Manage MCP Server Connections

Manage MCP Server Connections

MCP server connections should be reviewed over time.

A server may change its endpoint, authentication, permissions, tools, or availability.

Workflows may also begin to depend on tools that were not part of the original setup.

Managing MCP connections helps you:

• confirm that servers are still available;
• understand which tools they provide;
• update connection details safely;
• protect authentication values;
• identify dependent workflows;
• pause automation before important changes; and
• remove unused or untrusted servers.

Open MCP Servers

Select MCP Servers from the Feluda sidebar.

The page shows the MCP connections available to your Feluda setup.

These may include:

• Feluda's built-in MCP server; and
• compatible external MCP servers you added.

Review the connection list before changing anything.

Review the connection name

Each server should have a clear name.

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;
• External;
• Test;
• Connection; or
• New MCP.

A clear name helps users recognise which server provides a tool in Workbench and Studio.

Review the connection state

Check whether the server is shown as:

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

The exact wording may vary.

Read any warning or error before editing the connection.

A server may be unavailable because of the endpoint, authentication, network, local process, remote service, or permission settings.

Review the endpoint

Confirm that the saved endpoint still matches the official server details.

Check:

• the protocol;
• server name or address;
• port;
• path;
• spelling;
• capitalisation where relevant; and
• whether the server owner changed the endpoint.

Do not replace the endpoint with a guessed value.

Use the current details supplied by the server owner or your organisation.

Review authentication

Some external MCP servers require authentication.

Confirm that:

• the credential belongs to the correct server;
• the account remains active;
• the credential has not expired;
• the required permission is still included;
• the authentication method has not changed; and
• the value remains stored in the protected connection settings.

Do not move private values into prompts, notes, Journal entries, or workflow instructions.

Review the available tools

A server may add, remove, rename, or change tools over time.

Review:

• which tools are currently available;
• what each tool does;
• whether it reads or writes information;
• what input it expects;
• what result it returns;
• which service it affects; and
• which workflows use it.

Do not assume that an older tool remains available after a server update.

Review server trust

Keep only servers that you understand and trust.

Ask:

• Who operates the server?
• Why is it connected?
• Which tools does it provide?
• What information can those tools receive?
• Can any tool change or remove information?
• Where does the server run?
• Who maintains it?
• Are its privacy and security practices still suitable?

Disconnect a server when its purpose or trust level is no longer clear.

Identify dependent Workbench use

Some users may rely on the server's tools in Workbench.

Before changing or removing the connection, check:

• which tools are commonly enabled;
• which tasks depend on them;
• whether another server provides the same capability;
• whether instructions refer to the tool by name; and
• whether users need advance notice.

A connection change can make familiar tools disappear from the Tools selector.

Identify dependent workflows

Review Studio flows that use the server's tools.

For each flow, confirm:

• the workflow name;
• the MCP tool used;
• whether the tool is required or optional;
• whether an error path exists;
• whether the flow is used in RunFlows; and
• whether the flow is scheduled.

Record these dependencies before making a major connection change.

Identify scheduled use

A scheduled workflow may depend on the MCP server at a time when no one is watching the live run.

Before changing the connection:

• open Schedule Manager;
• identify dependent schedules;
• review their next-run times;
• pause them when appropriate;
• confirm external destinations; and
• assign someone to test the connection afterward.

Do not change an important connection immediately before a scheduled run.

Pause automation before major changes

Pause related schedules when changing:

• the endpoint;
• authentication;
• the server account;
• permissions;
• the tool list;
• the destination service; or
• the server itself.

Then test the updated connection manually.

Resume schedules only after Workbench and workflow tests succeed.

Update the endpoint safely

When the server owner provides a new endpoint:

1. identify dependent workflows and schedules;
2. pause related schedules;
3. copy the new endpoint exactly;
4. save the connection;
5. confirm the server becomes available;
6. review the discovered tools;
7. test one read-only tool;
8. test dependent workflows; and
9. resume automation only after successful results.

A new endpoint may expose a different tool list or result format.

Update authentication safely

When a credential expires or changes:

1. obtain the current value through the approved process;
2. pause dependent schedules;
3. update the protected authentication field;
4. save the connection;
5. confirm the server is available;
6. test one read action;
7. test required write actions carefully;
8. review Workbench Activity; and
9. resume dependent automation.

Never place the credential in a test prompt.

Review permissions after an update

A new account or credential may have different permissions.

Confirm whether the tools still have the intended:

• read access;
• write access;
• record access;
• file access;
• destination access;
• source access; and
• organisational restrictions.

Use the narrowest access required for the task.

Do not expand access only because a workflow failed.

First confirm that the requested source or destination is correct.

Test a read tool first

After any important connection change, begin with a simple read-only test.

For example:

Use the enabled Internal Knowledge Search tool.

Search for "MCP connection test".
Return only the information provided by the tool.
Do not create or change anything.

Review the Activity log.

Confirm that:

• the expected tool was called;
• the input was correct;
• a result was returned;
• no warning appeared; and
• the final answer matches the tool output.

Test write tools separately

A successful read test does not confirm that write permissions work.

Test each required write tool with:

• non-sensitive sample information;
• a safe destination;
• a reversible action when possible;
• a clear expected result; and
• direct destination review.

Confirm the result in the connected service.

Review Workbench after a change

Open Workbench and confirm that:

• the server's tools appear;
• the tool names are correct;
• the selected model can use them;
• the Activity log records the call;
• the returned format is expected; and
• no unrelated tool is selected.

Start a new conversation for a clean test.

Review Studio after a change

Open each dependent workflow in Studio.

Confirm that:

• the MCP tool still appears;
• the correct tool remains enabled;
• the selected model supports it;
• tool input still matches the required format;
• error paths remain connected;
• empty results are handled; and
• the final output is still useful.

Save the flow only after completing the review.

Review RunFlows after a change

Test the saved workflow through RunFlows.

Use non-sensitive sample input.

Review:

• the starting input;
• intermediate output;
• tool activity;
• warnings;
• errors;
• final output; and
• any external destination.

This confirms that the saved version works outside Studio.

Review scheduled workflows after a change

After manual tests succeed:

• check the schedule input;
• confirm the next-run time;
• confirm the server will be available;
• review normal runtime;
• check for conflicts;
• confirm destination names; and
• assign a reviewer for the first resumed run.

Monitor the first scheduled result closely.

Disable or pause use without removing the server

When available, disable the connection or stop using its tools when the server is temporarily unavailable or under review.

You may also:

• disable its tools in Workbench;
• remove them from LLM blocks;
• pause dependent workflows;
• pause schedules; or
• use an approved alternative connection.

Temporary control is often safer than immediate removal when dependencies are not fully known.

When to remove a server

Remove an external MCP server when:

• it is no longer needed;
• the service has been retired;
• the endpoint no longer exists;
• the server is no longer trusted;
• another approved connection replaces it;
• repeated failures will not be repaired; or
• no current workflow depends on its tools.

Do not remove Feluda's built-in MCP server unless you fully understand the effect on available tools.

Check dependencies before removal

Before removing a server, confirm whether its tools are used by:

• Workbench users;
• Studio workflows;
• saved RunFlows items;
• scheduled workflows;
• Gene-provided flows;
• Journal-writing processes; or
• other recurring tasks.

Update, replace, pause, or remove those dependencies first.

Remove the connection

When the server is ready to be removed:

1. pause related schedules;
2. stop active workflows that depend on it;
3. confirm no important write action is still running;
4. record the replacement plan when needed;
5. remove or disconnect the external server;
6. confirm its tools disappear from Workbench and Studio; and
7. test affected workflows for clear error handling.

Removing the connection does not automatically repair dependent flows.

Confirm what changed after removal

After removal, review:

• the MCP Servers page;
• the Workbench Tools selector;
• Studio workflows;
• RunFlows;
• Schedule Manager;
• external destinations; and
• user instructions that mention the removed tool.

Update documentation and workflow descriptions so users do not expect a tool that is no longer available.

Replace a server carefully

A replacement server may offer similar tools with different:

• names;
• inputs;
• outputs;
• permissions;
• authentication;
• destinations;
• limits; or
• error formats.

Do not treat it as a direct replacement until it has been tested.

Update dependent workflows one at a time.

Avoid duplicate connections

Two connections to the same server can cause:

• repeated tool names;
• model confusion;
• duplicate actions;
• unclear Activity logs;
• inconsistent authentication; and
• difficulty identifying the correct connection.

Use one clearly named connection unless separate accounts or permission levels are intentionally required.

Use separate connections when justified

Separate connections may be appropriate when:

• one account is read-only;
• another account has approved write access;
• teams use different destinations;
• test and production services are separate;
• privacy requirements differ; or
• organisational boundaries require separation.

Name each connection clearly.

For example:

• Customer Records MCP — Read Only;
• Customer Records MCP — Approved Writes;
• Project Service MCP — Test; or
• Project Service MCP — Production.

Keep test and production connections separate

A test server should not be mistaken for the live service.

Use clear names and safe destinations.

Confirm which environment a tool affects before every write action.

Test workflows against the intended environment before regular use.

Review connection ownership

Every external MCP connection should have a responsible owner.

The owner should know:

• why the server is connected;
• who operates it;
• which tools it provides;
• where authentication is managed;
• which workflows depend on it;
• how errors are reviewed;
• when schedules should be paused; and
• when the connection should be removed.

Unowned connections can become outdated without anyone noticing.

Review connections regularly

Use a regular review routine.

For each external server, confirm:

• the server is still needed;
• the endpoint is current;
• authentication remains valid;
• permissions remain appropriate;
• tools are understood;
• dependent workflows are known;
• scheduled use is still required;
• recent errors have been reviewed;
• privacy requirements are still met; and
• an owner remains responsible.

Review important or high-impact connections more often.

Review data paths

A connection may send information to:

• a local service;
• an internal server;
• a remote provider;
• a business system;
• a file service;
• a messaging service; or
• another connected destination.

Confirm what information leaves Feluda and where it goes.

A local AI model can still send information to a remote MCP server.

Review the complete path.

Review logs and activity

Workbench Activity and RunFlows output can show:

• tool names;
• input data;
• output data;
• warnings;
• errors; and
• repeated calls.

Use this information to identify whether a connection still behaves as expected.

Remove unnecessary sensitive details from test input.

Respond to repeated errors

Repeated errors may mean:

• the endpoint changed;
• authentication expired;
• the server is unstable;
• the tool was removed;
• permissions changed;
• a connected service changed;
• the result format changed; or
• the workflow expects outdated behaviour.

Pause dependent automation.

Correct the connection or update the workflow before resuming.

Respond to unexpected tool changes

When a tool is renamed or its result changes:

1. pause dependent schedules;
2. test the tool in Workbench;
3. compare the new input and output;
4. update Studio workflows;
5. review error and empty-result paths;
6. test in RunFlows; and
7. resume automation only after successful results.

A small server-side change can affect several flows.

Respond to a trust concern

If the server is no longer trusted:

• stop using its tools;
• pause dependent workflows;
• pause schedules;
• revoke or replace credentials when appropriate;
• review recent Activity;
• inspect important external actions;
• identify information that may have been sent; and
• remove the connection after dependencies are controlled.

Use an approved alternative only after testing it.

A practical management routine

Use this process:

1. Open MCP Servers.
2. Review each external connection.
3. Confirm endpoint and connection state.
4. Confirm authentication and permissions.
5. Review the current tool list.
6. Identify Workbench, Studio, RunFlows, and schedule dependencies.
7. Pause automation before major changes.
8. Update one connection detail at a time.
9. Test one read tool in Workbench.
10. Test required write tools safely.
11. Test dependent workflows in RunFlows.
12. Monitor the first resumed scheduled run.
13. Remove unused or untrusted servers.
14. Confirm dependent tools and workflows were updated.
15. Record who owns the connection.

Careful connection management keeps MCP tools available without leaving outdated or unnecessary access in place.