Replace an MCP Server Safely

Replace an MCP Server Safely

Replacing an MCP server can affect every Feluda task that uses its tools.

A replacement may be needed because:

• the current server is being retired;
• a new provider offers a better service;
• the endpoint is changing;
• the server is no longer maintained;
• permissions are too broad;
• reliability is poor;
• a local service is moving to a remote service;
• a remote service is moving on-premise;
• the tool list has changed; or
• your organisation has selected a different approved system.

Do not remove the current server first.

Keep it available while the replacement is connected, tested, and compared.

Treat replacement as a migration

A server replacement is not only a connection change.

It may also change:

• tool names;
• tool descriptions;
• required input;
• output fields;
• result structure;
• authentication;
• account scope;
• permissions;
• source systems;
• destinations;
• error messages;
• runtime; and
• workflow behaviour.

Plan the replacement as a migration from one complete tool environment to another.

Start with the reason for replacement

Record why the current server is being replaced.

Examples include:

• service retirement;
• security concern;
• ownership change;
• repeated outages;
• unsupported tool changes;
• new organisational policy;
• data-location requirements;
• better local operation;
• better shared access; or
• a move to a supported provider.

The reason helps define what the replacement must improve.

Define success before changing anything

A successful replacement should confirm that:

• required tools remain available;
• source access is correct;
• destination access is correct;
• results are complete;
• important fields are preserved;
• permissions remain narrow;
• authentication is protected;
• Workbench tasks still work;
• Studio workflows still work;
• RunFlows results remain correct;
• schedules run successfully;
• write actions affect the right destination; and
• the old server can be removed without disrupting users.

Write down these requirements before testing.

Identify the server owner

Confirm who owns or maintains:

• the current MCP server;
• the replacement MCP server;
• the connected source;
• the connected destination;
• the authentication account;
• affected workflows; and
• scheduled automation.

Know who can answer questions during the migration.

Inventory current dependencies

Before adding the replacement, identify every use of the current server.

Check:

• Workbench instructions;
• saved prompts;
• Studio workflows;
• RunFlows items;
• scheduled workflows;
• Gene-provided flows;
• Journal-writing processes;
• local files or databases;
• external business systems;
• team documentation; and
• user training material.

A server can have hidden dependencies that are not visible from its connection page alone.

Record the current connection

Record:

• server name;
• endpoint;
• connection type;
• authentication method;
• account used;
• available tools;
• read and write permissions;
• approved URLs;
• approved IP addresses;
• approved paths;
• approved ports;
• source systems;
• destinations;
• dependent workflows;
• dependent schedules; and
• last successful test date.

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

Record the current tool list

For every important tool, note:

• tool name;
• purpose;
• whether it reads or writes;
• required input;
• returned output;
• source;
• destination;
• account;
• permission needs;
• normal runtime;
• empty-result behaviour;
• warning behaviour;
• error behaviour; and
• workflows that depend on it.

This becomes the baseline for replacement testing.

Save known-good tests

Keep one controlled test for every important tool.

For a read tool, record:

• sample input;
• expected source;
• expected record;
• expected fields;
• expected warning state;
• expected result count; and
• normal runtime.

For a write tool, record:

• safe test destination;
• proposed action;
• expected changed fields;
• expected confirmation;
• duplicate-prevention method; and
• how to reverse the test.

Use non-sensitive sample information.

Identify scheduled dependencies

Open Schedule Manager.

Record:

• schedule name;
• workflow;
• frequency;
• next-run time;
• source;
• destination;
• write actions;
• normal runtime;
• reviewer; and
• failure path.

Pause important schedules before migrating their workflow.

Identify write dependencies

Give special attention to tools that:

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

A replacement write tool may use a different destination or default behaviour.

Review the replacement server

Before connecting it, confirm:

• who operates it;
• where it runs;
• how it is maintained;
• which tools it provides;
• what information it receives;
• whether it stores data;
• whether it uses other services;
• what authentication it requires;
• what permissions it needs;
• what its availability expectations are; and
• how it can be removed.

Do not replace one poorly understood server with another.

Compare local and remote location

The replacement may change the data path.

Possible changes include:

• local to local;
• local to remote;
• remote to local;
• remote provider to another remote provider; or
• one local-network service to another.

Review:

• model location;
• MCP server location;
• source location;
• destination location;
• authentication path;
• logs; and
• saved results.

A location change may require new approval.

Compare trust and ownership

Ask:

• Is the replacement owner known?
• Is maintenance responsibility clear?
• Is the provider approved?
• Are privacy practices understood?
• Are tool changes documented?
• Is support available?
• Is there a service-status process?
• Is there a clear removal process?

Trust should be reviewed independently from functionality.

Compare authentication

The replacement may use:

• a different account;
• a different API key;
• a new access token;
• a protected header;
• an organisational sign-in;
• local authentication; or
• another credential method.

Store credentials only in Feluda's protected settings.

Confirm that the account has the narrowest required access.

Compare permissions

Review differences in:

• read access;
• write access;
• project scope;
• record scope;
• file access;
• URL access;
• IP access;
• path access;
• port access;
• workspace access; and
• administrative rights.

Do not copy broad permissions automatically from the old server.

Apply only what the replacement needs.

Compare tools by purpose

Tool names may differ even when the purpose is similar.

Create a mapping table.

Current tool	Replacement tool	Purpose	Status
Search Records	Find Records	Retrieve matching records	Needs testing
Update Record	Modify Record	Change approved fields	Needs approval
Create Task	Add Work Item	Create a task	Different destination rules

Do not rely only on similar names.

Compare required input

The replacement tool may require different:

• identifiers;
• field names;
• date formats;
• source names;
• project values;
• account values;
• destination values;
• structured objects; or
• optional settings.

Compare the exact input shown in Workbench Activity.

Compare returned output

The replacement may return different:

• field names;
• field order;
• nested values;
• data types;
• lists;
• dates;
• timestamps;
• warnings;
• errors;
• confirmation fields; or
• pagination details.

Record the differences before changing workflows.

Compare no-result behaviour

One tool may return:

• an empty list;
• an empty object;
• a no-match message;
• a null value;
• a warning; or
• another defined response.

Existing workflows may depend on the old no-result format.

Test the new behaviour explicitly.

Compare error behaviour

The replacement may use different errors for:

• unavailable server;
• failed authentication;
• missing input;
• permission denial;
• no matching record;
• timeout;
• unsupported action;
• invalid field; or
• unavailable destination.

Update error paths so failures remain visible.

Compare runtime and limits

Test:

• normal runtime;
• large requests;
• result limits;
• page size;
• rate limits;
• timeouts;
• simultaneous calls;
• scheduled use; and
• local hardware use when applicable.

A functionally correct replacement may still be unsuitable if it cannot handle the expected workload.

Keep both servers during testing

Use parallel testing when possible.

Keep the current connection active while the replacement is evaluated.

Name the connections clearly.

For example:

• Customer Records MCP — Current;
• Customer Records MCP — Replacement Test;
• Project Files MCP — Local;
• Project Files MCP — New Remote Test.

This reduces confusion in Workbench and Studio.

Avoid duplicate tool names

Similar tools from both servers may appear at the same time.

Use clear connection names and enable only one version during each test.

Do not allow the model to choose between two nearly identical write tools.

Connect the replacement server

Open MCP Servers.

Add the replacement using:

• a clear name;
• the official endpoint;
• protected authentication details; and
• the intended account.

Save the connection.

Confirm its state before continuing.

Review discovered tools

Confirm that:

• expected tools appear;
• unexpected tools are understood;
• removed capabilities are documented;
• write tools are clearly identified;
• tool descriptions are complete;
• permissions are known; and
• test and production tools are distinguishable.

Do not enable every discovered tool.

Test the replacement connection

Start with one read-only tool.

Use the known-good test recorded from the current server.

For example:

Use only the enabled replacement record-search tool.

Search for test record "MCP-MIGRATION-001".

Return:
1. record identifier;
2. title;
3. status;
4. owner;
5. last updated date; and
6. any warning.

Do not create or change anything.

Review Workbench Activity

Confirm:

• the replacement tool was called;
• the replacement server provided it;
• the correct account was used;
• input was accurate;
• returned fields were complete;
• warnings were understood;
• errors were absent or explained;
• no current-server tool was called; and
• the final answer matched the raw result.

Compare current and replacement results

Use the same input for both servers.

Compare:

Check	Current server	Replacement server
Record identifier
Status
Owner
Last updated
Source
Warning
Runtime

Investigate every meaningful difference.

Test known valid results

Confirm that the replacement returns:

• the intended record;
• the correct source;
• required fields;
• exact identifiers;
• exact dates;
• current status;
• expected warnings; and
• an acceptable runtime.

Repeat the test to check consistency.

Test empty results

Use an identifier that should not exist.

Confirm that:

• the tool completes;
• no match is returned;
• the model does not invent a result;
• the no-match response is distinguishable from an error;
• no fallback uses the current server; and
• no write action occurs.

Test invalid input

Use safe invalid examples such as:

• an incomplete identifier;
• invalid date;
• missing filename;
• unsupported field;
• empty required value; or
• unknown project.

Confirm that the replacement returns a clear explanation.

Test permission boundaries

Confirm that:

• approved sources work;
• unapproved sources remain blocked;
• approved destinations work;
• unapproved destinations remain blocked;
• read-only accounts cannot write;
• file paths remain narrow;
• URLs remain narrow;
• IP rules remain narrow; and
• only required ports are allowed.

Do not broaden permissions to make an unclear test pass.

Test write tools separately

Use a safe test destination.

Begin with a draft-first instruction.

For example:

Prepare a replacement-server test update.

Show:
* server and tool;
* environment;
* record identifier;
* current values;
* proposed values;
* destination; and
* how the change can be reversed.

Do not perform the update yet.

Review the proposal before approval.

Approve one exact write

Approve only:

• one tool;
• one destination;
• one record;
• defined fields;
• defined values; and
• one action.

If the proposal changes, request approval again.

Confirm the write externally

Inspect the connected service.

Confirm that:

• the correct record changed;
• only approved fields changed;
• the correct account was used;
• the correct environment was used;
• the timestamp is correct;
• no duplicate appeared; and
• the action can be reversed when expected.

Test timeout handling

Determine what happens when the replacement is slow.

Confirm:

• whether the call times out;
• whether partial output appears;
• whether the external write may still complete;
• whether repeated calls occur;
• whether retries create duplicates; and
• whether the workflow shows a clear error.

Inspect the destination before retrying a timed-out write.

Test duplicate prevention

Repeat a safe create request.

Confirm whether the replacement:

• recognises the existing item;
• uses a unique identifier;
• creates a duplicate;
• overwrites the item;
• returns a warning; or
• requires a manual check.

Update the workflow when duplicate behaviour differs.

Create a copied workflow for migration

Do not begin by changing the only working workflow.

Copy or duplicate the current flow when possible.

Give it a clear name.

For example:

Customer Record Summary — Replacement MCP Test

Keep the original flow unchanged during initial migration.

Replace one tool at a time

In the copied workflow:

1. locate the current-server tool;
2. replace it with the mapped replacement tool;
3. update the instruction;
4. update input fields;
5. update output mappings;
6. update permissions;
7. update no-result handling;
8. update error handling; and
9. save the test flow.

Do not replace every tool at once in a complex workflow.

Update tool instructions

Change:

• exact tool name;
• source description;
• required parameters;
• output fields;
• missing-value rules;
• warning handling;
• read-only limits;
• write limits; and
• approval requirements.

Remove references to old behaviour.

Update field mappings

Review all later blocks that use returned fields.

These may include:

• LLM Extract;
• LLM Label;
• Expression;
• Emit;
• report templates;
• file output;
• Journal output;
• write tools; and
• final formatting.

Update renamed or restructured fields.

Update Expression rules

Check exact:

• field names;
• status values;
• capitalisation;
• date formats;
• number formats;
• empty values;
• null values; and
• data types.

A small difference can route the workflow incorrectly.

Update no-result paths

Make sure the replacement's no-match result goes to the correct path.

Distinguish:

• match found;
• no match;
• permission error;
• server error;
• invalid input; and
• timeout.

Do not let errors enter a normal success path.

Update error paths

Use clear messages such as:

The replacement MCP service could not complete the request.
Review the connection, authentication, permissions, and input.

Do not display a normal-looking report after the tool failed.

Use Emit blocks during migration

Add Emit blocks after important steps.

For example:

Input
→ Replacement MCP Tool
→ Emit Raw Result
→ Extract Fields
→ Emit Extracted Fields
→ Final Output

This helps locate the first difference.

Test the copied workflow in Studio

Test:

• normal input;
• no match;
• invalid input;
• multiple matches;
• permission error;
• unavailable server;
• timeout;
• partial result;
• write success;
• write failure; and
• duplicate prevention.

Review every affected path.

Test the saved workflow in RunFlows

After saving:

1. open RunFlows;
2. select the replacement test flow;
3. use known-good sample input;
4. review intermediate output;
5. review the replacement tool call;
6. review warnings and errors;
7. confirm the correct branch;
8. compare final output with the current flow; and
9. inspect any external destination.

Compare current and replacement workflows

Run both flows with the same sample.

Compare:

• starting input;
• selected tool;
• tool parameters;
• raw result;
• extracted fields;
• branch decisions;
• final answer;
• runtime;
• warnings;
• errors; and
• external actions.

Document accepted differences.

Migrate low-risk workflows first

Start with workflows that:

• are read-only;
• use sample or non-sensitive data;
• have no schedule;
• affect no external destination;
• have clear expected results; and
• are easy to roll back.

Use the lessons from these flows before migrating important write workflows.

Migrate one workflow at a time

For each workflow:

1. pause its schedule;
2. create or confirm a backup copy;
3. replace the tool;
4. update mappings and permissions;
5. test in Studio;
6. test in RunFlows;
7. compare with the old flow;
8. verify any external destination;
9. obtain review; and
10. mark the workflow as migrated.

Avoid a single large migration without checkpoints.

Keep a migration record

Track:

• workflow name;
• current tool;
• replacement tool;
• test status;
• permission status;
• write-test status;
• RunFlows status;
• schedule status;
• reviewer;
• migration date; and
• rollback status.

This prevents workflows from being missed.

Test one-time schedules

Before changing a recurring schedule, use a one-time scheduled test.

Confirm that:

• the replacement server is available;
• authentication remains valid;
• the correct tool is called;
• input is current;
• output is complete;
• the correct branch runs;
• the destination is correct;
• no duplicate appears; and
• Schedule Manager records the result.

Resume schedules gradually

Resume one important schedule at a time.

Review the first several runs.

Check:

• connection state;
• tool input;
• raw output;
• runtime;
• warnings;
• errors;
• branch decisions;
• write destinations; and
• duplicates.

Pause again when unexpected behaviour appears.

Keep the old server during the rollback period

Do not remove the old server immediately after the first successful test.

Keep it available until:

• all required tools are mapped;
• all workflows are migrated;
• all schedules are tested;
• write actions are verified;
• users are informed;
• documentation is updated;
• the rollback period has passed; and
• the replacement is stable.

Keep old write tools disabled when they are no longer needed.

Prevent use of the wrong server

During the parallel period:

• use clear connection names;
• disable unneeded tools;
• update prompts;
• update workflow descriptions;
• label test and production connections;
• restrict write permissions; and
• inform users which server is active.

Avoid two enabled write tools with the same purpose.

Define rollback conditions

Roll back when:

• the replacement connection is unstable;
• critical tools are missing;
• result quality is unacceptable;
• fields cannot be mapped reliably;
• write destinations are wrong;
• permissions are too broad;
• runtime is unacceptable;
• repeated calls create risk;
• scheduled runs fail repeatedly; or
• privacy requirements are not met.

Do not continue only because migration work has already begun.

Roll back a workflow

To roll back:

1. pause its schedule;
2. restore the current-server flow;
3. confirm the current connection;
4. run the known-good read test;
5. test required write actions;
6. verify the destination;
7. resume the old schedule only after success; and
8. record why the replacement failed.

Keep the replacement test connection available for investigation when safe.

Confirm the replacement is ready

Before removing the old server, confirm that:

• every required tool has a replacement;
• every workflow has been migrated or retired;
• every schedule uses the replacement;
• all important permissions are approved;
• read results are complete;
• write results are verified;
• empty results work;
• errors are visible;
• timeouts are safe;
• duplicates are controlled;
• documentation is updated;
• users know the change; and
• rollback is no longer required.

Remove old workflow dependencies

Search for:

• old tool names;
• old server names;
• old endpoint references;
• old field names;
• old status values;
• old source descriptions;
• old destination names; and
• old troubleshooting instructions.

Update or remove every remaining reference.

Revoke old credentials

Removing the connection from Feluda may not revoke access at the old service.

When the old server is retired:

• revoke or rotate old credentials;
• disable old accounts when appropriate;
• remove unnecessary permissions;
• review recent activity;
• confirm no schedule still uses the account; and
• follow the old provider's removal process.

Remove the old server connection

When all dependencies are controlled:

1. pause any remaining old-server schedules;
2. confirm no active old-server call is running;
3. confirm rollback is no longer required;
4. remove or disconnect the old server;
5. confirm its tools disappear;
6. reopen Workbench;
7. reopen affected Studio workflows;
8. test the replacement again; and
9. monitor the next regular runs.

Confirm the old tools are gone

Review:

• MCP Servers;
• Workbench Tools;
• Studio LLM blocks;
• RunFlows;
• Schedule Manager;
• saved prompts;
• documentation; and
• user instructions.

Old tools should not remain selectable or referenced.

Clean up temporary migration items

Remove:

• temporary test connections;
• duplicate test workflows;
• sample records;
• temporary files;
• migration-only permissions;
• old credentials;
• obsolete schedules; and
• outdated documentation.

Keep migration records that are required for future review.

Review privacy after migration

Confirm the final data path.

Check:

• model location;
• replacement server location;
• source location;
• destination location;
• information sent;
• logs;
• storage;
• account access; and
• external services.

The replacement may change privacy even when the task looks the same.

Review operational ownership

Confirm who now owns:

• the replacement connection;
• authentication;
• tool monitoring;
• workflow maintenance;
• schedule review;
• update testing;
• incident response; and
• future removal.

Update the environment record.

Monitor after removal

Review the first regular period after the old server is removed.

Check:

• connection availability;
• tool calls;
• result completeness;
• errors;
• runtime;
• schedule history;
• external destinations;
• duplicate actions; and
• user reports.

An overlooked dependency may appear only after the old tools are gone.

A practical replacement routine

Use this process:

1. Record the reason for replacement.
2. Define success.
3. Identify owners.
4. Inventory every dependency.
5. Record the current connection and tool list.
6. Save known-good tests.
7. Pause affected schedules.
8. Review the replacement server.
9. Compare trust, location, authentication, permissions, tools, and results.
10. Connect the replacement with a clear test name.
11. Test one read-only tool.
12. Compare current and replacement results.
13. Test empty, invalid, permission, and error cases.
14. Test write tools separately.
15. Copy and migrate one workflow.
16. Test it in Studio and RunFlows.
17. Migrate remaining workflows one at a time.
18. Test one-time schedules.
19. Resume schedules gradually.
20. Keep the old server during the rollback period.
21. Remove every old dependency.
22. Revoke old credentials.
23. Remove the old connection.
24. Clean up temporary migration items.
25. Monitor the replacement after removal.

A safe replacement keeps the old server available until the new server has proven that it can support every required Feluda task.