Is a local MCP server always more private?

No. A local server can still call an online service. Review every tool, source, destination, and external dependency before treating the workflow as local.

Can a remote MCP server be used with a local AI model?

Yes. Model processing can remain on the device while the MCP tool request is sent to the remote server. The complete task is then only partly local.

Which server type is better for offline use?

A local MCP server is required for fully offline tool use, and the model, source, authentication, destination, and every other dependency must also work locally.

What should I compare before choosing a server?

Compare data location, trust, privacy, source and destination, maintenance, availability, hardware, network access, authentication, permissions, performance, write actions, and scheduled use.

Choose Between Local and Remote MCP Servers | Feluda.ai Documentation

Choose Between Local and Remote MCP Servers

Feluda can use tools from local and remote MCP servers.

Both types can provide useful capabilities.

The main difference is where the server runs and how Feluda reaches it.

A local MCP server runs on your computer or an approved local network.

A remote MCP server runs on another system reached through a network or the internet.

Choose the server type that fits the task, data, maintenance, availability, and review requirements.

Compare the two server types

Area	Local MCP server	Remote MCP server
Location	Your computer or approved local network	Another system or hosted service
Internet requirement	May work without internet	Usually requires network or internet access
Data path	Can remain local	Tool input is sent to the remote server
Maintenance	Usually managed by you or your organisation	Usually managed by a provider or remote team
Hardware	Uses local resources	Uses the remote server's resources
Availability	Depends on local device and services	Depends on network and remote service uptime
Updates	You may control timing	Provider may update the server
Offline use	Possible when every dependency is local	Usually not possible
Scaling	Limited by local hardware	May handle larger or shared workloads
Access	Often limited to local sources	Can reach approved remote systems

Neither option is automatically better.

The right choice depends on the complete workflow.

Start with the task

Define what the MCP tool must do.

For example:

search local files;
read an internal database;
retrieve a customer record;
access a hosted knowledge service;
create a task;
send a message;
save a local report; or
update an online business system.

The source and destination often determine whether a local or remote server is more suitable.

Understand the complete data path

Review every step.

A local setup may look like:

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

A remote setup may look like:

User Input
→ AI Model
→ Remote MCP Server
→ Online Service
→ Tool Result
→ Final Answer

A mixed setup may use a local model with a remote MCP server.

Model location and MCP server location are separate decisions.

What is a local MCP server?

A local MCP server runs:

on the same computer as Feluda;
on another approved device in the local network;
inside a local application; or
as part of an on-premise service.

It may provide tools for:

reading local files;
searching a local document collection;
using a local database;
working with a desktop application;
writing to a local folder; or
accessing an internal service.

A local server can still contact an external service.

Review each tool, not only the server address.

What is a remote MCP server?

A remote MCP server runs outside the local computer.

It may be operated by:

your organisation;
a software provider;
a hosted internal service;
a trusted third party;
an open-source project host; or
another approved operator.

It may provide tools for:

hosted business systems;
cloud storage;
online search;
messaging;
shared records;
remote databases; or
other online services.

Remote tools require network access.

Choose a local server for local sources

A local MCP server is often a good fit when the tool needs to use:

files stored on the device;
a local database;
a desktop application;
an offline document collection;
a local Journal;
a local model service; or
an internal service available only on the local network.

Keeping the server near the source can reduce unnecessary data movement.

Choose a remote server for remote systems

A remote MCP server is often a good fit when the tool needs to use:

a hosted business platform;
a shared organisational service;
an online database;
cloud storage;
a messaging service;
a remote knowledge base; or
a provider-managed application.

The server may already be maintained close to the connected system.

Compare privacy

A local MCP server can help keep tool processing on the device or local network.

This is useful when:

sensitive files should remain local;
internal records should not leave the organisation;
data residency matters;
offline work is required; or
the source exists only on the device.

A local server is not automatically private if its tools call remote services.

Remote-server privacy

A remote MCP server receives the information required by its tools.

That information may include:

search terms;
document text;
record identifiers;
file information;
structured fields;
user instructions; or
content prepared by an earlier workflow step.

Confirm what the server receives and how it handles that information.

Review the server owner

For either type, ask:

Who operates the server?
Who maintains it?
Why is it needed?
Which tools does it provide?
What information can it receive?
Can it store tool input or output?
Can it use another service?
Who can change its configuration?
What happens when it is unavailable?

A known location does not replace trust review.

Compare internet dependence

A local MCP server can work without internet access when:

the server is local;
the source is local;
authentication works locally;
the destination is local; and
no tool calls an online service.

A remote MCP server normally needs:

a working network;
a reachable endpoint;
valid remote authentication; and
an available hosted service.

Compare offline use

Choose a local MCP server when the workflow must continue offline.

Confirm that:

the AI model is local;
the MCP server is local;
all sources are local;
authentication remains valid offline;
destinations are local; and
no remote fallback is enabled.

A remote MCP server makes the workflow network-dependent.

Compare availability

A local server depends on:

the computer being on;
the local process running;
the port remaining available;
local files being mounted;
local databases running;
enough hardware resources; and
the operating system remaining stable.

A remote server depends on:

network access;
remote service uptime;
provider maintenance;
valid authentication;
firewall or VPN access; and
the provider's infrastructure.

Choose based on expected uptime

A remote service may be more available than one personal computer.

A local server may be more dependable when:

the internet connection is unreliable;
the service must work offline;
the source exists only locally; or
the organisation controls the local infrastructure.

Test the actual environment rather than assuming one type is always more reliable.

Compare maintenance

With a local MCP server, you may need to manage:

installation;
startup;
updates;
ports;
local permissions;
file paths;
hardware;
backups;
logs; and
troubleshooting.

With a remote MCP server, the provider may manage the service itself.

You still need to manage:

the Feluda connection;
authentication;
permissions;
tool changes;
dependent workflows; and
provider trust.

Compare update control

A local server may let you choose when to update.

This can make it easier to:

test first;
pause schedules;
record the current version;
keep a rollback option; and
migrate workflows gradually.

A remote provider may update the server without matching your preferred timing.

Monitor tool lists, result formats, permissions, and errors after remote changes.

Compare hardware requirements

A local server uses local resources.

Depending on the tools, it may need:

processor time;
memory;
storage;
graphics processing;
local database capacity; or
access to other applications.

A remote server uses the provider's hardware for server-side work.

The local computer still runs Feluda and may run the AI model.

Compare performance

A local server may be faster when:

the source is local;
the tool does not need the internet;
the computer has enough resources; and
network delay would otherwise be significant.

A remote server may be faster when:

the connected system is remote;
the provider has stronger hardware;
the task is large;
the service is optimised for the source; or
local hardware is limited.

Measure the complete tool task.

Measure total runtime

Record:

time to choose the tool;
connection time;
tool execution time;
result-return time;
model interpretation time; and
total workflow time.

A local server can still be slow when the local computer is overloaded.

A remote server can still be fast when the service and network are stable.

Compare scaling

A local server may be suitable for:

one user;
a small team;
local projects;
low-volume tasks; or
controlled offline work.

A remote server may be more suitable for:

shared access;
higher request volume;
centralised maintenance;
several users;
remote teams; or
large connected systems.

Confirm the provider's limits before relying on high-volume use.

Compare authentication

A local server may use:

no authentication;
a local account;
a protected token;
operating-system access; or
internal network controls.

A remote server may use:

an API key;
access token;
account sign-in;
protected headers;
organisational identity; or
another remote authentication method.

Store private values only in Feluda's protected settings.

Review credential renewal

Remote credentials may:

expire;
require refresh;
be revoked;
change scope;
depend on an external identity provider; or
stop working after an account change.

Local credentials may also change, especially after:

operating-system updates;
account changes;
service reinstallation;
database changes; or
local security-policy updates.

Plan how access will be maintained.

Compare permissions

Both local and remote tools may require:

read permission;
write permission;
account access;
URL access;
IP access;
path access;
port access; or
destination access.

Use the narrowest permission that supports the approved task.

Local permission examples

A local server may need access to:

one source folder;
one output folder;
one local database;
one desktop application;
one port; or
one approved network device.

Avoid giving it access to the entire filesystem or local network.

Remote permission examples

A remote server may need access to:

one workspace;
one project;
selected records;
one hosted folder;
one messaging channel;
one business account; or
one approved API scope.

Avoid broad administrator permissions.

Compare file access

A local MCP server is often better for local file operations because it can work near the source.

Confirm:

approved folder;
file types;
read or write access;
overwrite behaviour;
output folder;
duplicate handling; and
backup process.

A remote server may require files to be uploaded or made accessible through another service.

Compare shared access

A remote MCP server may be easier for several users or devices to access.

This can support:

shared tools;
consistent configuration;
centralised updates;
common business systems; and
remote teams.

Review account boundaries and user permissions.

A local server may be more suitable when access should remain limited to one computer or location.

Compare network requirements

A local server on the same computer normally uses a local endpoint.

A local-network server may require:

a private IP address;
an open local port;
local firewall rules;
network availability; and
device access.

A remote server may require:

internet access;
DNS;
HTTPS;
VPN;
proxy settings;
external firewall rules; and
provider availability.

Compare firewall and VPN needs

A local connection may fail when:

the local firewall blocks the port;
another application uses the port;
the service is bound to the wrong address; or
the network profile changes.

A remote connection may fail when:

the VPN is disconnected;
the domain is blocked;
the endpoint changes;
a certificate fails;
the provider is unavailable; or
an organisational network policy blocks access.

Test the actual network path.

Compare write actions

Both local and remote MCP servers can provide write tools.

A local write tool may:

create a file;
update a local record;
write a Journal entry;
change a local database; or
move a local item.

A remote write tool may:

update a hosted record;
send a message;
create a task;
upload a file; or
change an online account.

Use the same review standards for both.

Use draft-first review

Before an important write action:

prepare the proposed change;
show the destination;
show the current state;
show the new values;
show the source;
confirm reversibility; and
request explicit approval.

The server location does not remove the need for human review.

Confirm external and local destinations

After a write action, inspect the real destination.

For a local server, inspect:

file;
folder;
Journal entry;
local database;
desktop application; or
local record.

For a remote server, inspect:

hosted record;
message;
task;
cloud file;
online account; or
remote service.

Compare backup needs

Local server data may depend on your backup process.

Review:

local files;
local databases;
configuration;
logs;
workflow output; and
credentials.

Remote services may provide their own backup or history.

Confirm what is actually preserved and how recovery works.

Compare recovery

For a local server, recovery may involve:

restarting the service;
restoring a configuration;
restoring a file;
restoring a database;
changing a port;
reinstalling the server; or
restoring a backup.

For a remote server, recovery may involve:

waiting for provider restoration;
renewing authentication;
changing the endpoint;
contacting the provider;
switching regions; or
using an approved alternative.

Compare troubleshooting visibility

A local server may provide direct access to:

local logs;
process status;
ports;
configuration files;
local files; and
service restarts.

A remote server may provide:

provider status;
remote logs;
account activity;
support tools;
service dashboards; or
provider error messages.

Feluda Activity and RunFlows help review both types.

Review Workbench Activity

For either server type, confirm:

which tool was called;
which server provided it;
what input was sent;
what result returned;
whether a warning appeared;
whether an error occurred; and
whether the final answer matches the tool result.

Do not rely only on the model's statement.

Review Studio and RunFlows

In workflows, review:

selected server tool;
model;
instruction;
input mapping;
result structure;
permissions;
error path;
no-result path;
Emit output; and
external destination.

Test the saved flow through RunFlows.

Compare scheduled use

A scheduled local-server workflow requires:

the computer to be on;
Feluda to be open;
the local server to be running;
local sources to be available;
local ports to remain reachable; and
enough hardware capacity.

A scheduled remote-server workflow requires:

network access;
valid authentication;
remote service availability;
provider uptime;
source availability; and
destination availability.

Test each with a one-time schedule.

Choose local for controlled offline work

A local MCP server is usually the stronger choice when:

the workflow must work offline;
the source is local;
information should remain on the device;
the organisation controls the environment;
local hardware is sufficient;
the task is low or moderate volume; and
maintenance responsibility is clear.

Confirm that no hidden remote service is involved.

Choose remote for shared managed services

A remote MCP server is usually the stronger choice when:

the source is already online;
several users need the same tools;
central maintenance is preferred;
the provider manages scaling;
high availability is needed;
local hardware is limited; and
network access is dependable.

Confirm that remote processing is appropriate for the information.

Use both when the workflow needs both

One Feluda setup can use local and remote MCP servers.

For example:

Local File Tool
→ Local Model Redaction
→ Remote Business Service
→ Final Output

Or:

Remote Knowledge Search
→ Local Model Summary
→ Local Journal

Review what information crosses from the local stage to the remote stage.

Keep mixed workflows visible

A mixed workflow should make each boundary clear.

Label blocks with names such as:

Read Local Source;
Remove Sensitive Fields;
Send Approved Query to Remote Service;
Save Result Locally; or
Human Review Before Remote Write.

Do not hide a remote call inside a generally local workflow.

Avoid automatic unreviewed fallback

A workflow should not silently switch:

from local to remote;
from remote to local;
from one server to another;
from a read tool to a write tool; or
from a test environment to production.

Make fallback behaviour visible.

Request approval when the new path changes privacy or destination.

Compare costs outside Feluda

A local MCP server may require:

hardware;
electricity;
storage;
maintenance time;
backups; or
internal support.

A remote server may have its own:

subscription;
account;
usage limits;
infrastructure charges;
service terms; or
support agreement.

Review the external service's current terms before relying on it.

Compare organisational fit

Ask:

Who owns the server?
Who supports it?
Who approves access?
Who monitors failures?
Who updates dependent workflows?
Who reviews write actions?
Who responds to privacy concerns?
Who handles recovery?

Choose the option that your organisation can operate responsibly.

Test both options fairly

When both are available, use the same:

task;
model;
input;
expected result;
output structure;
permissions;
review process; and
number of test runs.

Compare:

result quality;
runtime;
reliability;
data path;
hardware use;
network dependence;
error handling; and
maintenance effort.

Create a comparison table

A practical comparison may look like:

Check	Local server	Remote server
Source location	Local files	Hosted knowledge base
Works offline	Yes	No
Average runtime	6 seconds	4 seconds
Maintenance owner	Internal IT	Provider
Write destination	Local folder	Shared project system
Network required	No	Yes
Data leaves device	No	Query and returned result
Suitable for task	Yes	Yes, when network is available

Choose based on the task's priorities.

Reassess after changes

Review the choice again when:

the source moves;
privacy requirements change;
hardware changes;
network reliability changes;
the provider changes;
the server updates;
workload increases;
users increase;
offline use becomes necessary; or
maintenance ownership changes.

A good choice today may not remain the best choice later.

A practical decision routine

Use this process:

Define the real tool task.
Identify the source and destination.
Decide whether offline use is required.
Map the complete data path.
Review privacy requirements.
Review server ownership and trust.
Compare hardware and network needs.
Compare availability and maintenance.
Compare authentication and permissions.
Test one read-only tool.
Review Activity and RunFlows.
Test write actions separately.
Test one-time scheduled use.
Compare repeated-run reliability.
Record the chosen server and reason.
Reassess after important changes.

Choose a local or remote MCP server based on the complete workflow, not only on where the server runs.