What are MCP Servers?

What are MCP Servers?

MCP servers connect Feluda to additional tools and information sources.

MCP stands for Model Context Protocol.

It is a shared way for an AI application to discover and use tools provided by another service.

In practical terms, an MCP server can make new capabilities available to an AI model in Feluda.

Depending on the server, those capabilities may help the model:

• retrieve information;
• search an approved source;
• work with files;
• use an internal service;
• access a business system;
• perform a supported action; or
• return structured data.

You remain responsible for deciding which servers to connect and which tools to make available.

Why MCP servers are useful

An AI model can write and reason about information in a conversation.

An MCP tool can give the model an approved way to interact with something outside that conversation.

For example, an MCP server might provide tools that can:

• search a knowledge source;
• look up a record;
• retrieve current information;
• create a note;
• read a supported file;
• use an internal API; or
• perform another defined task.

This lets you extend Feluda without placing every possible capability inside one application.

Feluda includes a built-in MCP server

Feluda includes a built-in MCP server.

It becomes available with the application and helps make Feluda tools accessible where they can be used.

As you add supported capabilities, their tools can become available in areas such as:

• Workbench;
• Studio; and
• RunFlows.

You do not need to connect an external MCP server to begin using Feluda.

External servers are optional additions for users who need other tools or services.

External MCP servers

Feluda can also connect to external MCP servers.

An external MCP server may be provided by:

• your organisation;
• a software service;
• an internal development team;
• a trusted third party;
• an open-source project; or
• another compatible tool provider.

Each server may expose a different set of tools.

Connecting the server does not mean every tool should be used for every task.

Review the server and its tools before enabling them.

MCP servers and tools are different

An MCP server is the connection point.

A tool is one capability provided through that connection.

For example, one MCP server might provide tools for:

• searching documents;
• reading a customer record;
• creating a task; and
• checking a service status.

The server can provide several tools, while each tool has its own purpose.

Review tools individually.

Do not assume that trusting one tool means every tool on the server is suitable for your work.

MCP servers and Genes are different

Genes and MCP servers can both add capabilities to Feluda, but they are not the same.

Capability	Main role
Gene	An installable Feluda package that may include tools, prompts, flows, resources, and settings
MCP server	A connected service that makes compatible tools available to Feluda

A Gene may provide its own tools.

An MCP server may provide tools from another service.

Tools from both sources can appear together in the parts of Feluda where they are supported.

MCP servers and AI models are different

An MCP server is not an AI model.

The AI model understands the instruction and prepares a response.

The MCP server provides tools the model may call.

A simple way to understand the roles is:

• AI model: interprets the task and prepares language or reasoning;
• MCP server: makes compatible tools available;
• tool: performs one defined action;
• Feluda: brings the model, tools, and your workflow together.

You still need a supported AI model when the task requires AI.

Where MCP tools can appear

After a server is connected and its tools are discovered, they may become available in:

• Workbench conversations;
• Studio workflow steps; and
• saved workflow runs.

The exact availability depends on:

• the connected server;
• the tools it provides;
• the selected model;
• the workflow;
• your settings; and
• whether the server is currently reachable.

A connected server does not guarantee that every model can use every tool correctly.

Test the intended combination.

Use MCP tools in Workbench

In Workbench, an MCP tool may be enabled for a conversation.

A simple process is:

1. select the AI provider and model;
2. open the Tools selector;
3. find the MCP-provided tool;
4. review its name and description;
5. enable only the tool needed for the task;
6. give the model a clear instruction; and
7. review the Activity log.

The Activity log helps you confirm whether the tool was called and what it returned.

Use MCP tools in Studio

An MCP tool can also support a repeatable workflow.

For example:

Input
→ Retrieve Information with MCP Tool
→ Summarise with AI
→ Output

Or:

Input
→ Check Record
→ Prepare Update
→ Human Review
→ Write Action

Test the tool in Workbench before placing it into a repeated workflow.

This helps you understand its input, output, limits, and errors.

A simple MCP example

Imagine that your organisation has an approved internal knowledge service.

Its MCP server may provide a search tool.

In Workbench, you could ask:

Use the enabled knowledge-search tool to find information about the
current onboarding process.

Return:
1. a short summary;
2. the relevant steps;
3. the source details returned by the tool; and
4. any missing or uncertain information.

Then review:

• whether the correct tool was used;
• whether the expected source was searched;
• what the tool returned; and
• whether the model summarised it accurately.

Read and write tools

MCP tools may perform different types of actions.

A read tool retrieves or views information.

A write tool creates, changes, sends, or removes information.

Read tools may:

• search;
• retrieve;
• inspect;
• list; or
• compare information.

Write tools may:

• create a file;
• update a record;
• send a message;
• create a task;
• save a note; or
• change something in a connected service.

Write tools require extra care.

Review write actions carefully

Before asking an MCP tool to perform a write action, confirm:

• the destination;
• the account;
• the record or file;
• the content;
• the recipient;
• whether the action can be reversed; and
• whether human approval is needed.

When possible, ask the model to prepare a draft first.

Review the draft before requesting the final action.

Understand tool descriptions

Each tool should have a clear purpose.

Review:

• what the tool does;
• what input it expects;
• what result it returns;
• whether it reads or writes;
• which service it uses;
• what information it may receive; and
• what limits apply.

Do not enable a tool only because its name sounds relevant.

Read the full description and test it with a simple example.

Review server trust

An MCP connection can expose tools from another service.

Before connecting an external server, ask:

• Who operates the server?
• Why is it needed?
• Which tools does it provide?
• What information can those tools receive?
• Can any tool change or remove information?
• Does the server require authentication?
• Where is the server hosted?
• Are its privacy and security practices suitable?
• Who is responsible for maintaining it?

Use servers from sources you understand and trust.

Review privacy before connecting

A tool may send task information to the connected MCP server.

That information may include:

• search terms;
• document content;
• record identifiers;
• file details;
• user-provided text;
• structured fields; or
• other information required by the action.

Before using sensitive information, confirm:

• what the server receives;
• where it processes the information;
• whether another service is involved;
• whether the data is stored;
• whether unnecessary details can be removed; and
• whether the connection fits your privacy requirements.

A local AI model does not make an external MCP tool local.

Local and remote MCP servers

An MCP server may run:

• on your own computer;
• on another device in your network;
• inside your organisation; or
• through an online service.

A local server can reduce external data movement when its tools and sources are also local.

A remote server requires a network connection and may send information outside your computer.

Review the complete path rather than relying only on the server name.

Authentication

Some external MCP servers require authentication.

This may involve:

• an account;
• an access token;
• an API key;
• a sign-in process; or
• another approved credential.

Store private values only in the intended protected settings.

Do not paste passwords, API keys, access tokens, or private connection values into:

• Workbench messages;
• workflow instructions;
• Journal entries;
• source documents; or
• normal notes.

Keep access limited

Give the connection only the access required for the task.

When the server or service supports it, prefer:

• read-only access for retrieval tasks;
• limited accounts;
• narrow permissions;
• approved destinations;
• restricted sources; and
• separate test environments.

Do not use broad access when a smaller permission set is sufficient.

Test with non-sensitive information

Use a simple test after connecting a server.

Confirm that:

• the server is reachable;
• its tools appear;
• the intended tool can be selected;
• the selected model can use it;
• the Activity log records the call;
• the result has the expected format; and
• no unintended action occurs.

Use sample data until you understand the tool's behaviour.

Review the Activity log

In Workbench, the Activity log can help you see:

• which tool was called;
• the input passed to it;
• the output it returned;
• whether the action completed;
• whether a warning appeared; and
• whether an error occurred.

Do not rely only on the model's statement that the tool succeeded.

Review the actual recorded activity.

Confirm results at their destination

When an MCP tool creates or changes something, inspect the connected service.

For example:

• open the created record;
• check the saved file;
• review the sent message;
• confirm the task;
• inspect the updated item; or
• verify the correct destination.

A successful call does not guarantee that the correct content was used.

Avoid duplicate actions

A delayed response or timeout may make a successful write look like a failure.

Before retrying:

1. check the tool activity;
2. inspect the destination;
3. confirm whether the item already exists;
4. review the connected service; and
5. retry only when the first action did not complete.

This helps prevent duplicate records, messages, files, or tasks.

Use one tool at a time when learning

Enable one MCP tool for the first test.

This makes it easier to understand:

• why the model selected it;
• what input it received;
• what it returned;
• which permission it used; and
• where an error occurred.

Add more tools only when the task genuinely needs them.

Use clear instructions

Tell the model:

• what you want to achieve;
• which tool should be used;
• which information is relevant;
• what output you expect;
• what limits apply; and
• whether an action should be performed or only drafted.

For example:

Use the enabled record-search tool to find the item with reference
number 48321.

Return the item name, status, owner, and last update date.
Do not change the record.

The final sentence makes the read-only intention clear.

Ask for confirmation before important actions

For a high-impact write task, use a two-step process.

First ask:

Prepare the update that would be sent to the connected service.
Do not submit it yet.

Review the prepared content.

Then ask for the final action only after confirming:

• the destination;
• the content;
• the recipient or record;
• the timing; and
• the consequences.

MCP errors

An MCP tool may fail because:

• the server is unavailable;
• the endpoint is incorrect;
• authentication is missing;
• a credential expired;
• the network is unavailable;
• the requested action is unsupported;
• required input is missing;
• access is denied;
• the connected service is unavailable; or
• the tool returned an unexpected result.

Read the complete error message before changing the connection.

If the server is unavailable

Check:

• whether the server is running;
• whether the connection address is correct;
• whether the network is available;
• whether authentication is still valid;
• whether a firewall or network rule blocks access;
• whether the remote service is online; and
• whether Feluda needs to refresh the connection.

Test the server with a small request after correcting the issue.

If tools do not appear

Confirm that:

• the server was added;
• the connection is active;
• Feluda can reach it;
• authentication is complete;
• the server provides tools;
• the tool list has been refreshed;
• the selected area supports the tool; and
• the model supports the required tool use.

Reopen the Tools selector after refreshing.

If the wrong tool is used

Reduce the number of enabled tools.

Then make the instruction more direct.

For example:

Use only the enabled customer-record search tool.
Do not call any write or update tool.

Review the tool descriptions for overlapping purposes.

Disable tools that are unrelated to the task.

If the result is incorrect

Check whether:

• the correct server was used;
• the correct tool was selected;
• the tool input was accurate;
• the source was current;
• the returned data was complete;
• the model interpreted the result correctly; and
• another source should be checked.

When accuracy matters, ask the model to separate:

• the raw tool result; and
• its own explanation or summary.

MCP tools in scheduled workflows

A scheduled workflow can use an MCP tool when the connection and all required services remain available at run time.

Before scheduling:

• test the tool manually;
• confirm authentication;
• review the source and destination;
• make errors visible;
• prevent duplicate write actions;
• understand normal runtime;
• check network requirements; and
• assign a reviewer.

A tool that works during a manual test may still fail later if the external service becomes unavailable.

Monitor connected services

External services can change.

Review MCP connections when:

• tools disappear;
• authentication expires;
• output format changes;
• repeated errors appear;
• the service changes its permissions;
• the organisation changes accounts;
• a tool is renamed; or
• the workflow no longer produces the expected result.

Re-test dependent workflows after an important server or tool change.

Remove unused connections

Disconnect or remove an MCP server when:

• it is no longer needed;
• the provider is no longer trusted;
• the service has been retired;
• the connection repeatedly fails;
• another approved server replaces it; or
• no workflow depends on its tools.

Before removal, check whether:

• Workbench users rely on the tools;
• Studio workflows use them;
• scheduled workflows depend on them;
• the connection contains required settings; and
• an alternative has been tested.

Removing the server may make its tools unavailable.

MCP server checklist

Before using an external MCP server, confirm that:

• you understand who provides it;
• its purpose is clear;
• the connection details are correct;
• authentication is protected;
• the available tools are understood;
• permissions are limited appropriately;
• sensitive information has been considered;
• the server has been tested with sample data;
• write actions are reviewable;
• errors are visible; and
• dependent workflows are known.

MCP servers can extend Feluda with useful capabilities.

Careful connection and tool review keep those capabilities understandable and controlled.