Guillaume Lebedel · · 5 min read 
The New MCP Spec Won't Get Your Agents Into Production
Table of Contents
The Model Context Protocol just shipped its 2026-07-28 release candidate, and most of it is what production teams have been asking for. It also won’t move a single agent from pilot to production.
Both things are true. The spec got better at the layer it owns, and that layer was never the one blocking enterprise rollouts.
About 97% of companies say they deployed an AI agent in the past year. Roughly 11% run one in production at real scale. The rest sit in what analysts now call pilot purgatory: built, demoed, funded, and quietly never shipped. The new spec sits on the wrong side of that gap.
The protocol grew up
The release candidate is a genuine step forward, and it’s worth reading in full if you build on MCP.
The headline change is a stateless core. The spec removes the initialization handshake and session management, so any request can land on any server instance. No sticky routing, no shared session store. That alone makes MCP servers far easier to run on ordinary HTTP infrastructure.
There’s real authorization work too. Clients now validate the issuer per RFC 9207, and the spec aligns more closely with OAuth 2.1 and OpenID Connect. If you’re standing up agent auth properly, owning the OAuth app matters more than the shared-app shortcut, a point worth reading on why you should register and own your own OAuth app.
Then there’s a formal deprecation policy. Features move through Active, Deprecated, and Removed, with at least twelve months between deprecation and the earliest possible removal. Roots, Sampling, and Logging are already deprecated. A versioned protocol with a removal clock is the kind of boring guarantee you want before you bet a roadmap on it.
New extensions round it out: Tasks for long-running work, and MCP Apps for server-rendered UI inside a sandboxed iframe. MCP keeps doing what it does well, which is wrap your APIs in a consistent shape an agent can discover at request time, a tradeoff we wrote up after what 200+ connector builds taught us about MCP versus direct APIs.
What it deliberately doesn’t cover
Read the spec for the part most teams actually need, and it isn’t there.
The spec standardizes how a tool is described, how it’s called, and how that call is transported. It says nothing about whether a given agent should run a given action against a given system of record. That’s by design, not an oversight. The protocol is the wire format; authorization belongs to the deployer.
For a functional lead wiring a copilot into Workday, or a developer shipping an internal finance-ops agent, three questions decide whether the thing reaches production:
- which actions this agent is allowed to run, and against which account
- who approved a write to a system of record, and how
- what was logged, and whether you can still query it six months later
None of those have a field in the protocol. And the most common answer to the second one, a human approval prompt, doesn’t hold up under volume. Approval clicks degrade with attention, which is why guardrails belong in scoped credentials, not approval prompts.
Why rollouts stall here, not at the model
The model is rarely the reason an agent stays in a pilot.
A demo runs on clean inputs and a cooperative operator. Production runs against real systems of record, real permissions, and an auditor who will eventually ask what the agent did and on whose authority. The gap between those two worlds is operational, and a smarter protocol or a smarter model doesn’t close it.
This is the execution and governance layer: the part that decides what an agent is allowed to do, enforces it on every call, and keeps a record. It’s the work that doesn’t fit in the spec, and it’s exactly where most enterprise agents get stuck.
The layer the spec leaves to you
That’s the layer we build at StackOne, because we kept hitting it ourselves.
An agent connects once and then acts as itself, not as a shared admin key. Each end-user connection gets its own scoped account, and read, write, and delete are granted separately rather than as a single blanket grant. Every call runs through a permission check in under a millisecond across 420+ systems, and every action is logged. When the auditor asks which record the agent changed, when, and under what authority, the answer is a query, not a forensic project.
None of that competes with MCP. The protocol still describes and transports the tool call. The execution and governance layer decides whether that call should happen and writes down that it did. They sit at different layers, and a mature spec at one layer doesn’t fill the other.
Before you wire the next agent
If you own an agent rollout, the spec upgrade is a reason to revisit the layer it doesn’t touch. Decide per-action scope before the agent ever calls a system of record. Replace the human approval click with a structural limit the agent can’t talk its way past. And stand up an audit log you can actually query, because a six-month answer can’t be backfilled after an incident.
The protocol layer is in good hands. The layer that gets agents to production is still yours to build. If you want to see how per-action scoping and audit logging work in practice, the StackOne docs walk through the account model and what gets recorded on every call.