Prepare a Local MCP Environment

Prepare a Local MCP Environment

A local MCP environment lets Feluda use an AI model, tools, sources, and destinations that run on your own computer or approved local network.

A complete local setup may include:

• Feluda;
• a local AI model runner;
• one or more downloaded models;
• a local MCP server;
• approved local files or databases;
• protected local credentials;
• local output destinations; and
• clear permission rules.

Preparing each part before building workflows makes testing and troubleshooting much easier.

What a local environment includes

A local environment is more than a local AI model.

A typical path may look like:

User Input
→ Local AI Model
→ Local MCP Tool
→ Local Source
→ Local AI Model
→ Local Output

To keep the complete task local, every required part must remain available without an external online service.

A remote MCP server, cloud model, online source, or cloud destination changes the data path.

Decide what must remain local

Before installing anything, define the requirement.

Ask:

• Must model processing stay on the device?
• Must the MCP server run locally?
• Must all sources remain local?
• Must the final output stay local?
• Must the workflow operate without internet access?
• Can another approved device on the local network be used?
• Are there organisational restrictions on files, accounts, or network use?

The answers determine the environment you need.

Choose the computer

The computer should be able to run:

• Feluda;
• the local model runner;
• the selected model;
• the MCP server;
• local tools;
• source applications; and
• any scheduled workflows.

Review:

• system memory;
• graphics memory;
• processor;
• graphics processor;
• storage;
• operating-system version;
• available ports;
• power settings; and
• normal workload.

The AI model usually creates the largest hardware demand.

Choose a local model runner

Feluda can connect to local model runners such as:

• Ollama;
• LM Studio; or
• another compatible local endpoint.

Ollama is useful for a lightweight setup.

LM Studio provides a graphical interface for downloading models and starting a local server.

Choose the runner that is easiest to maintain on the computer.

Install the model runner

Install the selected model runner using its official installer or approved installation method.

After installation:

• open the application or service;
• confirm that it starts normally;
• check its local server settings;
• note the endpoint;
• note the port; and
• confirm that the operating system does not block it.

Keep the runner updated according to your normal software-management process.

Download a model

Download at least one model before configuring Feluda.

Choose a model based on:

• available memory;
• task complexity;
• tool-use support;
• instruction following;
• context size;
• structured output;
• language requirements; and
• expected speed.

A smaller model that runs reliably is often a better starting point than a larger model that frequently fails to load.

Test the model in its own runner

Before connecting Feluda, send a simple message directly through the model runner.

Confirm that:

• the model loads;
• a response appears;
• response time is acceptable;
• memory use remains stable;
• the server remains running; and
• no unexpected error appears.

This separates model-runner problems from Feluda configuration problems.

Record the local endpoint

Standard setups often use:

• Ollama: http://localhost:11434
• LM Studio: http://localhost:1234

Use the endpoint shown by your model runner when it differs.

Record:

• protocol;
• host;
• port;
• path when required; and
• whether the service starts automatically.

Connect the local provider in Feluda

Open AI Providers from the Feluda sidebar.

Select or add the local provider.

Then:

1. enter or confirm the base URL;
2. save the provider settings;
3. select Fetch Models;
4. wait for the installed models to appear; and
5. choose the model you want to test.

A normal local model connection does not require a cloud model key.

Confirm that Feluda sees the model

If the model does not appear, check:

• the model runner is open;
• its local server is running;
• the endpoint is correct;
• the port is reachable;
• the model is downloaded;
• the local firewall allows the connection; and
• Fetch Models was selected again.

Do not continue to MCP testing until the model works in Feluda.

Test the local model in Workbench

Open Workbench.

Select:

• the local provider; and
• the downloaded model.

Send a simple message without tools.

For example:

Explain what a local AI workflow is in three short paragraphs.

Confirm that:

• the response appears;
• the correct model is selected;
• no cloud provider is used;
• the response time is acceptable; and
• the local runner remains stable.

Choose the local MCP server

A local MCP server may run:

• on the same computer;
• on another approved computer in the local network;
• inside a local application; or
• as part of an internal service.

Confirm who provides and maintains it.

Review:

• its purpose;
• available tools;
• endpoint;
• authentication;
• data sources;
• write destinations;
• startup process; and
• update process.

Install or start the local MCP server

Follow the server owner's approved setup process.

Confirm that:

• the server starts;
• its endpoint is visible;
• its port is known;
• authentication is complete when required;
• the expected tools are available; and
• no remote dependency is hidden in the server.

A server running locally may still call an online service.

Add the server to Feluda

Open MCP Servers from the sidebar.

Add the local server.

Enter:

• a clear server name;
• the endpoint URL; and
• protected authentication details when required.

Use names such as:

• Local Documents MCP;
• Local Project Files MCP;
• Internal Database MCP; or
• Offline Research Tools MCP.

Save the connection and review its state.

Confirm tool discovery

After the connection is saved, confirm that the server's tools appear.

Review each tool's:

• name;
• purpose;
• expected input;
• returned output;
• read or write behaviour;
• source;
• destination; and
• permission needs.

Do not enable every tool by default.

Prepare local sources

Local sources may include:

• files;
• folders;
• a local document collection;
• a local database;
• a local Journal;
• a desktop application;
• a downloaded dataset; or
• another approved local service.

Place sources in stable locations.

Avoid temporary folders and paths that may change after restart.

Organise source folders

Use clear folder names.

For example:

/projects/atlas/source
/projects/atlas/reference
/projects/atlas/results

Or on Windows:

C:\Users\Name\Documents\Feluda\Atlas\Source
C:\Users\Name\Documents\Feluda\Atlas\Results

Separate input and output folders when possible.

Check file availability

Confirm that:

• files exist;
• filenames are clear;
• duplicate filenames are avoided;
• required files are fully downloaded;
• permissions allow access;
• the source is not only an online placeholder; and
• the local tool can read the file type.

Cloud-synchronised folders may not contain complete offline copies.

Prepare local databases

When a tool uses a local database, confirm:

• database service is running;
• host and port are correct;
• local authentication works;
• the required database exists;
• the account has limited access;
• backups are available; and
• write permissions are understood.

Test a read-only query before any update.

Prepare local destinations

Local outputs may be saved to:

• RunFlows;
• the Feluda Journal;
• a local file;
• a local folder;
• a local database;
• a desktop application; or
• another on-device service.

Confirm exactly where each write tool sends its result.

Protect credentials

Some local services still require:

• access tokens;
• passwords;
• API keys;
• database credentials; or
• protected headers.

Store private values only in Feluda's intended protected settings or the operating system's secure credential storage.

Do not place them in:

• Workbench prompts;
• Studio instructions;
• Input blocks;
• Journal entries;
• files used as normal sources; or
• troubleshooting screenshots.

Use separate credentials by purpose

When possible, use separate credentials for:

• read-only use;
• approved write use;
• test environments;
• production environments;
• different projects; or
• different teams.

Clear separation reduces accidental access.

Set narrow file permissions

Give the MCP tool access only to the required folders or files.

Prefer:

• one input folder;
• one output folder;
• one project directory; or
• specific approved paths.

Avoid access to the complete filesystem.

Set narrow network permissions

Review:

• allowed URLs;
• allowed IP addresses;
• allowed ports;
• localhost access;
• local-network access; and
• blocked destinations.

Allow only the services required for the task.

Review localhost services

A localhost address points to the same computer.

Confirm:

• which application uses the port;
• whether the service is trusted;
• whether the port is fixed;
• whether another process can take it;
• whether authentication is enabled; and
• whether the service starts automatically.

Localhost access still needs review.

Review local-network services

When the MCP server runs on another device, confirm:

• device identity;
• private-network address;
• network availability;
• firewall rules;
• authentication;
• service owner;
• source access; and
• what happens when that device is offline.

A local-network workflow is not a single-device workflow.

Test one read-only tool

Open Workbench.

Select:

• the local provider;
• the local model; and
• one MCP read tool.

Use a small request.

For example:

Use only the enabled Local Documents Search tool.

Search for "local MCP environment test".

Return:
1. document title;
2. local path;
3. returned summary; and
4. any warning.

Do not create or change anything.

Review Activity

Open the Workbench Activity drawer.

Confirm:

• the correct tool was called;
• the input was accurate;
• the local source was used;
• the output is complete;
• no remote tool was called;
• warnings were visible; and
• the final answer matches the raw result.

Keep the first test simple.

Test an empty result

Use a query that should not match anything.

Confirm that:

• the tool completes;
• no result is returned;
• the model reports no match;
• no information is invented;
• no remote fallback is used; and
• the process stops normally.

Test a tool error

Use an approved method, such as temporarily stopping the local MCP server.

Confirm that:

• the error is visible;
• the model does not invent a result;
• repeated calls stop;
• the workflow does not switch to an unapproved service; and
• the user receives a clear review message.

Restart the server afterward.

Test a read-only account

When the source supports account permissions, confirm that the test account can:

• search approved records;
• read approved files;
• retrieve required fields; and
• access only the intended scope.

Also confirm that it cannot perform write actions.

Test blocked access

When safe and appropriate, test one unapproved:

• folder;
• file;
• URL;
• IP address;
• port;
• record; or
• project.

Confirm that access is denied clearly.

The model should not use another source without permission.

Test write tools separately

Do not test a write tool until read-only testing succeeds.

Use:

• a test record;
• a temporary folder;
• a reversible action;
• non-sensitive content; and
• explicit approval.

Confirm the result directly at the destination.

Use a draft-first write test

Ask the model to prepare the action first.

For example:

Prepare a local test file.

Show:
* filename;
* output folder;
* content;
* whether an existing file would be replaced; and
* how the file can be removed.

Do not create the file yet.

Review the draft before approval.

Confirm local write results

After approval, inspect:

• the file;
• folder;
• Journal entry;
• database record;
• task;
• note; or
• other local destination.

Confirm that:

• the correct item changed;
• no unrelated item changed;
• no duplicate appeared;
• the timestamp is correct; and
• the action can be reversed when needed.

Build a small Studio workflow

Start with:

Input
→ Local LLM with Local MCP Tool
→ Output

Use the same model, tool, and instruction that worked in Workbench.

Keep the first workflow focused on one task.

Add intermediate visibility

Use an Emit block when you need to see raw data.

For example:

Input
→ Local MCP Retrieval
→ Emit Raw Result
→ Local Model Summary
→ Output

This helps separate a tool problem from a model problem.

Add no-result and error paths

Distinguish:

• valid result;
• empty result;
• permission error;
• server error; and
• model error.

Do not route every outcome into a normal success message.

Test the saved flow in RunFlows

After saving the workflow:

1. open RunFlows;
2. select the flow;
3. provide sample input;
4. start the run;
5. inspect intermediate output;
6. review the tool call;
7. review warnings and errors;
8. compare the final answer with the raw result; and
9. inspect any local write destination.

Test while disconnected

After the connected test succeeds:

1. save required work;
2. disconnect from the internet;
3. keep Feluda open;
4. keep the local model runner active;
5. keep the local MCP server active;
6. repeat the Workbench test;
7. repeat the RunFlows test; and
8. inspect the local destination.

This reveals hidden remote dependencies.

Check every block for remote dependencies

Review each Studio block.

Confirm:

• provider;
• model;
• enabled tools;
• source;
• destination;
• authentication;
• fallback;
• links; and
• connected services.

One cloud model or remote tool makes the complete flow internet-dependent.

Disable unapproved fallbacks

A local workflow should not silently switch to:

• a cloud model;
• web search;
• a remote MCP server;
• online storage;
• cloud messaging; or
• another external service.

When fully local processing is required, return a clear error instead.

Prepare for computer restart

Restart the computer and confirm that:

• Feluda opens;
• the model runner starts;
• the model is still installed;
• the MCP server starts;
• endpoints remain unchanged;
• local files remain available;
• authentication remains valid; and
• Workbench can call the tool.

A setup that only works before restart is not ready for regular use.

Prepare automatic service startup

For scheduled use, determine which local services must start automatically.

These may include:

• the model runner;
• the MCP server;
• a local database;
• a file service;
• a document index; or
• another desktop application.

Use the service owner's approved startup method.

Review sleep and power settings

Scheduled local workflows depend on the computer being available.

Check:

• sleep settings;
• laptop lid behaviour;
• battery saving;
• automatic restart;
• login requirements;
• screen lock behaviour; and
• available power.

A sleeping computer may miss the run.

Review hardware under normal load

Test while normal applications are open.

Watch for:

• high memory use;
• slow responses;
• model-loading failure;
• delayed tool calls;
• local service timeouts;
• application instability; and
• competing workflows.

Reduce model size or simultaneous work when needed.

Avoid overlapping local workflows

Several local runs may compete for:

• memory;
• processor time;
• graphics memory;
• model server access;
• the same source file;
• the same database; or
• the same output destination.

Stagger schedules and use unique output names.

Test a one-time schedule

Use a one-time schedule before creating a recurring one.

Confirm that:

• the computer is awake;
• Feluda is open;
• the model runner is active;
• the MCP server is active;
• the source is available;
• the workflow completes;
• the local result is correct; and
• Schedule Manager records the run.

Repeat the test while disconnected when offline use is required.

Review device security

A local setup keeps more responsibility on the device.

Protect:

• the operating-system account;
• screen lock;
• local files;
• source folders;
• Journal data;
• local databases;
• credentials;
• backups;
• removable drives; and
• physical access.

Local processing does not make an unprotected computer safe.

Plan backups

Back up information that must be preserved.

Review whether the backup is:

• local;
• encrypted;
• removable;
• network-based; or
• cloud-based.

A cloud backup changes the wider storage path even when the workflow itself is local.

Record the environment

For important setups, record:

• operating system;
• Feluda version;
• model runner;
• model;
• model endpoint;
• MCP server;
• MCP endpoint;
• required ports;
• approved source paths;
• approved output paths;
• account type;
• required local services;
• test date; and
• responsible owner.

Do not include raw credentials.

Re-test after changes

Repeat the test set when:

• Feluda updates;
• the model runner updates;
• the model changes;
• the MCP server updates;
• tool names change;
• endpoints change;
• ports change;
• paths change;
• permissions change; or
• the operating system updates.

Use the same controlled tests each time.

Final local environment checklist

Before regular use, confirm that:

• Feluda works normally;
• the local model runner is installed;
• the model is downloaded;
• Feluda can fetch the model;
• the model works in Workbench;
• the local MCP server is available;
• expected tools appear;
• local sources are stable;
• local destinations are clear;
• credentials are protected;
• permissions are narrow;
• read-only tests succeed;
• empty and error cases work;
• write actions are reviewed;
• RunFlows succeeds;
• disconnected testing succeeds when required;
• required services survive restart; and
• scheduled use has been tested separately.

A dependable local MCP environment is built by preparing and testing every part of the path—not only the AI model.