Setting up MCP compliance monitoring without a protocol team
MCP now has a deprecation policy and a conformance suite. The minimum setup to track it without dedicating a role to it.
Until 2026, keeping up with MCP was a sport. Revisions landed, features changed, and the only way not to be caught out was reading SEPs as they came.
The 2026-07-28 revision changes that. It brings three governance pieces that make monitoring feasible without dedicating a role to it: a formal feature lifecycle, an extensions system, and a conformance suite requirement.
You still have to wire something up. Here is the minimum setup.
What there actually is to track
Four sources, no more.
The specification changelog. The authoritative list of what changed between two revisions. Everything else follows from it.
The deprecations. They are tracked publicly, with timelines. A deprecated feature stays functional for at least twelve months before removal. That list is your calendar.
Your SDK's release notes. That is where the protocol becomes code in your codebase. Deprecated capabilities are marked obsolete there, with a pointer to the replacement.
The clients you support. A protocol change only really concerns you when a client your users actually use adopts it. That determines your real urgency, not the spec date.
That last point is the worst tracked and the most decisive. The switch is opt-in on both sides: nothing changes until the client moves.
The minimum setup
A conformance check in CI. The protocol now requires a conformance suite. Run it against your server on every merge. It is not complete proof, but it catches shape regressions without anyone thinking about it.
A failover test in CI. Real multi-step scenario, two instances round-robin, one instance killed mid-flight. It is the only test that proves your server is genuinely stateless.
A calendar alert per deprecation. Not "someday". A date, set the day you learn about the deprecation, with two months of margin before the announced deadline.
A one-hour quarterly review. You open the changelog, the deprecation list, your SDK notes, and you write three lines: what concerns you, what does not, what needs scheduling. One hour a quarter is enough if the rest is automated.
What skipping it costs
The cost is never an outage on the day. It is always deferred, and it takes three forms.
Catch-up. You discover three revisions of debt at once, and what would have been three small projects becomes one big one, with dependencies between them.
Dead code that throws. A deprecated feature compiles until the day it is removed from the SDK. The bug then arrives with no context, six months after someone could have deleted it in two minutes.
A rejected submission. Connector directories look at conformance. A server two revisions behind reads badly, and the fix delays distribution.
Who should own it
If you have a protocol team, this is not your problem. Almost nobody does.
The normal case is a SaaS whose MCP server was written by one developer in two weeks a year ago, and who moved on. The server runs, nobody looks at it, and it drifts slowly.
The two honest options are: someone internal takes an hour a quarter and CI does the rest, or you outsource the monitoring. The worst choice is deciding it will happen "when we have time", because that moment does not arrive.
FAQ
How often do revisions ship?
The cadence is not guaranteed, but 2026-07-28 is described as the last to break compatibility at this scale. The governance added is specifically meant to allow evolution without rupture.
Does the conformance suite validate my server?
No. It validates protocol shape. It says nothing about your security, your performance, or how good your tools are from the agent's point of view.
What about extensions?
They evolve on their own schedule, which is the point of the system. Track only the ones you use.
Monitoring, without spending your Fridays on it
€290 a month. I watch the protocol as it moves, tell you what concerns your server specifically, and warn you before it becomes urgent. No twenty-page report, just what applies to you.
Interested? Talk about compliance monitoring →
Related reading
Got an MCP server to audit?
Five minutes to describe it. I reply within one business day with a first written diagnosis, free of charge.
Get my MCP server audited