Handle MCP Server Updates

Handle MCP Server Updates

An MCP server update can change more than the server itself.

It may affect:

• the endpoint;
• authentication;
• available tools;
• tool names;
• required input;
• returned fields;
• permissions;
• error messages;
• connected services; or
• workflow behaviour.

Treat an MCP server update as a change to every Feluda process that depends on that server.

Review dependencies, pause important automation, test the new version, and confirm external results before returning to regular use.

What an MCP server update can change

A server update may introduce:

• a new endpoint;
• a different port;
• a new authentication method;
• renamed tools;
• removed tools;
• additional tools;
• different required fields;
• a changed result structure;
• new permissions;
• different limits;
• new warnings; or
• changed write behaviour.

Even a small server-side change can affect several workflows.

Start with the update information

Before changing the connection, review the information supplied by the server owner.

Look for:

• update date;
• new version;
• required actions;
• endpoint changes;
• authentication changes;
• renamed or removed tools;
• changed fields;
• changed permissions;
• known limitations;
• maintenance window; and
• rollback instructions.

Do not apply an update based only on a short announcement when more detailed guidance is available.

Identify the server owner

Confirm who is responsible for the server.

The owner may be:

• your organisation;
• an internal team;
• a software provider;
• a trusted third party;
• an open-source project; or
• another approved operator.

Record who can answer questions about the update.

Identify every dependency

Before applying the change, find where the server's tools are used.

Check:

• Workbench conversations and saved instructions;
• Studio workflows;
• RunFlows items;
• scheduled workflows;
• Gene-provided flows;
• Journal-writing processes;
• local scripts or services;
• test environments; and
• external destinations.

A tool may be used in more places than the original connection owner remembers.

Record the current connection

Before editing anything, record:

• server name;
• endpoint;
• authentication method;
• current connection state;
• current tool list;
• current permissions;
• dependent workflows;
• dependent schedules;
• known external destinations; and
• the last successful test date.

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

Record the current tool list

For each important tool, note:

• tool name;
• purpose;
• read or write behaviour;
• expected input;
• expected output;
• account used;
• source;
• destination;
• permissions; and
• workflows that depend on it.

This gives you a baseline for comparison after the update.

Save a known-good test

Keep one safe test for each important tool.

For a read tool, record:

• test input;
• expected record;
• expected fields;
• expected source;
• expected warning state; and
• expected runtime.

For a write tool, record:

• test destination;
• proposed action;
• expected changed fields;
• expected confirmation; and
• how the test action can be reversed.

Use non-sensitive sample information.

Pause dependent schedules

Pause related schedules before changing:

• the endpoint;
• authentication;
• the server account;
• permissions;
• tool names;
• tool behaviour; or
• result formats.

This prevents scheduled workflows from running during an incomplete transition.

Note each paused schedule so it can be reviewed before resuming.

Stop active write workflows

Before the update, confirm that no important write action is still running.

Review:

• active RunFlows executions;
• Workbench Activity;
• Schedule Manager history;
• pending external writes; and
• long-running tool calls.

Do not update the connection while an important external action is in progress.

Decide whether a rollback is possible

Ask:

• Can the previous server version be restored?
• Can the old endpoint remain available temporarily?
• Can the earlier authentication method be reused?
• Can the old tool list be restored?
• Can dependent workflows be returned to the earlier version?
• Is a backup of configuration available?
• Who is authorised to perform the rollback?

A rollback plan is especially important for production workflows.

Test in a separate environment when possible

Use a test connection when the update affects important workflows.

A separate environment may use:

• a test server;
• a staging endpoint;
• a test account;
• a test workspace;
• sample records;
• temporary output folders; or
• a copied workflow.

Name the connection clearly.

For example:

Customer Records MCP — Updated Test

Keep it separate from the regular connection until testing succeeds.

Update the endpoint

If the endpoint changes:

1. copy the new endpoint from the official update information;
2. confirm the protocol;
3. confirm the host;
4. confirm the port;
5. confirm the path;
6. remove accidental spaces;
7. save the connection; and
8. review the connection state.

Do not guess a different endpoint when the new one fails.

Review protocol changes

A server may change from:

• one host to another;
• one port to another;
• one path to another; or
• one connection method to another.

Confirm whether the change affects:

• network rules;
• certificates;
• local firewall settings;
• proxy settings;
• VPN access;
• URL permissions; or
• port permissions.

Update only the rules needed for the approved new endpoint.

Update authentication

The update may require:

• a new token;
• a new account;
• a different key;
• a sign-in flow;
• a different protected header;
• a changed permission scope; or
• credential rotation.

Store the new value only in the protected connection settings.

Never paste it into Workbench, Studio, Journal, or normal notes.

Confirm account scope after authentication changes

A replacement account or credential may have different access.

Review:

• available projects;
• record scope;
• file access;
• read permission;
• write permission;
• administrative access;
• external destinations; and
• test or production environment.

A successful sign-in does not prove that the account has the correct boundaries.

Confirm the server connection

Open MCP Servers in Feluda.

Review:

• server name;
• endpoint;
• connection state;
• authentication state;
• visible warnings;
• visible errors; and
• discovered tools.

Do not continue to workflow testing until the server is available.

Compare the discovered tool list

Compare the new tool list with the recorded baseline.

Look for:

• new tools;
• missing tools;
• renamed tools;
• duplicate tools;
• changed descriptions;
• changed read or write behaviour;
• changed tool sources; and
• changed destinations.

Do not assume a renamed tool behaves exactly like the old one.

Review removed tools

When a tool is removed:

• identify every dependent workflow;
• pause related schedules;
• remove or replace the tool in Studio;
• update Workbench instructions;
• update documentation;
• test the replacement; and
• confirm that no hidden fallback is used.

A missing tool should produce a clear error, not an invented result.

Review renamed tools

A renamed tool may break:

• direct tool instructions;
• Studio block configuration;
• saved prompts;
• workflow descriptions;
• monitoring rules; or
• troubleshooting instructions.

Update the exact tool name wherever it is referenced.

Then test whether the new tool returns the same type of result.

Review new tools

Treat a new tool as untested.

Review:

• purpose;
• server source;
• input;
• output;
• read or write behaviour;
• permissions;
• destination;
• privacy path;
• errors; and
• limits.

Do not enable new write tools automatically.

Review tool descriptions

A changed description may indicate changed behaviour.

Compare:

• intended use;
• supported actions;
• required fields;
• source system;
• destination;
• no-result behaviour;
• error behaviour; and
• permission requirements.

Update model instructions when the tool's purpose changed.

Review required input

An updated tool may require:

• a new record identifier;
• a different date format;
• an additional account field;
• a source name;
• a destination value;
• a project ID;
• a new option; or
• a changed field name.

Compare the new requirements with existing Workbench prompts and Studio blocks.

Review removed input fields

An update may stop accepting an older field.

Remove outdated parameters from:

• prompts;
• workflow mappings;
• structured input;
• templates;
• test cases; and
• documentation.

Passing an unsupported field may cause a warning, error, or ignored value.

Review output structure

An updated server may change:

• field names;
• field order;
• nesting;
• data types;
• lists;
• page information;
• timestamps;
• warning format;
• error format; or
• success confirmation.

Compare the raw result with an earlier successful result.

Review field-name changes

A changed field name can break later workflow steps.

For example:

owner

may become:

assigned_owner

Update:

• LLM Extract instructions;
• Expression rules;
• labels;
• templates;
• reports;
• tables;
• Emit output; and
• final formatting.

Test every affected path.

Review data-type changes

A field may change from:

• text to number;
• number to text;
• one value to a list;
• date to timestamp;
• empty string to null;
• object to nested object; or
• one record to several records.

Check how later blocks interpret the new type.

Review date and time changes

Confirm whether the updated server changes:

• date format;
• timezone;
• reporting period;
• timestamp precision;
• local time;
• UTC handling; or
• daylight-saving behaviour.

Use exact dates in tests.

Review pagination and result limits

An update may change:

• page size;
• default result count;
• next-page values;
• sorting;
• result limits; or
• duplicate handling.

Confirm whether existing workflows still retrieve the complete intended result.

Review warnings and errors

The server may introduce new warning or error messages.

Record:

• what triggers them;
• whether they are blocking;
• whether partial data is returned;
• whether the workflow should stop;
• whether human review is needed; and
• whether retrying is safe.

Do not route a new error into a normal success path.

Review permission requirements

The update may require different:

• read access;
• write access;
• account scope;
• URL access;
• IP access;
• file-path access;
• port access; or
• external-service permission.

Review the Studio Permissions panel for affected workflows.

Apply the narrowest approved change.

Review URL rules

If the server host or path changes, update only the required URL rule.

Confirm:

• exact domain;
• subdomain;
• path;
• redirects;
• protocol; and
• final destination.

Avoid broad internet access when one domain is enough.

Review IP and port rules

If the update changes network location, confirm:

• IP address;
• host;
• port;
• local or remote status;
• firewall rules;
• VPN requirements; and
• which service uses the port.

Do not open a broad address or port range only to make the update work.

Review path rules

If a tool reads or writes files, confirm:

• input folder;
• output folder;
• changed directory;
• file naming;
• overwrite behaviour;
• path format; and
• operating-system differences.

Keep access limited to the approved folders.

Test one read-only tool first

After the update, begin with one simple read-only test.

For example:

Use only the enabled Internal Knowledge Search tool.

Search for "MCP update test".

Return:
1. result title;
2. source identifier;
3. returned summary;
4. last updated date; and
5. any warning.

Do not create or change anything.

Use the same known-good sample used before the update.

Review Workbench Activity

Open the Activity drawer.

Confirm:

• expected tool;
• expected server;
• correct parameters;
• correct account;
• returned fields;
• warnings;
• errors;
• number of calls; and
• final answer accuracy.

Compare the activity with the previous successful baseline.

Test a known valid result

Confirm that:

• the correct record is returned;
• the source is unchanged or intentionally changed;
• required fields remain available;
• exact values are preserved;
• timestamps are understandable;
• no new unsupported claim appears; and
• runtime remains acceptable.

Test an empty result

Use a value that should return no match.

Confirm that:

• the tool completes;
• no result is returned;
• the model reports no match;
• no fallback is hidden;
• no record is invented; and
• the updated error structure does not confuse the model.

Test an error condition

Use an approved safe method.

Confirm that:

• the error is visible;
• the model does not invent a normal result;
• repeated calls do not continue;
• the workflow follows its error path;
• authentication values remain protected; and
• retry guidance is safe.

Test write tools separately

Do not assume write tools work because read tools do.

Test with:

• a safe account;
• a test environment;
• a temporary item;
• non-sensitive content;
• explicit approval; and
• a reversible action when possible.

Confirm the result at the external destination.

Compare write behaviour

Check whether the updated tool changes:

• created item structure;
• required fields;
• default destination;
• overwrite behaviour;
• duplicate handling;
• confirmation format;
• partial-write behaviour; or
• delete behaviour.

Reapprove any changed high-impact process.

Test timeout behaviour

An updated server may respond more slowly.

Confirm:

• normal runtime;
• timeout point;
• whether partial output appears;
• whether a write completed before timeout;
• whether retries create duplicates; and
• whether the workflow reports the delay clearly.

Inspect the destination before repeating a timed-out write.

Open dependent workflows in Studio

For each affected flow, review:

• provider and model;
• selected MCP tool;
• tool instruction;
• input mapping;
• expected fields;
• Emit blocks;
• Expression rules;
• labels;
• permissions;
• error paths;
• no-result paths; and
• output formatting.

Update one flow at a time.

Use Emit blocks during migration

Add or keep Emit blocks after important steps.

For example:

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

This makes changed structure visible.

Update Expression rules

An Expression block may depend on exact:

• field names;
• status values;
• capitalisation;
• date formats;
• number formats;
• missing-value behaviour; or
• data types.

Compare the incoming updated value with the rule.

Update LLM Extract steps

If the returned structure changed, revise extraction instructions.

Confirm that the model still returns:

• all required fields;
• exact identifiers;
• exact dates;
• exact amounts;
• visible missing values; and
• a stable structure.

Test several examples.

Update classification steps

If the server changed labels or status values, review:

• allowed labels;
• label descriptions;
• fallback label;
• overlapping categories;
• source values; and
• branch connections.

A renamed source status can route the workflow incorrectly.

Test the saved flow in RunFlows

After updating a workflow:

1. save it;
2. open RunFlows;
3. use the known-good sample;
4. review intermediate output;
5. review the MCP call;
6. review warnings and errors;
7. confirm the correct branch;
8. compare the final answer; and
9. inspect any external destination.

This confirms the saved version works outside Studio.

Test every affected path

Test:

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

One successful path is not enough.

Compare before and after results

Use a table such as:

Check	Before update	After update
Tool name	Search Records	Find Records
Record ID field	record_id	id
Status value	Pending	pending
Empty result	Empty list	No-match object
Runtime	4 seconds	7 seconds
Write confirmation	created=true	status=created

This makes required workflow changes clear.

Update documentation

Revise user-facing guidance when the update changes:

• server name;
• endpoint setup;
• authentication;
• tool names;
• tool descriptions;
• workflow steps;
• permissions;
• output fields;
• limitations;
• errors; or
• review requirements.

Remove instructions that refer to old behaviour.

Update saved prompts

Search for prompts that mention:

• old tool names;
• old fields;
• old status values;
• old destinations;
• old paths;
• old endpoints; or
• old limits.

Update and retest them.

Review Gene-provided flows

An installed Gene may include a flow that depends on the MCP server.

Confirm whether:

• the flow still finds the tool;
• required settings remain valid;
• the result structure still matches;
• permissions remain sufficient; and
• the Gene itself needs an update or resync.

Do not edit a reusable template without understanding how it will be maintained.

Review schedules before resuming

For each paused schedule, confirm:

• the updated workflow is saved;
• the correct server is selected;
• authentication works;
• the tool appears;
• the input remains valid;
• runtime remains acceptable;
• duplicate prevention still works;
• the destination is correct; and
• a reviewer is assigned.

Resume one important schedule at a time.

Use a one-time scheduled test

Before restoring a recurring schedule, create or use a one-time run.

Confirm that:

• the run starts;
• the server is available;
• the correct tool is called;
• the result structure is correct;
• the expected branch runs;
• the destination is correct;
• no duplicate appears; and
• Schedule Manager records the result.

Monitor the first resumed runs

Review the first several regular runs.

Check:

• tool calls;
• parameters;
• warnings;
• errors;
• runtime;
• result completeness;
• workflow branches;
• external writes; and
• duplicates.

Pause again when unexpected behaviour appears.

Roll back when the update is unsafe

Consider rollback when:

• the server cannot connect;
• authentication cannot be restored;
• critical tools disappear;
• result structure remains incompatible;
• write destinations are unreliable;
• permission requirements are too broad;
• repeated errors continue;
• data exposure is unclear; or
• important workflows cannot be verified.

Follow the approved rollback plan.

Confirm the rollback

After rollback:

• confirm the old connection;
• confirm the old tool list;
• test the known-good read action;
• test required write actions;
• test affected workflows;
• inspect external destinations; and
• keep schedules paused until the old behaviour is confirmed.

Record why the update was not accepted.

Remove temporary test connections

After the migration succeeds:

• confirm the regular connection works;
• confirm all dependent flows use it;
• confirm schedules use the correct version;
• remove temporary write access;
• remove temporary test records;
• remove obsolete test connections; and
• keep only the documentation needed for future maintenance.

Do not leave duplicate production-like connections without a clear purpose.

Review privacy after the update

Confirm whether the update changes:

• where the server runs;
• what data it receives;
• whether it stores input;
• whether it uses another service;
• what logs contain;
• which fields it returns;
• who can access the connected account; or
• where write actions go.

Reapprove the connection when the data path changes materially.

Review trust after the update

Stop regular use when:

• the server owner changes unexpectedly;
• the endpoint points to an unknown location;
• authentication requirements become unclear;
• tools request broader access without explanation;
• sensitive data appears unexpectedly;
• write behaviour changes without documentation; or
• the update cannot be verified.

Use an approved alternative only after testing it.

Record the completed update

For important servers, record:

• update date;
• old and new version;
• changed endpoint;
• changed authentication method;
• changed tools;
• changed fields;
• changed permissions;
• affected workflows;
• test results;
• schedules resumed;
• reviewer; and
• rollback status.

Do not record raw credentials.

A practical MCP update routine

Use this process:

1. Review the official update information.
2. Identify the server owner.
3. Record the current connection and tool list.
4. Identify Workbench, Studio, RunFlows, Gene, and schedule dependencies.
5. Save known-good tests.
6. Pause related schedules.
7. Stop active write actions.
8. Confirm the rollback plan.
9. Update endpoint and authentication.
10. Compare the new tool list.
11. Review changed input, output, permissions, warnings, and errors.
12. Test one read-only tool in Workbench.
13. Test empty and error cases.
14. Test write tools separately.
15. Update dependent workflows in Studio.
16. Test saved flows in RunFlows.
17. Use a one-time scheduled test.
18. Resume schedules gradually.
19. Monitor the first regular runs.
20. Record the completed update or perform the rollback.

A controlled update protects both the MCP connection and every Feluda workflow that depends on it.