Retire an MCP Server

Retire an MCP Server

Retiring an MCP server means ending its use in Feluda and removing the access, workflows, schedules, and documentation that depend on it.

A server may need to be retired because:

• the service is no longer needed;
• the server is being shut down;
• another server has replaced it;
• the provider is no longer approved;
• the tools are no longer maintained;
• the connection is unreliable;
• permissions are too broad;
• the source system has changed; or
• the organisation no longer trusts the service.

Do not remove the connection before identifying what depends on it.

Retirement is more than disconnection

Removing the server from MCP Servers is only one step.

A complete retirement may also require:

• pausing schedules;
• replacing or removing tools in Studio;
• updating Workbench instructions;
• reviewing RunFlows items;
• revoking credentials;
• removing external permissions;
• preserving required records;
• deleting temporary test data;
• updating documentation; and
• confirming that no hidden dependency remains.

Plan the retirement as a controlled change.

Decide whether the server is being replaced

First determine whether the server will be:

• replaced by another MCP server;
• replaced by a built-in Feluda capability;
• replaced by a Gene;
• replaced by a manual process;
• replaced by another approved service; or
• removed without replacement.

The answer determines how dependent workflows should be handled.

Define the retirement outcome

A successful retirement should confirm that:

• no active workflow depends on the server;
• no schedule calls its tools;
• no user instruction refers to old tool names;
• no important write action is still running;
• required records are preserved;
• credentials are revoked or rotated;
• external access is removed;
• the connection is deleted;
• old tools no longer appear; and
• the replacement or shutdown process is documented.

Write down these conditions before starting.

Assign a retirement owner

One person or team should coordinate the retirement.

The owner should know:

• why the server is being retired;
• who operates it;
• which tools it provides;
• which workflows depend on it;
• which schedules use it;
• where credentials are managed;
• what information must be preserved;
• whether a replacement exists; and
• who approves final removal.

This reduces the chance that a dependency is missed.

Record the current connection

Before making changes, record:

• server name;
• endpoint;
• local or remote location;
• authentication method;
• account owner;
• available tools;
• read and write permissions;
• important sources;
• important destinations;
• dependent workflows;
• dependent schedules;
• known-good tests; and
• last successful use.

Do not record raw passwords, tokens, keys, or private headers.

Inventory the tool list

For every tool, record:

• tool name;
• purpose;
• whether it reads or writes;
• required input;
• returned output;
• connected source;
• destination;
• permissions;
• workflows that use it;
• schedules that use it; and
• whether a replacement exists.

This becomes the retirement checklist.

Search for Workbench dependencies

Users may refer to old tools in:

• saved prompts;
• copied instructions;
• team guides;
• onboarding material;
• Journal notes;
• support documentation; or
• repeated Workbench tasks.

Search for:

• the server name;
• old tool names;
• old source names;
• old destination names; and
• old example prompts.

Update or remove every reference.

Search for Studio dependencies

Open important Studio workflows.

Check each LLM block for:

• selected MCP tools;
• prompts that name the old tool;
• input mappings;
• output mappings;
• permissions;
• no-result paths;
• error paths;
• write-action steps; and
• destination references.

A workflow may still depend on the server even when the tool name is not visible in the flow title.

Search RunFlows

Review saved flows and recent runs.

Confirm:

• which flows called the server;
• whether users still run them manually;
• whether old results need to be preserved;
• whether errors already show missing-tool problems; and
• whether replacement flows are available.

Disable or retire obsolete flows clearly.

Search Schedule Manager

Open Schedule Manager.

Record every schedule that uses a dependent workflow.

Include:

• schedule name;
• workflow;
• frequency;
• next-run time;
• source;
• destination;
• write action;
• reviewer; and
• replacement status.

Pause these schedules before removing the server.

Search Gene-provided flows

An installed Gene may include prompts, tools, or flows that depend on the server.

Confirm whether:

• the Gene still needs the server;
• a replacement version exists;
• the flow can be updated;
• the Gene should be removed;
• a resync is required; or
• the dependency is documented elsewhere.

Do not remove a server before checking reusable Gene content.

Identify external dependencies

The server may connect Feluda to:

• a business application;
• a database;
• cloud storage;
• a local file service;
• messaging;
• a project system;
• an internal API;
• a local application; or
• another provider.

Confirm whether those external systems still expect traffic from the server.

Identify write actions

Give special attention to tools that:

• create records;
• update records;
• send messages;
• save files;
• write Journal entries;
• change statuses;
• move items; or
• delete information.

Stop or complete important writes before retirement.

Check for active work

Before pausing or removing anything, review:

• active Workbench tasks;
• running RunFlows items;
• pending tool calls;
• scheduled runs already in progress;
• delayed remote writes;
• local file operations; and
• external service queues.

Do not retire the server while a critical write action may still complete.

Pause schedules

Pause every dependent schedule before changing workflows or the connection.

Confirm that:

• no new run will start;
• the next-run time is noted;
• the replacement plan is known;
• the destination is understood; and
• a reviewer is assigned.

Leave schedules paused until the replacement or shutdown is fully verified.

Decide what must be preserved

Some information may need to be kept after the server is gone.

This can include:

• important workflow output;
• Journal entries;
• audit records;
• source identifiers;
• final reports;
• migration decisions;
• tool mappings;
• permission records;
• incident records; or
• proof of final revocation.

Preserve only what is required.

Preserve important output

Review whether important results exist only in:

• the connected service;
• local output folders;
• the Journal;
• RunFlows history;
• generated files;
• database records; or
• server logs.

Export or back up required information before the source becomes unavailable.

Preserve configuration records

Keep a non-secret record of:

• server purpose;
• endpoint;
• tool list;
• account owner;
• permission scope;
• workflow dependencies;
• replacement mapping;
• retirement date; and
• final verification.

This helps explain historical workflows later.

Do not preserve unnecessary secrets

Do not copy raw:

• passwords;
• API keys;
• access tokens;
• private headers;
• client secrets; or
• database credentials

into retirement records or ordinary archives.

Record the revocation method instead.

Back up before removal

Create or confirm a current backup when the server affects important local data.

The backup may include:

• Feluda user data;
• Studio workflows;
• Journal entries;
• local source files;
• local databases;
• important output;
• configuration records; and
• recovery documentation.

Test the backup before relying on it.

Choose the replacement path

If a replacement exists, map each old tool to the new capability.

Retired tool	Replacement	Required action
Search Records	Find Records	Update tool name and field mapping
Update Record	Modify Record	Retest approval and write destination
Save Report	Local File Writer	Update path and permission rules

Do not assume similar names mean identical behaviour.

Test the replacement before retirement

Keep the old server available during replacement testing when possible.

Confirm that the replacement:

• returns the required information;
• preserves important fields;
• handles no matches;
• reports errors;
• uses approved permissions;
• writes to the correct destination;
• prevents duplicates;
• works in Studio;
• works in RunFlows; and
• works on schedule.

Retire the old server only after the replacement is dependable.

Update Workbench guidance

Replace old instructions with the new tool name or new process.

For example, replace:

Use the Customer Record Search tool.

with:

Use only the enabled Find Customer Record tool.

Remove outdated examples that would cause users to select the retired tool.

Update Studio workflows

For each dependent workflow:

1. pause its schedule;
2. create or confirm a backup copy;
3. replace or remove the old tool;
4. update the prompt;
5. update input fields;
6. update output fields;
7. update permissions;
8. update no-result handling;
9. update error handling;
10. test in Studio; and
11. test the saved flow in RunFlows.

Update one workflow at a time.

Remove the tool without replacement

When no replacement is needed, decide whether to:

• remove the tool step;
• retire the whole workflow;
• replace the workflow with a manual process;
• return a clear unavailable message; or
• archive the flow for historical reference.

Do not leave a broken tool block in an active workflow.

Update workflow descriptions

A workflow description should explain:

• that the server is retired;
• whether the workflow was replaced;
• which new flow should be used;
• whether the flow is archived;
• whether results remain historical only; and
• who owns the replacement.

This prevents users from trying to run an obsolete process.

Test no-tool behaviour

When a workflow loses the retired tool, confirm that it does not:

• invent a result;
• silently use another unapproved source;
• call an unrelated tool;
• continue to a write action;
• return an old cached result as current; or
• present a normal success message.

Use a clear stop or review message.

Update error paths

A useful message may say:

This workflow used a retired MCP service and is no longer available.
Use the replacement workflow or contact the workflow owner.

Do not expose internal connection details unnecessarily.

Update permissions

Remove permissions that existed only for the retired server.

Review:

• URL allowlists;
• IP allowlists;
• path permissions;
• port permissions;
• account access;
• project access;
• file access;
• destination access; and
• write access.

Removing the server connection does not always remove external permissions.

Remove account access

If the retired server used a dedicated account, determine whether to:

• disable the account;
• remove project access;
• remove workspace access;
• remove database access;
• remove file access;
• remove administrator rights; or
• delete the account according to policy.

Confirm that no other approved process uses the same account.

Revoke credentials

Removing a connection from Feluda may not revoke the credential at the external service.

Revoke or rotate:

• access tokens;
• API keys;
• passwords;
• protected headers;
• database credentials; or
• other service credentials

through the approved service process.

Verify credential revocation

After revocation, confirm that:

• the old account can no longer authenticate;
• the old key is no longer accepted;
• the retired endpoint cannot use the credential;
• no schedule still depends on it;
• no shared workflow uses it; and
• the revocation is recorded.

Do not test by exposing the secret in a prompt.

Remove network access

Remove rules that were needed only for the retired server.

This may include:

• firewall rules;
• VPN access;
• proxy rules;
• DNS entries;
• URL permissions;
• IP permissions;
• port access; or
• local-network routes.

Confirm that no other approved service needs the same rule.

Remove local service startup

For a local server, disable unnecessary startup behaviour.

Review:

• automatic service startup;
• login startup;
• scheduled startup tasks;
• desktop application startup;
• background processes; and
• local database dependencies.

Stop the service only after all dependent workflows are controlled.

Remove local files carefully

A local MCP server may have:

• configuration files;
• logs;
• caches;
• indexes;
• downloaded packages;
• temporary files;
• local databases; or
• output folders.

Decide what must be archived and what can be deleted.

Do not delete shared source data without confirming ownership.

Handle local databases

Before removing a local database:

• identify every user;
• identify every workflow;
• create a valid backup;
• test restoration;
• export required records;
• stop writes;
• stop the database service; and
• confirm final approval.

Database retirement may require a separate organisational process.

Archive only what is needed

An archive may preserve:

• final configuration record;
• workflow mapping;
• retirement approval;
• migration record;
• important logs;
• final audit output; and
• recovery instructions.

Avoid archiving unnecessary sensitive data.

Label archived workflows

Use clear names such as:

ARCHIVED — Customer Records via Retired MCP

Or:

RETIRED — Local File Search — Replaced June 2026

Remove schedules and write permissions from archived flows.

Archived flows should not look active.

Remove old saved prompts

Search for prompts that mention:

• retired server name;
• retired tool names;
• old endpoint;
• old source;
• old destination;
• old field names; or
• old process instructions.

Update or delete them.

Update user documentation

Update:

• help articles;
• internal guides;
• onboarding instructions;
• workflow descriptions;
• tool examples;
• troubleshooting steps;
• screenshots; and
• service-owner records.

Clearly identify the replacement when one exists.

Inform affected users

Users should know:

• retirement date;
• affected tools;
• affected workflows;
• replacement process;
• new tool names;
• changed output or permissions;
• where to report problems; and
• whether old results remain available.

Avoid announcing completion before the replacement is verified.

Run final tests before removal

Confirm that:

• replacement read workflows work;
• replacement write workflows work;
• RunFlows output is correct;
• one-time schedules succeed;
• external destinations are correct;
• old workflows are paused or archived;
• users can find the replacement; and
• rollback is no longer needed.

Confirm no rollback is needed

Keep the old server available during an agreed rollback period when possible.

End the rollback period only after:

• required workflows are stable;
• required schedules have completed successfully;
• users have adopted the replacement;
• no important field is missing;
• no unexpected write behaviour appears; and
• no unresolved incident remains.

Remove the connection from Feluda

When every dependency is controlled:

1. confirm no active old-server call is running;
2. confirm all schedules are paused or migrated;
3. confirm credentials are ready for revocation;
4. confirm required records are preserved;
5. remove or disconnect the server in MCP Servers;
6. reopen Workbench;
7. reopen affected Studio workflows; and
8. confirm old tools no longer appear.

Confirm tool removal

Review:

• MCP Servers;
• Workbench Tools;
• Studio LLM blocks;
• RunFlows;
• Schedule Manager;
• saved prompts;
• Gene-provided flows; and
• documentation.

No active process should still expect the retired tool.

Test retired workflows

Run only safe checks.

Confirm that an old workflow:

• is clearly archived;
• cannot reach the retired server;
• does not call another tool silently;
• does not continue to a write step;
• shows a clear retirement message; and
• points users to the replacement when available.

Review external service activity

After retirement, inspect the old service.

Confirm that:

• no new tool calls appear;
• no new writes appear;
• no scheduled activity continues;
• revoked credentials remain inactive;
• old accounts are disabled when required; and
• the provider no longer receives Feluda traffic.

Monitor after retirement

Review the first normal work period after removal.

Look for:

• missing-tool errors;
• failed schedules;
• user reports;
• old prompt usage;
• unexpected fallback;
• incorrect replacement results;
• external writes from old accounts; and
• overlooked dependencies.

Correct issues immediately.

Respond to a missed dependency

If an overlooked workflow fails:

1. pause the affected workflow or schedule;
2. identify the old tool reference;
3. decide whether to migrate or retire it;
4. update the flow;
5. test in Studio;
6. test in RunFlows;
7. verify any write destination; and
8. record the missed dependency.

Do not restore broad old access unless rollback is formally approved.

Complete the retirement record

Record:

• server name;
• retirement reason;
• retirement date;
• replacement server or process;
• workflows migrated;
• workflows archived;
• schedules removed or migrated;
• credentials revoked;
• accounts disabled;
• permissions removed;
• data preserved;
• final tests;
• reviewer; and
• final approval.

Do not include secret values.

A practical retirement routine

Use this process:

1. Define the retirement reason.
2. Decide whether a replacement exists.
3. Define the completion conditions.
4. Assign an owner.
5. Record the current connection and tools.
6. Inventory Workbench, Studio, RunFlows, Gene, and schedule dependencies.
7. Identify write actions and active work.
8. Pause dependent schedules.
9. Preserve required output and configuration records.
10. Back up important local data.
11. Test the replacement when one exists.
12. Migrate workflows one at a time.
13. Test replacement flows in Studio and RunFlows.
14. Test one-time schedules.
15. Update prompts, documentation, and user guidance.
16. Remove old permissions.
17. Revoke credentials and disable old accounts.
18. Remove network and startup access.
19. End the rollback period.
20. Remove the MCP connection.
21. Confirm old tools disappear.
22. Monitor for missed dependencies.
23. Complete the retirement record.

A server is fully retired only when its connection, access, workflows, schedules, credentials, and user references have all been addressed.