Does MCP make an integration portable? Test the exit

MCP does not, by itself, make two integrations interchangeable. A shared protocol can give clients and servers a common interface for discovering and calling tools. It does not establish that a replacement preserves the workflow, permissions or recovery arrangements your firm needs.

A document-search integration might connect successfully but return different fields, search a wider collection, lose useful context or handle an unavailable source differently. A successful connection does not settle any of those questions.

The practical next step is an exit test for one integration: specify what must survive, compare the current and proposed arrangements using synthetic material, then rehearse restoration.

This guide concerns replacement—not general permission design, product selection or approval for a live change.

What MCP tells you—and what it does not

The primary specification pages checked 7 October 2026 identify revision 2026-07-28. The bounded documentary distinctions below do not establish implementation compatibility:

Protocol information	What you still need to establish
MCP describes host, client and server roles.	Which components you are replacing, and which responsibilities remain with the host or surrounding application.
Tools have names and input schemas; output schemas are optional.	Whether the tools available to your client accept equivalent inputs and return information with equivalent meaning.
Tool availability can vary with authorisation.	What the workflow can actually discover and call under its configured identity.
Transport and authorisation have distinct requirements; HTTP authorisation guidance differs from STDIO credential handling.	Whether the chosen versions and configurations work together without losing required controls.

Sources: MCP architecture, tools, transports, authorisation, checked on 7 October 2026 for the protocol descriptions used here. This was a documentation check, not a client/server compatibility test.

A familiar tool name is not proof of familiar behaviour. Nor does protocol support establish where application state lives, whether it can be exported, or how much work a replacement requires.

For this guide, portability means being able to replace a specified integration while preserving the required work and controls, at an acceptable switching cost. Evidence from one configuration supports only that bounded conclusion.

Define the replacement before testing

Choose one change: for example, replace a document-search server while keeping the host and client workflow unchanged.

Write down:

• What stays: the workflow, required outputs and existing access boundaries.
• What changes: the server, configuration and any field mapping or adapter.
• What must survive: required behaviour, state, error handling, evidence and recovery.
• What is acceptable: limits for changeover effort, interruption and ongoing maintenance.
• Who owns the test: the person who can inspect results and restore the prior arrangement.

Reuse the existing C2 authority record and its established permission requirements. This is a check that they survive the swap, not an opportunity to widen them. If the acting identity or permitted scope is unknown, resolve that before claiming equivalence.

Keep credentials and real client material out of the worksheet. Put restricted configuration references in the appropriate internal record.

Copy this exit-test worksheet

Set requirements before trying the candidate. Record expected behaviour separately from observations, and test the current arrangement rather than assuming it is a reliable baseline.

Check	Required outcome or limit	Current arrangement: observed result	Candidate: observed result
Components	Host/client/server versions; exact replacement boundary	___	___
Connection	Compatible protocol revision, transport and required optional features	___	___
Tools and results	Required arguments, fields, citations and meanings	___	___
Access	Same required identity boundary, allowed resources and refused access	___	___
State	Context or saved state needed to continue; export, recreation or restart method	___	___
Difficult results	Defined handling of no match, superseded material and missing fields	___	___
Failures	Defined handling of timeouts and unavailable sources	___	___
Evidence	Inspectable records for requests, denials, failures and changeover	___	___
Restoration	Restore the prior arrangement within the agreed time and effort	___	___
Switching cost	Acceptable setup, mapping, testing, training and maintenance effort	___	___

For each observation, retain the test date, configuration reference, evidence location and any difference from the requirement. Mark an untested item untested, not passed.

If the current arrangement fails a requirement, record that too. Reproducing an existing weakness is not evidence that a required control has been preserved.

Fictional rehearsal: replace a document-search server

This entire example is fictional and untested. Server A, Server B and the fixtures below are illustrative labels, not products or observed results.

The proposed change replaces Server A with Server B. The host, client workflow and human review step stay the same.

Use an isolated test environment with synthetic documents and test identities. Include:

• a current procedure in the permitted collection;
• an older procedure clearly marked as superseded;
• a document in an excluded synthetic collection;
• a query with no matching document.

Give each document a distinct identifier, title and date. Do not connect live client repositories to make the rehearsal more realistic.

1. Establish the baseline

Run the chosen client workflow against Server A. Capture the inputs, returned fields, displayed result and available evidence.

Check permitted access, excluded access, no-match behaviour and handling of superseded material. Use a controlled test method for missing fields and unavailable sources; record what that method actually covers.

Save the configuration needed to restore Server A. Record the restoration owner and agreed recovery limit.

2. Discover and map the candidate’s tools

Connect Server B within the isolated environment. Check the tools available to the test identity, then compare arguments and result fields.

Can the client still use the returned identifier, title, date and citation? Do those fields mean the same thing?

Record every mapping or adapter required. A connection that works only after custom changes may still be a viable replacement, but those changes belong in its switching cost and maintenance record.

3. Repeat permitted and refused searches

Use the same fixtures, queries and access requirements.

The permitted collection should remain accessible. The excluded collection should remain inaccessible at the intended enforcement boundary.

Inspect the available access evidence, not just the displayed answer. A client hiding a document does not demonstrate that the downstream request was refused. If the relevant boundary cannot be verified safely, mark the check hold.

4. Compare difficult results and failures

Repeat the query with no match. Retrieve the superseded fixture. Test a missing result field and a controlled timeout or unavailable source.

Check whether the workflow:

• distinguishes “nothing found” from “source unavailable”;
• preserves the information needed to identify superseded material;
• handles missing fields without silently misrepresenting the result;
• leaves enough evidence for an operator to explain the failure.

Identical wording and log formats are not required. The specified behaviour and usable evidence are.

5. Check state and restoration

If the workflow depends on saved selections, context or other state, establish where that state lives. Test whether it remains usable, must be recreated or requires a documented restart. If the workflow needs no retained state, record that explicitly.

Restore Server A using the saved steps. Repeat an allowed and a denied search, and check the required state and evidence.

Record elapsed time, manual work and anything that could not be restored. Restoration is part of the rehearsal, not a promise to work it out later.

No step above has been performed for this article. There are no observed pass results.

Record the result without overstating it

Use three test outcomes:

• Pass within scope: Every required check passes with inspectable evidence, restoration is demonstrated, and switching cost stays within the agreed limit.
• Hold: A required comparison, configuration detail or result is unknown or untested.
• Fail against requirements: A required behaviour is not met, prohibited access succeeds, or restoration or switching cost exceeds the agreed limit.

A handshake, a listed tool or one successful search is not enough.

Finish with a short decision record:

Replacement boundary and tested versions:
Test date and evidence references:
Result — pass within scope / hold / fail:
Required checks not met or not tested:
Mappings, adapters and other dependencies:
Restoration result:
One-off switching effort and recurring maintenance:
Remaining risks or limitations:
Recommended next action and owner:

Name residual dependencies plainly: for example, a non-exportable state store, a required proprietary feature or an adapter that only one team can maintain. Do not label the whole integration portable while leaving those costs invisible.

Passing a synthetic rehearsal is not authorisation to change production. It supports a bounded finding: these configurations met these checks with these fixtures. Any live replacement still needs the firm’s normal assessment and approval.

MCP can provide a common interface. The exit test answers the more useful question: can you leave this implementation without losing the particular work and controls you need?

Sources and limits

The pinned 2026-07-28 MCP architecture, tools, transport overview and authorisation pages were retrieved and read on 7 October 2026. Architecture identifies host/client/server roles. The tools definition includes an input schema and optional output schema; the capabilities section allows the available tools to vary by authorisation. The authorisation page distinguishes HTTP guidance from STDIO credential handling. These are specification descriptions, not measured compatibility, safety or switching effort.

The worksheet, fixtures, test sequence and decision criteria are original recommendations, not MCP conformance requirements. Portability, reliability and performance are untested and unverified. No chosen client/server configuration or executed replacement/restoration result is supplied. The fictional rehearsal establishes no product capability, successful migration, hosting location or privacy guarantee. Recheck the pinned version and selected implementation documentation before connected testing or a live migration.

Return to the Integrations parent for the workflow decision and C5 for a bounded non-coding pilot. Rights and output reuse remain in Weights; product details remain in Hermes.