An MCP server changed. How do you know what broke?

"It still connects" is not a compatibility test

Suppose a customer-support workflow calls a tool named update_case. The call still succeeds after a server release, but the tool now interprets an omitted status as "close the case" instead of "leave the status unchanged." A schema validator may not catch that. The integration is available; the outcome has changed.

That example is illustrative, but the distinction is real. MCP's protocol version describes compatibility between clients and servers at the protocol layer. The tool list and each tool's input schema describe what the server offers. The behavior behind a valid call is another matter again. Passing one layer does not prove the next one is unchanged.

Keep three contracts separate

Protocol contract. Can the client and server communicate using a version and capabilities they both support? The current MCP specification uses date-based identifiers for protocol revisions that include backwards-incompatible changes. It also defines how clients and servers negotiate supported versions.

Tool contract. Which tools are available, what each is called, what its description says, and which arguments its input schema accepts? A removed or renamed tool, a changed enum, or a newly required field may break the agent before it reaches the business system.

Workflow contract. Does the tool still have the same effect in the connected system? Does a "create" call still create one record? Does an omitted argument preserve the old value? Does an error mean the operation definitely failed, or could it have partially succeeded?

The MCP protocol's version identifier cannot stand in for application-specific promises about every tool's meaning. The contract that matters to a workflow has to be tested at the level where it can fail.

Capture what production actually uses

Before a change, take an inventory of the tools and schemas used by important workflows. Record the tool name, description, required and optional arguments, value constraints, and the systems or records the call can affect. Include the identity and permissions under which it runs.

Then compare the proposed release with that baseline. A useful diff flags removed tools, renamed arguments, newly required values, changed enum options, and description changes that could alter how a model chooses or fills in a tool call. Review description changes as behavior changes: a model uses the description to decide when a tool is appropriate, even if the JSON schema stayed the same.

The inventory should be tied to real workflows, not just a server's full tool list. A changed tool nobody uses may not need the same release gate as a change to a payment or customer-data workflow.

Test the job, not only the schema

Contract checks catch structural incompatibilities. They do not tell you whether the workflow still reaches the expected result. For each important task, create a small set of representative checks:

• a normal request using common arguments;
• a boundary case, such as an empty optional value or a less common enum;
• an authorization check for a user who should be allowed and one who should not;
• a failed or timed-out call, including what happens if the downstream action partly completed;
• an end-to-end check that verifies the resulting record or side effect in the destination system.

For model-driven workflows, include the surrounding prompt and tool descriptions in the test. A tool can remain structurally valid but become more ambiguous to the model after a description change. Check whether the agent chooses the right tool and whether it presents the result accurately.

Use a test environment or safe fixture for any action that can affect a real customer, send a message, or change production data. A passing test should establish what was checked and which version of the server, client, model, and workflow was involved. Otherwise, a green result is difficult to reproduce after a failure.

Release in a way you can undo

Run the checks before rollout, then release to a limited set of workflows or users when the system allows it. Watch for tool errors, unexpected argument patterns, retries, and changes in the outcomes the workflow produces. Define a rollback path before the release: restore the prior server build or tool contract, route calls back to a known version, or disable the changed workflow while the team investigates.

The MCP specification has a deprecation policy for protocol features, including a stated period before deprecated features become eligible for removal. That gives implementers a migration window for protocol changes. It does not automatically provide the same guarantee for every tool exposed by every server. Ask the server owner what compatibility policy applies to its tools and what notice or migration support comes with a breaking change.

The useful release question

"Does it still connect?" is necessary, but too small. Ask: "Can the client still speak to this server, are the tools the workflow depends on still compatible, and does the task still produce the right result under the right identity?"

Those checks take more care than testing one successful call. They also catch the quiet failure mode: an integration that looks healthy while the agent's job has changed underneath it.

Sources

1. Model Context Protocol, Versioning (protocol revisions, negotiation, and deprecation policy; accessed 2026-10-05)
2. Model Context Protocol, The 2026-07-28 Specification (protocol changes and migration considerations; accessed 2026-10-05)
3. MCP TypeScript SDK, Versioning Policy (SDK release and migration practices; accessed 2026-10-05)