Most organisations would not let someone upgrade a database driver in production by typing @latest on a Friday afternoon. Many already do exactly that with MCP servers. The configuration examples that get copied into editors and agents often use a floating version, and the server is fetched fresh whenever the client starts. The agent's tools can change overnight without anyone deciding they should.
That would matter less if MCP servers were stable, passive plumbing. They are not. An MCP server defines the tools an agent can see, how those tools are described, what parameters they accept and what they return. Change any of that and the agent's behaviour changes, even if your prompts, model and code did not.
The Azure MCP Server 3.0 upgrade notes in Microsoft's release post are a useful illustration, not because the release was careless (it documents its changes clearly) but because they show how many kinds of change a single MCP upgrade can contain.
What changed in one real upgrade
Microsoft lists, among others:
- Renamed commands and tools. Preview users of the resilience tools must move from
resiliencetoresiliencynaming, including the tool prefixes. A monitor command was replaced bylistandgetforms. - Changed response shapes. Advisor recommendation listings now use ARM-style
properties. Monitor log queries and Azure AI Search index queries returnresultswrappers. Some named payloads became wrapped objects; two Functions commands now return direct objects. - Removed options. Saved calls and scripts must drop obsolete options such as subscription, resource-group, tenant and auth-method; custom retry-policy options are gone; and
sql server deleteno longer accepts--force. - Stricter inputs. Unknown parameters now return errors instead of being ignored.
- Moved configuration. Server settings move under
MicrosoftMcpinappsettings.json, and namespaces, including logging categories, change fromAzure.Mcp.CoretoMicrosoft.Mcp.Core. - Provisioning defaults. Virtual-machine and scale-set creation now require an explicit
--image, the default size isStandard_D2s_v5, and two image aliases were removed. - Protocol requirements. The server uses MCP protocol version
2026-07-28. Custom HTTP clients on that version must sendMcp-MethodandMcp-Nameheaders on every POST, a requirement that comes from the specification changelog itself; clients on2025-11-25keep automatically negotiated backward compatibility.
Each of these is a reasonable change. Together they mean an agent workflow that worked on Tuesday can, after an unplanned upgrade, choose a tool that no longer exists, misparse a result, fail on a saved call, or log to a category your monitoring no longer watches.
Why conventional testing misses it
A build pipeline compiles code and runs tests. MCP changes usually do not touch your code. The agent's prompt still loads. The client still connects. The server still starts. What changed is the contract between the model and the tools, and the consequences appear as behaviour: a slightly different tool choice, a summary built from a misread wrapper object, an error the agent politely works around by trying something else.
Those failures are quiet. That is what makes them expensive.
A compatibility-test matrix
Treat each MCP server as a pinned dependency with its own test matrix. For each workflow that uses it, test the categories of change that an upgrade can introduce:
| Change category | What breaks | Test |
|---|---|---|
| Tool names and filters | Tool list filters stop matching; agent loses a tool | Compare exposed tool list against the approved list |
| Descriptions and schemas | Tool selection shifts; calls rejected | Rerun the tool-selection suite from Part 3 |
| Response shapes | Parsers and agent summaries misread results | Golden-response comparison on fixed test resources |
| Removed or renamed options | Saved calls and scripts fail | Replay saved calls in the test environment |
| Configuration and logging | Settings ignored; logs disappear from dashboards | Start server with production config; check log categories arrive |
| Defaults for new resources | Created resources differ from your standards | Create one resource of each type in a sandbox; diff against policy |
| Protocol version | Custom clients fail or behave differently | Run custom client integration tests against the new server |
Not every workflow needs every row. A read-only Advisor workflow needs the first three and the logging row. A workflow that creates resources needs all of them.
The upgrade path
Pin. Use an exact server version in every client configuration, not latest. Record it in the repository with the approved tool list. Microsoft's own read-only example in the 3.0 post does exactly this, starting the server with @azure/mcp@3.0.0, while many examples elsewhere in the project's documentation use @azure/mcp@latest. Copy the pinned form.
Read the notes. Map each documented change to the workflows that use the affected tools. Microsoft's notes for 3.0 are detailed; not every server will be, which is a reason to prefer servers that are.
Test in a sandbox. Run the matrix against the new version in a non-production subscription with the same identity model.
Canary. Move one team or one workflow first. Watch tool-selection rates, errors and support questions for a defined period.
Promote or roll back. Promote by changing the pinned version in configuration through a reviewed change. Roll back the same way. Rollback must be tested: if the new version wrote configuration in a new location or format, confirm the old version still starts cleanly.
Record. Keep the version, the test results and the decision. When behaviour changes later, the record shows whether an upgrade is a suspect.
Sedgefield Freight is fictional, and its systems and figures are illustrative. Sedgefield's platform team found that two of its five pinned client configurations were floating after all, set by developers following an older setup guide. Fixing that took an afternoon. Their first planned upgrade then caught a parser in a reporting script that expected the old Advisor response shape. In an unplanned upgrade, the script would have produced an empty weekly report and nobody would have noticed for a fortnight.
Three quiet failures to look for
The matrix is easier to run when you know what a quiet failure looks like. Three patterns from the 3.0 notes are worth checking explicitly in any upgrade.
The filter that matches nothing. A --tool list written against preview names such as resilience_* stops matching after the rename to resiliency_*. Depending on the client, the agent either loses those tools or, if the filter is dropped while someone debugs, gains every tool. Compare the exposed list after the upgrade against the approved list, name by name.
The log that went quiet. Logging rules and dashboards keyed on Azure.Mcp.Core categories stop receiving events once they are emitted as Microsoft.Mcp.Core. The server works; your monitoring of it does not. After the upgrade, confirm that each category you alert on still arrives, and treat an unexpectedly quiet dashboard as a failure, not a good day.
The default nobody chose. A workflow that creates virtual machines and relied on an implicit image now fails, which is loud and easy to fix. The size default is quieter: whatever the size used to be, it is now Standard_D2s_v5 unless set explicitly. If cost or quota assumptions depend on the size, set it in the workflow rather than inheriting it from the server.
Upgrades belong in the supply-chain record
An MCP server is code that runs with your credentials and shapes what your agents do. That makes it part of your software supply chain, with the same questions as any dependency: where it came from, which version, who approved it and how to remove it. Agent skills and MCP servers are executable dependencies sets out that review gate; this part adds the operational half, which is controlling change once a server is approved.
The ownership record for each server, covered in why an internal MCP registry needs ownership, is where the pinned version, the test matrix and the upgrade history should live.
Next: Part 6, Local MCP, shared MCP or remote MCP? All parts are on the series page.
How CloudNala can help
CloudNala helps platform teams bring MCP servers under change control. We would find the floating versions, pin and record what is in use, build a compatibility-test matrix for your real workflows, and set up a canary and rollback path so the next upgrade is a planned change rather than a surprise.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Readiness Review or write to us at consult@cloudnala.co.za