MCP Grew Up. Your Integration Debt Has a Clock.

The Model Context Protocol crossed a threshold in July, and the announcement read like plumbing. The 2026-07-28 spec revision removed protocol sessions from the core path, added HTTP headers carrying method and name metadata so gateways can classify MCP traffic without parsing JSON bodies, added RFC 9207 issuer validation on top of the resource-bound tokens RFC 8707 already required, and put Roots, Sampling, Logging, Dynamic Client Registration, and the old HTTP+SSE transport on a formal twelve-month deprecation lifecycle, with an incompatible change to elicitation besides. The lifecycle is the part with a clock attached.

The claim I want to defend is narrower than “MCP is now governable,” because a protocol never governs anything; deployments do. It’s this: the deprecation clock is a forcing function, the only one you’re likely to get, and what it forces is discovery. Sometime in the next year, every MCP integration in your company has to be touched by someone or it degrades. That includes the integrations you don’t know about, and given how AI usage actually spreads , the ones you don’t know about are the point. A compatibility deadline is the one mechanism that surfaces them all without a mandate, because the mandate is physics: migrate or break. The governance return comes entirely from what you do at that compulsory touch point. Handle it as an SDK bump and you get an SDK bump. Handle it as the census you were never able to run, and you come out with the artifact agent governance has been missing: a register of every agent-to-tool boundary, each with an owner.

Be precise about what the new spec does and doesn’t give you, because the security wins are real but conditional. Method and name metadata in headers means a gateway or WAF can classify and coarsely deny MCP traffic, such as “no tools/call from this network zone to that server,” without deep-parsing bodies. That is inspection and gross filtering, not authorization: headers are client-supplied, so the rule at the edge needs a companion check in the application that the header and body agree, and argument-level authorization stays where it always lived, next to the tool. Resource-bound tokens, required since the 2025 revision and only as good as the check behind them, shrink the blast radius of a stolen credential, provided your issuance and validation actually bind and check the audience; the spec mandates the mechanism, your deployment supplies the truth of it. Statelessness removes the session dependency from core protocol handling, which simplifies serving and pushes context into each request. That’s an architectural direction that suits enforcement, not a control by itself. Each of these is a wall you can now build. None is a wall the spec built for you.

So run the year in three moves. Discover, from evidence rather than memory: egress logs and gateway traffic for MCP-shaped flows, dependency manifests for MCP SDKs, service catalogs, and an amnesty week for teams to register what they wired up themselves. Each finding becomes a row: server or client, owner, transport, deprecated features touched, what it can reach. Rank by exposure times privilege times dependency; the internet-facing server wired to production data outranks the intern’s notes tool, whatever the migration effort. Then migrate against acceptance tests, not vibes: wrong-audience tokens rejected; forbidden method-and-name pairs blocked at the gateway and the discrepancy case handled; client and server versions verified compatible under canary with a rehearsed rollback; the deprecated path actually retired, not left listening. The eval-environment lesson applies here too: test these boundaries where you provoke agents, not just where you serve customers.

Treat the twelve months as a planning horizon, not a promise. A lifecycle in the spec doesn’t synchronize SDK maintainers, and client libraries will drop deprecated paths on their own schedules, some sooner. The owner of each row verifies the roadmap of the specific libraries that row depends on; “the spec says twelve months” is not a compatibility guarantee, it’s the outer bound of your window.

The finish line, stated so you can check it: every MCP boundary in the register, every row owned, every row passing its acceptance tests, no deprecated features in production traffic, all before your most conservative dependency drops them. Miss the window and you’ll still migrate, in fragments, on pages, with no census to show for it. The clock runs either way. The only question is whether it runs on a register or on your incident channel.