7-28 Hands MCP to Platform Teams

TL;DR: The 7-28 MCP spec revision includes a number of capabilities that will resonate with platform teams. MCP now goes stateless, requests carry their own identity and capability info, Roots, sampling, and logging get deprecated, and more. As a result, platform teams can govern MCP the same way they govern the rest of their infrastructure.

For the last year, most enterprise platforms teams we’ve talked to have seen MCP show up the same way: developers found it, valued it, and then wired a dozen servers into their coding agents before anyone in platform engineering had a chance to ask a question. The behavior wasn’t intentionally reckless, but it was genuinely difficult to centralize governance and enforce a security boundary.

Today's spec revision changes that. This is the release platform teams have been waiting for.

Why this was a platform problem, not just a protocol detail

Today's MCP (the 2025-11-25 spec most enterprises are running) relies on an initialize handshake and a server-issued session ID that every subsequent request has to carry. That's fine for a single developer running a local server over stdio, but messy for a platform team; there has not been a clean way to say "this specific call, from this specific agent, on behalf of this specific user, is or isn't authorized" without also reconstructing whatever context lives in that session.

So platform teams had to choose one of two bad options. Let every team run its own MCP servers with its own auth posture. Or build a custom proxy layer to fake statelessness on top of a protocol that was never designed for it.

What actually changes, read as a platform team

The headline: MCP goes stateless. The handshake disappears. Requests carry their own identity and capability info instead of leaning on a pinned session. Where a server still needs to track state across calls, that state becomes an explicit handle passed back and forth in tool arguments, not an implicit session your infrastructure has to keep alive.

Any request can go to any node behind any load balancer. That's the precondition for treating MCP servers like the rest of your infrastructure.

Three other changes matter just as much to platform teams, even though they'll get less attention:

• Roots, sampling, and logging are deprecated. The departure of roots forces access scope back to where it belongs: server configuration, explicit tool parameters, or a policy layer you control. And the deprecation of logs forces them onto real infrastructure (e.g. OTel), which allows a platform team to build a queryable trace of every agent-to-tool call.
• Tool contracts standardize on JSON Schema 2020-12. inputSchema and outputSchema stop being a loose suggestion and become an actual contract you can validate at your gateway, before a malformed or malicious tool call ever reaches a production system.

Put together, this is a protocol that finally looks like something you can put a gateway in front of.

What to actually do about it

Platform teams should treat this revision as an opportunity to stand up real MCP governance. Here are a few concrete moves:

1. Inventory before you migrate. Find every MCP server that your organization is running or connecting to (sanctioned and unsanctioned). For each one, ask whether it depends on Roots for access boundaries, whether it holds session state you don't control, and whether it's reachable over HTTP with weak or no auth today. In short, register your current risks.
2. Centralize the auth boundary. Every call to an MCP server is, by definition, an agent acting on someone's behalf. That's a single, well-defined control point you can use. Exchange and descope tokens so agents get less power than the humans they represent.
3. Validate schemas at the edge. With inputSchema and outputSchema finally pinned to a real dialect, you can reject malformed tool calls and malformed tool results before they touch anything real.
4. Treat statelessness as your scaling unlock. Once servers don't need session affinity, you can run them like any other horizontally scaled service, and apply org-wide policy-as-code across your whole MCP surface instead of per-server configuration.

If your team has been quietly dreading the "how do we get our arms around MCP" conversation, this is the moment to have it.