Compare Local and Cloud Models for MCP Tools
Feluda can use local and cloud AI models with MCP tools.
Both options can:
- use tools in Workbench;
- support Studio workflows;
- process tool results;
- prepare structured output;
- support read and write tasks; and
- become part of scheduled workflows.
The best choice depends on the task.
Compare models by testing the complete MCP process, not only by comparing model names or general chat quality.
The main difference
A local model runs on your own computer.
A cloud model runs on the provider's remote systems.
| Model type | Where model processing happens |
|---|---|
| Local model | On your computer through a local model runner |
| Cloud model | On the remote provider's systems |
The MCP server may still be local or remote in either setup.
Model location and tool location are separate.
The four common combinations
An MCP task may use:
| Model | MCP server | Main data path |
|---|---|---|
| Local | Local | Model and tool processing can remain on the device or local network |
| Local | Remote | Model processing stays local, but tool input goes to the remote server |
| Cloud | Local | Model input goes to the cloud provider, while the tool accesses a local source |
| Cloud | Remote | Both model and tool processing may involve remote services |
Review the complete path before using sensitive information.
Local models in Feluda
Feluda can connect to local model runners such as:
- Ollama;
- LM Studio; or
- another compatible local endpoint.
Local models can be used in:
- Workbench;
- Studio;
- RunFlows; and
- scheduled workflows.
The local model runner must remain available while the model is in use.
Cloud models in Feluda
Feluda can connect to supported cloud AI providers.
Cloud models generally require:
- an internet connection;
- a configured provider;
- a protected provider key or account; and
- permission to send the task information to that provider.
The available models depend on the configured provider.
Compare privacy
Local models can keep model processing on the device.
This can be useful when:
- documents are sensitive;
- internal information should remain local;
- offline operation is required;
- data residency matters; or
- the organisation prefers on-device processing.
A local model does not keep a remote MCP call local.
The tool may still receive information outside the computer.
Cloud-model privacy
A cloud model receives the information sent to its provider.
Before use, review:
- user input;
- source text;
- tool results;
- conversation history;
- attached files;
- structured fields; and
- final output.
Remove information that the model does not need.
Compare MCP data paths
With a local model, the MCP tool call may be the only part that leaves the device.
With a cloud model, both the model request and a remote MCP tool call may leave the device.
For every task, identify:
- model location;
- MCP server location;
- source location;
- authentication location;
- destination location; and
- where results are stored.
Do not describe a workflow as local unless all required parts remain local.
Compare offline use
A local model can work without an internet connection after:
- the model runner is installed;
- the model is downloaded;
- the local endpoint is configured; and
- required local services are running.
A complete MCP workflow works offline only when:
- the model is local;
- the MCP server is local;
- the source is local;
- authentication works locally;
- the destination is local; and
- no online dependency is required.
Cloud models require internet access.
Compare setup requirements
A local model setup normally requires:
- a local model runner;
- a downloaded model;
- a running local server;
- enough computer memory;
- enough storage; and
- a configured local endpoint in Feluda.
A cloud model setup normally requires:
- a provider account;
- provider authentication;
- an internet connection; and
- a configured provider in Feluda.
Choose the setup your environment can maintain reliably.
Compare hardware needs
Local models use the user's computer.
Their performance depends on:
- system memory;
- graphics memory;
- processor;
- graphics processor;
- model size;
- source length;
- number of tool calls;
- simultaneous workflows; and
- other active applications.
Cloud models use the provider's hardware.
The user's computer still runs Feluda and connected local tools, but it does not perform the cloud model inference.
Compare speed
Local-model speed depends heavily on the computer and model size.
A smaller local model may respond quickly.
A larger local model may:
- load slowly;
- use more memory;
- delay tool calls;
- cause timeouts; or
- compete with other workflows.
Cloud-model speed depends on:
- network quality;
- provider availability;
- model demand;
- request size; and
- provider response time.
Measure the complete task rather than only the first model response.
Measure the full MCP task
Record:
- time to understand the request;
- time to choose the tool;
- MCP tool execution time;
- time to interpret the result;
- total workflow time; and
- time under normal workload.
A fast model may still produce a slow task when the MCP server or connected service is slow.
Compare tool-use reliability
Test whether the model can:
- recognise that a tool is needed;
- choose the correct tool;
- provide valid parameters;
- use the correct server;
- handle an empty result;
- handle an error;
- interpret returned fields;
- avoid repeated calls; and
- stop after completion.
Tool reliability matters more than general writing quality for MCP tasks.
Compare simple tool use
A simple task may involve:
- one tool;
- one identifier;
- one returned record; and
- one fixed output structure.
Many suitable local and cloud models can handle this well.
Test with the real tool and expected source.
Compare complex tool use
A complex task may require:
- several tools;
- ambiguous tool choice;
- multiple records;
- long tool output;
- several workflow steps;
- classification;
- approvals;
- write actions; or
- detailed reasoning.
More capable models may perform these tasks more reliably.
Test the entire process before deciding.
Compare exact-value handling
MCP tasks often require the model to preserve:
- names;
- dates;
- amounts;
- identifiers;
- statuses;
- filenames;
- record references;
- account names; and
- source links.
Compare raw tool output with the final answer.
Do not assume a more fluent model is more precise.
Compare structured output
Workflows may depend on a stable structure.
Test whether each model consistently returns:
- required field names;
- correct value types;
- complete sections;
- valid lists or tables;
- visible missing values;
- stable labels; and
- predictable error output.
Inconsistent structure can break later blocks.
Compare context handling
Some MCP tasks include:
- long documents;
- many returned records;
- detailed conversation history;
- several tools;
- large structured responses; or
- multiple workflow stages.
Test whether the model:
- remembers the tool-use limit;
- preserves all required fields;
- keeps records separate;
- retains source references;
- avoids mixing old and new input; and
- follows the final requested format.
Use only the context the task needs.
Compare no-result handling
Use a search that should return no match.
Confirm whether the model:
- reports the empty result;
- avoids inventing a record;
- avoids calling a write tool;
- asks for better input when appropriate;
- distinguishes no match from an error; and
- stops after the result is clear.
This test is important for both local and cloud models.
Compare error handling
Test an approved error condition.
Confirm whether the model:
- recognises the tool failure;
- explains it accurately;
- avoids presenting invented source data;
- avoids repeated calls;
- protects authentication details;
- follows the review path; and
- tells the user what should be checked.
A model that handles only successful calls is not ready for regular use.
Compare write-action behaviour
For write tools, test whether the model:
- prepares a draft first;
- identifies the destination;
- preserves the record identifier;
- waits for explicit approval;
- changes only approved fields;
- handles partial writes;
- avoids repeated calls; and
- responds safely to a timeout.
Important write actions should remain under human review.
Compare local model advantages
A local model may be a better fit when:
- model processing must remain on the device;
- offline operation is required;
- the task is repeated often;
- the workflow is narrow and predictable;
- local hardware is sufficient;
- direct model control is important; or
- local sources and tools are already available.
A local model can also reduce dependence on remote model availability.
Compare local model limitations
A local model may be less suitable when:
- the hardware cannot run the required model;
- the task needs complex reasoning;
- long context is required;
- multi-tool selection is difficult;
- output must be highly consistent;
- several workflows compete for resources; or
- scheduled availability is hard to maintain.
Smaller local models may need shorter prompts and simpler flows.
Compare cloud model advantages
A cloud model may be a better fit when:
- the task requires stronger reasoning;
- several tools must be coordinated;
- long source material must be processed;
- structured output needs high reliability;
- local hardware is limited;
- large models are required; or
- the provider offers a model suited to the task.
Confirm that remote processing is appropriate for the information involved.
Compare cloud model limitations
A cloud model may be less suitable when:
- internet access is unavailable;
- the information must remain on-device;
- remote processing is not approved;
- provider availability is uncertain;
- network delay is unacceptable; or
- the workflow must operate in a fully local environment.
MCP tool location must still be reviewed separately.
Compare reliability over repeated runs
Run the same controlled test several times.
Record:
- model;
- provider;
- selected tool;
- tool input;
- number of calls;
- raw result;
- final answer;
- warnings;
- errors;
- total runtime; and
- result consistency.
One successful run is not enough.
Use Workbench for comparison
For each model:
- start a new conversation;
- enable the same MCP tool;
- use the same prompt;
- use the same sample input;
- open Activity;
- review tool parameters;
- compare raw output; and
- compare the final answer.
Change only the model.
Use Studio for comparison
Build a small flow:
Input
→ LLM with MCP Tool
→ Output
Run it with each candidate model.
Keep unchanged:
- MCP server;
- tool;
- input;
- instruction;
- permissions;
- source;
- output requirements; and
- workflow connections.
Use Emit blocks
Add an Emit block after the MCP result.
For example:
Input
→ MCP Tool Step
→ Emit Raw Result
→ Model Interpretation
→ Output
This makes it easier to compare whether each model preserves the same source data.
Compare through RunFlows
Test the saved flow in RunFlows.
Compare:
- total runtime;
- tool selection;
- tool parameters;
- returned data;
- warnings;
- errors;
- final output; and
- external action when relevant.
Use several runs for a dependable comparison.
Create a comparison table
A practical comparison may look like:
| Check | Local model | Cloud model |
|---|---|---|
| Correct tool selected | Yes | Yes |
| Exact values preserved | Mostly | Yes |
| Empty result handled | Yes | Yes |
| Repeated calls | One repeated call | None |
| Offline use | Yes | No |
| Model processing location | Local device | Remote provider |
| Hardware demand | High | Lower local demand |
| Total runtime | 20 seconds | 11 seconds |
Choose according to the task's priorities.
Compare privacy with the real MCP server
Do not compare privacy using the model alone.
Include:
- model location;
- MCP server location;
- source location;
- connected service;
- destination;
- logs;
- saved results; and
- authentication.
A local model with a remote tool may send less information remotely than a cloud model, but it is not fully local.
Compare local hardware use
Test the local model while other normal applications are open.
Watch for:
- memory pressure;
- slow responses;
- delayed tool calls;
- model-loading failures;
- application instability;
- thermal slowdown; and
- workflow conflicts.
A model that works only on an otherwise idle computer may not suit regular operations.
Compare internet dependence
Test what happens when the network is unavailable.
A local-model task may continue when:
- the model is downloaded;
- the model runner is active;
- the MCP server is local;
- the source is local; and
- the destination is local.
A cloud model cannot complete its inference without access to the provider.
Compare scheduled use
Scheduled local-model workflows require:
- the computer to remain on;
- Feluda to remain available;
- the local model server to run;
- the model to be installed;
- the MCP server to run;
- enough hardware capacity; and
- all sources and destinations to remain available.
Scheduled cloud-model workflows require:
- internet access;
- provider availability;
- valid provider authentication;
- MCP server availability;
- source availability; and
- destination availability.
Test both with a one-time schedule before regular automation.
Compare mixed-model workflows
Feluda can use local and cloud models in the same workflow.
For example:
Local Model
→ Prepare or Redact Input
→ MCP Retrieval
→ Cloud Model
→ Final Analysis
Or:
MCP Retrieval
→ Local Model Extracts Fields
→ Cloud Model Prepares Report
Review exactly what moves between blocks.
Local processing in one step does not make later cloud processing local.
Use local models for focused steps
A local model may work well for:
- redaction;
- field extraction;
- simple classification;
- short summaries;
- local file processing; or
- narrow tool calls.
Test every sensitive transformation before relying on it.
Use cloud models for demanding steps
A cloud model may be useful for:
- complex synthesis;
- long-context analysis;
- ambiguous tool selection;
- multi-source comparison;
- detailed reports; or
- difficult reasoning.
Send only the information needed for that step.
Do not use an unreviewed fallback
A workflow should not silently switch from a local model to a cloud model.
If fallback is allowed, make it visible.
Confirm:
- why the fallback occurred;
- what information will be sent;
- which provider will receive it;
- whether the fallback is approved; and
- whether the user should confirm first.
When local processing is required, return an error instead of using an unapproved remote model.
Choose by workflow stage
You do not need to use one model for every part of the workflow.
Choose the best fit for each stage.
For example:
| Workflow stage | Possible model choice |
|---|---|
| Sensitive source preparation | Local model |
| Simple field extraction | Local model |
| Complex comparison | Cloud model |
| Final local formatting | Local model |
| High-impact approval | Human review |
Keep the complete data path visible.
Re-test after model changes
A model update can change:
- tool selection;
- parameter formatting;
- exact-value handling;
- structured output;
- error handling;
- speed;
- context use; or
- repeated-call behaviour.
Repeat the same MCP test after an important model change.
Re-test after MCP changes
A server or tool update can change:
- tool names;
- descriptions;
- required fields;
- result structure;
- permissions;
- warnings; or
- errors.
Re-test both local and cloud candidates when the tool changes.
A practical comparison routine
Use this process:
- Define the real MCP task.
- Identify privacy and offline requirements.
- Identify required tool behaviour.
- Choose one suitable local model.
- Choose one suitable cloud model.
- Use the same MCP server and tool.
- Use the same prompt and sample input.
- Review Workbench Activity.
- Compare raw results with final answers.
- Test empty results and errors.
- Test structured output.
- Test write actions separately.
- Compare speed and consistency.
- Review hardware and network dependence.
- Test in Studio and RunFlows.
- Test scheduled use last.
- Record the result and chosen model.
The best model is the one that performs the full MCP task reliably while meeting the workflow's privacy, hardware, speed, and availability needs.