Connect an MCP Server

Connect an MCP Server

Feluda includes a built-in MCP server and can also connect to compatible external MCP servers.

An external MCP connection can make additional tools available in Workbench and Studio.

Those tools may help Feluda:

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

Connect only servers that you understand and trust.

Before you begin

Collect the information provided by the MCP server owner.

You may need:

• a clear server name;
• the endpoint URL;
• the required authentication method;
• an account or access credential;
• information about the tools it provides;
• the expected permissions;
• any network requirements; and
• a safe test task.

Do not guess connection details.

Use the official information supplied by the server owner or your organisation.

Review the server first

Before adding the connection, confirm:

• who operates the server;
• why the connection is needed;
• which tools it provides;
• what information those tools may receive;
• whether any tool can create, change, send, or remove information;
• where the server is hosted;
• whether authentication is required;
• who maintains the server; and
• whether its privacy and security practices fit your work.

Do not connect an unknown server only because it offers a useful-looking tool.

Understand the endpoint URL

The endpoint URL tells Feluda where the MCP server can be reached.

It may point to:

• a service running on your computer;
• another device on your local network;
• an internal organisational service; or
• an online service.

Copy the endpoint exactly as provided.

A missing character, incorrect port, or wrong path can prevent the connection from working.

Local and remote endpoints

A local endpoint usually connects to a service running on your own computer.

A remote endpoint connects across a network.

The difference matters because a remote server may receive information outside your device.

Before using sensitive information, confirm:

• where the server runs;
• where its tools send data;
• whether another service is involved;
• whether the information is stored; and
• whether the connection is approved for the task.

A local AI model does not make a remote MCP connection local.

Protect authentication details

Some MCP servers require an access key, token, account, or another form of authentication.

Store private values only in the protected settings intended for them.

Do not paste credentials into:

• Workbench messages;
• workflow instructions;
• Journal entries;
• normal notes;
• source files; or
• public documentation.

Use Feluda Secrets or the protected authentication fields provided by the connection setup.

Step 1: Open MCP Servers

Open Feluda.

Select MCP Servers from the Dashboard sidebar.

The MCP Servers page shows the available connections and the controls for adding an external server.

Feluda's built-in MCP server may also be shown in this area.

Do not remove or change the built-in connection unless you understand the effect on your available tools.

Step 2: Add a server

Select the option to add a new MCP server.

A setup form opens.

Enter the connection information supplied by the server owner.

This normally includes:

• server name;
• endpoint URL; and
• authentication details when required.

Additional fields may appear depending on the server and Feluda version.

Step 3: Choose a clear name

Use a name that explains what the connection is for.

Good examples include:

• Internal Knowledge Server;
• Customer Records MCP;
• Project Files MCP;
• Research Tools Server; or
• Support Operations MCP.

Avoid names such as:

• Server 1;
• Test;
• New MCP;
• External; or
• Connection.

A clear name makes it easier to identify the source of tools later.

Step 4: Enter the endpoint URL

Copy the endpoint URL exactly.

Check:

• the protocol;
• the server name or address;
• the port;
• the path;
• capitalisation where relevant; and
• whether a trailing slash is required.

Do not add spaces before or after the URL.

When the endpoint points to a local service, make sure that service is already running.

Step 5: Add authentication when required

Complete the authentication fields provided by the server owner.

Depending on the server, this may involve:

• an access token;
• an API key;
• an account sign-in;
• a protected header value; or
• another supported method.

Use the least access required for the task.

Prefer read-only or limited access when the tools only need to retrieve information.

Step 6: Save the connection

Review the entered details.

Confirm:

• the name is clear;
• the endpoint is correct;
• authentication values are in protected fields;
• the intended server is being connected;
• no unnecessary permission has been granted; and
• the connection is appropriate for the information it may receive.

Save the server.

Feluda will attempt to use the saved connection and discover the tools it provides.

Step 7: Check the connection state

Review the server after saving.

Look for information showing whether it is:

• connected;
• available;
• unavailable;
• waiting for authentication; or
• returning an error.

The exact wording may vary.

If the server is not available, read the complete error before editing the connection.

Step 8: Review the discovered tools

A successful connection may provide one or more tools.

Review every tool before enabling it.

Check:

• the tool name;
• what it does;
• what input it expects;
• what information it may receive;
• what result it returns;
• whether it reads or writes;
• which destination it uses; and
• whether the action can be reversed.

Do not assume that all tools from one server have the same level of risk.

Step 9: Confirm the tools in Workbench

Open Workbench.

Choose a provider and model that support tool use.

Open the Tools selector.

Look for the tools provided by the new MCP server.

They should appear alongside other available tools, including tools supplied by Genes.

If they do not appear, return to the MCP Servers page and review the connection.

Step 10: Test one read tool

Begin with one simple read-only tool when possible.

Use non-sensitive sample information.

For example:

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

Return:
1. the main steps;
2. the source details returned by the tool; and
3. any missing or uncertain information.

Do not create or change anything.

Enable only the tool needed for the test.

Step 11: Review the Activity log

After the model responds, open the Workbench Activity log.

Confirm:

• which tool was called;
• what input was sent;
• what result was returned;
• whether the call completed;
• whether a warning appeared; and
• whether an error occurred.

Compare the model's final answer with the actual tool result.

A polished answer can still misrepresent the returned information.

Step 12: Test the tool in Studio

After the Workbench test succeeds, you may add the tool to a workflow.

A simple workflow might look like:

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

Test the workflow with:

• normal input;
• missing information;
• unexpected input;
• an unavailable server;
• an empty tool result; and
• a tool error.

Keep the first workflow small.

Use a read-only test first

Read tools are safer for the first connection test because they retrieve information without intentionally changing a destination.

A read test helps you confirm:

• the server is reachable;
• authentication works;
• the tool appears;
• the selected model can call it;
• the returned format is understandable; and
• the Activity log records the request.

Test write tools only after the connection is understood.

Test write tools carefully

A write tool may:

• create a record;
• update an item;
• save a file;
• send a message;
• create a task; or
• remove information.

Before testing, confirm:

• the test destination;
• the exact item or record;
• the content;
• whether the action can be reversed;
• whether a test environment is available; and
• whether human approval is required.

Use non-sensitive sample data and a safe destination.

Use a draft-first process

For important write actions, ask the model to prepare the content without submitting it.

For example:

Prepare the customer-record update.

Show:
* the record that would be changed;
* the fields that would be updated;
* the new values; and
* the reason for the change.

Do not perform the update yet.

Review the draft.

Request the final action only after checking the destination and content.

Confirm write actions at the destination

After a write tool runs, inspect the connected service.

Check:

• the correct record;
• the correct account;
• the saved file;
• the sent message;
• the created task;
• the updated value; or
• the intended destination.

Do not rely only on the model's confirmation.

Avoid duplicate write actions

A timeout or delayed response may make a successful action appear to have failed.

Before retrying:

1. review the Activity log;
2. inspect the connected destination;
3. confirm whether the item already exists;
4. compare timestamps; and
5. retry only when the first action did not complete.

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

Test with the intended model

Models can differ in how reliably they use tools.

Test the connection with the model that will be used in regular work.

Review whether it:

• selects the correct tool;
• supplies the required fields;
• avoids unnecessary calls;
• understands the returned result;
• follows read-only instructions; and
• reports errors clearly.

Change the model only after confirming that the connection itself works.

Enable only the required tools

A server may expose several tools.

Enable only the tools needed for the current task.

This makes it easier to:

• understand model choices;
• reduce accidental actions;
• review permissions;
• identify errors; and
• keep the Activity log clear.

Add more tools only when the task genuinely requires them.

Review data sent to the server

Before regular use, check what information the tool receives.

This may include:

• search terms;
• document text;
• record identifiers;
• file paths;
• names;
• dates;
• structured fields; or
• user instructions.

Remove details that are not needed.

Do not send private information only because the tool accepts it.

Review server permissions

Use the narrowest access that supports the task.

When available, prefer:

• read-only access;
• limited accounts;
• approved destinations;
• restricted records;
• narrow source access; and
• separate test environments.

Broad access increases the effect of a wrong instruction or incorrect tool call.

Add the server to a workflow only after testing

A workflow can repeat a tool action faster and more consistently than a manual conversation.

That makes initial testing especially important.

Before adding the MCP tool to Studio, confirm:

• the server remains reachable;
• authentication is stable;
• the tool input is understood;
• the output format is consistent;
• errors are visible;
• write actions are reviewable; and
• the intended model uses it reliably.

Prepare for server errors

Add a clear error path when the workflow depends on the MCP server.

For example:

MCP Tool
→ Success → Continue Workflow
→ Error → Return Review Message

A useful error message might say:

The connected service could not be reached.
Review the MCP server connection before running the workflow again.

Do not hide a failed tool call behind a normal-looking output.

Prepare for empty results

A successful tool call may return no matching information.

Decide what the workflow should do.

It may:

• return "No matching information found";
• ask for a different search term;
• follow a human-review path;
• stop the workflow; or
• use another approved source.

Do not let the AI invent a result when the tool returns nothing.

If the server does not connect

Check:

• whether the endpoint URL is correct;
• whether the server is running;
• whether the network is available;
• whether authentication is complete;
• whether the port is reachable;
• whether a firewall blocks the connection;
• whether the service is temporarily unavailable; and
• whether Feluda needs to refresh the connection.

Correct one issue at a time.

Then test with a simple read action.

If authentication fails

Confirm:

• the credential is current;
• it was copied completely;
• it belongs to the correct server;
• it has the required permission;
• it has not expired;
• the account remains active;
• it is stored in the intended protected field; and
• the server owner has not changed the authentication method.

Do not paste the credential into a conversation to test it.

If tools do not appear

Check that:

• the server connection is saved;
• the server is available;
• authentication succeeded;
• the server actually exposes tools;
• the connection has refreshed;
• Workbench was reopened when needed;
• the Tools selector is showing the expected source; and
• the selected model supports tool use.

Return to the MCP Servers page and review any error.

If a tool appears but cannot be used

Review:

• tool permissions;
• required input;
• model compatibility;
• server availability;
• account access;
• the tool description;
• unsupported actions; and
• the returned error message.

Test the smallest supported request.

If the wrong tool is called

Disable unrelated tools.

Use a direct instruction such as:

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

Review tools with similar names.

Rename the server connection clearly so its tools are easier to identify.

If the returned data is wrong

Check whether:

• the correct server was connected;
• the correct tool was selected;
• the search or record input was accurate;
• filters were applied;
• the source is current;
• the tool returned complete data; and
• the model interpreted the result accurately.

Ask the model to show the returned fields separately from its own summary when accuracy matters.

If the connection works only sometimes

Intermittent problems may involve:

• an unstable network;
• a local server that stops;
• expired authentication;
• a remote service outage;
• a firewall;
• a changing endpoint;
• a slow tool;
• several workflows using the service at once; or
• a timeout that is too short.

Record when the problem occurs.

Compare manual and scheduled runs.

Use external tools in scheduled workflows carefully

A scheduled workflow may call an MCP server when no one is watching the live run.

Before scheduling it:

• test the connection repeatedly;
• confirm authentication;
• make server errors visible;
• handle empty results;
• prevent duplicate writes;
• review normal runtime;
• confirm the destination;
• avoid overlapping runs; and
• assign a reviewer.

External service availability can change after the schedule is created.

Monitor the connection over time

Review the server when:

• tools disappear;
• authentication expires;
• repeated errors appear;
• tool output changes;
• permissions change;
• a service is renamed;
• a workflow stops working; or
• the server owner announces an update.

Re-test dependent workflows after an important change.

Update connection details carefully

When the endpoint or authentication changes:

1. identify workflows that use the server;
2. pause related schedules;
3. update the connection;
4. test one read tool;
5. test required write tools safely;
6. review the Activity log;
7. test dependent workflows; and
8. resume schedules only after successful results.

Do not change a production connection without understanding what depends on it.

Remove an MCP server

Remove or disconnect a server when:

• it is no longer needed;
• it is no longer trusted;
• the service has been retired;
• another approved connection replaces it;
• the endpoint no longer exists; or
• repeated failures will not be repaired.

Before removal, check whether its tools are used by:

• Workbench users;
• Studio workflows;
• RunFlows;
• scheduled workflows; or
• Gene-provided flows.

Removing the connection makes its tools unavailable.

Final connection checklist

Before regular use, confirm that:

• the server owner is understood;
• the connection has a clear name;
• the endpoint is correct;
• authentication is protected;
• the server is reachable;
• the tools are visible;
• every tool's purpose is understood;
• read and write actions are distinguished;
• permissions are limited appropriately;
• sample tests succeed;
• the Activity log shows the expected calls;
• write actions are confirmed at their destination;
• errors and empty results are handled; and
• dependent workflows are known.

A successful connection makes tools available.

Careful testing confirms whether those tools are ready for real work.