Use MCP Tools Offline

Use MCP Tools Offline

Feluda can use local AI models without an internet connection.

MCP tools can also work offline, but only when every required part of the task remains local.

A fully offline MCP workflow normally requires:

• a local AI model;
• a local model runner;
• a local MCP server;
• local information sources;
• local authentication or no external authentication;
• local destinations; and
• no hidden online dependency.

A local model alone does not make the complete workflow offline.

What offline means

An offline workflow does not need an active internet connection to complete its task.

It may still use:

• your computer;
• local applications;
• local files;
• local databases;
• services running on localhost;
• another approved device on a private local network; or
• locally stored credentials.

If any required step contacts an online service, the complete workflow is not fully offline.

Understand the complete workflow path

Review every step.

For example:

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

This can work offline.

A different workflow may look like:

User Input
→ Local AI Model
→ Remote MCP Tool
→ Online Service
→ Local AI Model
→ Output

This workflow still depends on the internet.

Local model processing

Feluda can connect to local model runners such as:

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

A local model processes its prompt on your own computer.

Common local endpoints include:

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

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

Start the local model runner

The local model service must be running before Feluda can use it.

For Ollama, confirm that the Ollama service is active.

For LM Studio, open its local server area and start the server.

Then:

1. open AI Providers in Feluda;
2. select or add the local provider;
3. confirm the base URL;
4. fetch the available models; and
5. select the model you want to use.

No cloud model key is required for normal local inference.

Local MCP servers

A local MCP server runs on your own computer or another approved local machine.

It may provide tools for:

• reading local files;
• searching a local document collection;
• using a local database;
• interacting with a desktop application;
• writing to a local folder;
• creating local Journal entries; or
• using another on-device service.

Confirm that the server itself does not call an online service.

Local sources

Offline workflows need sources that remain available without the internet.

These may include:

• local files;
• local folders;
• a local database;
• downloaded documents;
• a local Journal;
• a local application;
• cached information; or
• an internal service available on the local network.

A link to an online document is not a local source.

Local destinations

The final output must also remain local if the entire workflow should stay offline.

Local destinations may include:

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

Sending a message, uploading a file, or updating an online record creates an internet dependency.

Hidden online dependencies

A workflow may appear local while still depending on the internet.

Common hidden dependencies include:

• a remote MCP server;
• web search;
• cloud storage;
• online authentication;
• a cloud database;
• an online messaging service;
• a remote model in a later block;
• license or account checks;
• remote source links; or
• a local tool that calls an online API.

Test the complete workflow without network access.

Local network is different from internet access

A workflow can use another device on the same private network and still avoid the public internet.

For example, it may use:

• a local file server;
• an internal database;
• another computer running an MCP server; or
• an approved on-premise service.

This is not the same as a single-device workflow.

Review network access, authentication, and organisational requirements.

Before you begin

Confirm that:

• Feluda is installed;
• the local model runner is installed;
• the model is downloaded;
• the model server is running;
• the local MCP server is installed and running;
• required files or databases are available;
• the destination is local;
• no cloud model is selected; and
• no remote tool is enabled.

Use non-sensitive sample information for the first test.

Choose an offline-capable model

The model must fit your computer.

Consider:

• available memory;
• graphics memory;
• model size;
• tool-use support;
• structured output;
• instruction following;
• source length; and
• expected speed.

A smaller model that runs reliably is often better than a larger model that frequently fails or causes timeouts.

Download the model before going offline

Model files must already be available on the device.

Before disconnecting:

• install the model runner;
• download the model;
• start the model once;
• confirm Feluda can see it; and
• complete a test response.

You cannot download a missing model without network access.

Prepare local sources in advance

Download or copy required information before going offline.

Confirm:

• filenames;
• folder locations;
• file permissions;
• document versions;
• database availability; and
• whether the tool can access the path.

Avoid temporary folders when files may be removed automatically.

Prepare local authentication

Some local tools may still require credentials.

Confirm that:

• the credential is stored locally;
• it does not require an online sign-in refresh;
• it remains valid offline;
• the account is available; and
• the tool does not contact an external identity service.

Store private values only in Feluda's protected settings.

Connect the local MCP server

Open MCP Servers from the Feluda sidebar.

Add or review the local connection.

Confirm:

• the server name;
• the local endpoint;
• the port;
• the connection state;
• available tools; and
• authentication when required.

Use a clear name such as:

Local Documents MCP

Or:

Offline Project Files MCP

Confirm the endpoint

A local endpoint may use:

• localhost;
• 127.0.0.1;
• another local address; or
• an approved private-network address.

Check:

• the correct protocol;
• address;
• port;
• path;
• server process; and
• firewall rules.

A local-looking name does not guarantee that the server avoids remote services.

Review every available tool

Confirm whether each tool:

• reads local information;
• writes to a local destination;
• contacts the internet;
• requires remote authentication;
• uses another service;
• stores data elsewhere; or
• performs a write action.

Enable only the tools required for the offline task.

Test in Workbench

Open Workbench.

Then:

1. select the local provider;
2. select the local model;
3. open Tools;
4. enable one local MCP tool;
5. use a clear instruction;
6. send the message; and
7. review the Activity drawer.

Keep the first test small.

Use a simple read-only test

For example:

Use only the enabled Local Documents Search tool.

Search for "offline MCP test".

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

Do not create or change anything.

This confirms the model and local tool can work together.

Review Activity

Confirm:

• the correct tool was called;
• the input was accurate;
• the result came from the local source;
• no remote tool was called;
• no unexpected network service was used;
• warnings were visible; and
• the final answer matched the tool result.

A local model can still call the wrong enabled tool.

Test without internet access

After the connected test succeeds:

1. save any 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 same test; and
7. compare the result.

Use a controlled test that will not interrupt other important work.

What the offline test should confirm

Confirm that:

• the local model responds;
• the MCP tool appears;
• the tool call completes;
• the source is available;
• authentication works;
• the output is returned;
• the destination remains available; and
• no hidden remote dependency appears.

Record any step that fails after the network is disconnected.

Test a no-match result offline

Use a sample query that should return nothing.

Confirm that:

• the tool completes normally;
• no result is returned;
• the model reports no match;
• no cloud fallback is used;
• no invented result appears; and
• the workflow stops correctly.

Test a local tool error

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

Confirm that:

• the error is visible;
• the model does not invent a result;
• repeated calls do not continue;
• no remote fallback is used; and
• the user receives a clear review message.

Restart the server after testing.

Build an offline workflow in Studio

A basic offline workflow may look like:

Input
→ Local LLM with Local MCP Tool
→ Output

A more reviewable workflow may look like:

Input
→ Local MCP Retrieval
→ Emit Raw Result
→ Local LLM Analysis
→ Local Output

Use local providers and local tools in every relevant block.

Use Emit blocks during testing

Emit blocks can show:

• raw local tool output;
• extracted fields;
• no-match results;
• error messages; or
• proposed local write actions.

This helps you confirm that no cloud step is hidden inside the workflow.

Check every workflow block

Review each block for:

• selected provider;
• selected model;
• enabled tools;
• source;
• destination;
• connected service;
• network requirement; and
• saved output.

One cloud block makes the complete workflow internet-dependent.

Use local write tools carefully

Offline write tools may still change important information.

They may:

• save a file;
• update a local database;
• create a Journal entry;
• change a local record; or
• move a file.

Use a draft-first process and confirm the destination.

Offline does not mean consequence-free.

Confirm local write destinations

After a write action, inspect:

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

Confirm that:

• the correct item changed;
• the correct value was written;
• no duplicate appeared;
• no unrelated file changed; and
• the result can be reversed when needed.

Protect local files

Use narrow path permissions.

Give the tool access only to:

• the required input folder;
• the approved output folder;
• one project directory; or
• specific files.

Do not grant complete filesystem access for a narrow task.

Protect local services

Use narrow IP and port rules.

Confirm:

• the service address;
• the port;
• the application using it;
• whether another process can use the same port;
• whether authentication is required; and
• whether the service is trusted.

Localhost access should still be reviewed.

Offline scheduling

A scheduled offline workflow requires all local components to be available at the planned time.

Confirm that:

• the computer is on;
• the computer is awake;
• Feluda is open;
• the model runner is active;
• the model is installed;
• the MCP server is active;
• local sources are mounted;
• local destinations are writable; and
• enough memory is available.

Use a one-time schedule for the first test.

Test a one-time offline schedule

Schedule the workflow for a near-future time.

Disconnect from the internet before the run.

Then confirm:

• the schedule starts;
• the local model loads;
• the local MCP tool runs;
• the source is available;
• the result appears;
• the local destination is correct; and
• Schedule Manager records the run.

Review the complete result before creating a recurring schedule.

Avoid sleep and power interruptions

Offline workflows still depend on the computer.

Review:

• sleep settings;
• laptop lid behaviour;
• battery-saving settings;
• automatic restarts;
• local service startup; and
• available power.

A sleeping computer may miss the scheduled run.

Hardware limits

Local models and local tools share the computer's resources.

Watch for:

• slow responses;
• model-loading failures;
• memory pressure;
• tool timeouts;
• application instability;
• delayed schedules; and
• overlapping local runs.

Use a smaller model or reduce simultaneous workflows when needed.

Avoid overlapping runs

Two offline workflows may compete for:

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

Stagger schedules and use unique output names.

Keep required software available

Offline workflows may depend on several local applications.

These can include:

• Feluda;
• Ollama;
• LM Studio;
• the local MCP server;
• a local database;
• a file server;
• a document index; or
• another desktop service.

Record which applications must be running.

Test after restarting the computer

A setup may work during configuration but fail after restart.

Test whether:

• the model runner starts;
• the MCP server starts;
• the endpoint remains the same;
• local files remain mounted;
• authentication remains available; and
• Feluda reconnects correctly.

Do this before relying on scheduled offline use.

Test after application updates

Re-test when:

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

Use the same offline test each time.

Troubleshoot a workflow that fails offline

Identify the first step that requires the internet.

Check:

• model provider;
• MCP server location;
• source;
• authentication;
• enabled tools;
• workflow blocks;
• destination;
• external links; and
• fallback behaviour.

Replace the dependency only when an approved local alternative exists.

If the model stops working offline

Confirm that:

• the local server is running;
• the model is downloaded;
• Feluda uses the local provider;
• the endpoint is correct;
• the model appears in AI Providers;
• enough memory is available; and
• the workflow did not switch to a cloud model.

Test the model without tools first.

If the MCP tool disappears offline

Check whether:

• the local MCP server is running;
• the endpoint is local;
• authentication depends on the internet;
• the tool list was loaded before disconnection;
• the server contacts an online service; and
• Feluda can still reach the local port.

Test the server separately.

If the source is unavailable offline

Confirm whether the source is truly local.

Check:

• file location;
• network drive;
• cloud-synchronised folder;
• database host;
• mounted volume;
• cached copy; and
• access permissions.

A cloud-synchronised folder may not contain every file locally.

If authentication fails offline

The connection may depend on:

• an online sign-in;
• token refresh;
• remote identity provider;
• account validation;
• network-based policy; or
• a cloud service.

Use an approved local authentication method when fully offline use is required.

If the workflow tries to use a remote fallback

Remove or disable the fallback when the task must remain offline.

A remote fallback may involve:

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

The workflow should return a clear offline error instead of silently sending data elsewhere.

Confirm offline privacy

An offline workflow can reduce external data movement.

It still requires normal device security.

Protect:

• the operating-system account;
• local files;
• model files;
• Journal data;
• local databases;
• tool logs;
• backups;
• local credentials; and
• physical access to the device.

Offline data can still be exposed through an unprotected computer.

Back up important local output

Do not treat one offline device as the only copy of information that must be preserved.

Use your approved backup process.

Confirm whether the backup itself is:

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

A cloud backup means the complete storage process is not fully offline.

A practical offline checklist

Before regular use, confirm that:

• the AI model is local;
• the model is downloaded;
• the model runner works without internet;
• the MCP server is local;
• every enabled tool works locally;
• sources are available offline;
• authentication remains valid offline;
• destinations are local;
• no cloud fallback is enabled;
• Activity shows only intended local tools;
• Studio contains no cloud blocks;
• RunFlows succeeds while disconnected;
• write destinations are verified;
• a one-time schedule succeeds offline; and
• device security and backups are appropriate.

A workflow is fully offline only when every required part remains available without an internet connection.