The MCP conversation is moving from tools to control

MCP is having a very practical summer.

The interesting news is not just that more platforms are adopting the Model Context Protocol. That part is already happening. The more important shift is that MCP is starting to grow the operational muscles that production AI agents need: stateless infrastructure, clearer authorization, audit trails, governed tool calls, and a cleaner path for extensions.

That is a different phase of the market.

For most of the last year, MCP was explained as the connector layer for AI agents. One client, many tools. One protocol, fewer custom integrations. A standard way for models to discover capabilities and call external systems.

That story is still true.

But it is no longer enough.

The real question for teams building with MCP is becoming: what happens when the agent is not just reading context, but taking action?

The strongest signal is the upcoming MCP spec revision

On May 21, the MCP maintainers published the release candidate for the next specification, named 2026-07-28. The final specification is planned for July 28, 2026 (Model Context Protocol Blog).

The headline change is that MCP becomes stateless at the protocol layer.

In the previous Streamable HTTP design, a client established a session, received an Mcp-Session-Id, and carried that session into later requests. That made sense for early implementations, but it also meant production deployments had to think about sticky sessions, shared session stores, and routing behavior that understood MCP traffic.

The release candidate changes that shape. Requests carry the protocol version, client information, and relevant capabilities with them. Headers such as Mcp-Method and Mcp-Name let ordinary HTTP infrastructure route and observe traffic without digging through every request body.

That sounds like plumbing because it is plumbing.

It also matters.

If MCP servers are going to sit behind load balancers, gateways, rate limiters, cloud platforms, and enterprise monitoring systems, they need to behave more like normal web services. Stateless requests make MCP easier to scale, easier to debug, and easier to operate in environments that already have strong opinions about HTTP.

The release candidate also introduces or formalizes several other production-facing ideas:

Extensions become first-class, including MCP Apps for server-rendered user interfaces and Tasks for long-running work.
Authorization is tightened to align more closely with OAuth and OpenID Connect deployments.
Roots, Sampling, and Logging are deprecated.
Tool schemas move to full JSON Schema 2020-12.
A formal deprecation policy gives implementers a clearer view of how features can evolve.

That is not just a feature list. It is the protocol moving from early adoption toward operating discipline.

Stateless MCP makes state more visible

One useful detail in the release candidate is the distinction between protocol state and application state.

Stateless protocol design does not mean agents stop needing memory. Real workflows still need state. A browser automation server may need a browser session. A data workflow may need a job id. A commerce workflow may need a basket id. A support workflow may need a ticket id.

The difference is where that state lives.

Instead of hiding workflow state inside transport metadata, an MCP server can return an explicit handle and ask the model to pass it back in later tool calls.

For example:

{
  "browser_session_id": "brs_123"
}

Then later:

{
  "browser_session_id": "brs_123",
  "url": "https://example.com/settings"
}

That looks small, but it changes the shape of agent systems.

When state is visible, the model can reason about it. Logs can show it. Gateways can inspect it. Humans can understand what happened after the fact. A hidden session id can keep a connection alive, but it does not help much when you need to explain why an agent changed a setting, filed a ticket, or moved data between systems.

Visible state is not automatically safe. Handles still need scope, expiry, validation, and permission checks. But visible state is easier to govern than invisible transport state.

That is the broader theme.

MCP is becoming less about making tool calls possible and more about making tool calls accountable.

Windows is treating MCP like an operating system surface

Microsoft's MCP on Windows work points in the same direction.

The Windows On-device Agent Registry gives apps and agents a managed way to discover and access MCP servers from local apps and remote servers. The Microsoft Learn documentation emphasizes security, user and admin control, and logging. It also notes that MCP servers can be contained in a separate environment by default and that users and administrators can audit interactions between MCP clients and servers (Microsoft Learn).

That is a useful signal because Windows is not treating MCP as a developer toy. It is treating MCP as something that may sit inside the operating environment where files, settings, apps, and user data live.

Once MCP reaches that layer, the questions change:

Which agents can see which connectors?
Which connector can access which resources?
Which user approved the action?
Which admin policy applied?
Where is the log when something goes wrong?

Those are boring questions in the best possible way.

They are also the questions enterprises will ask before they let agents use real systems.

Microsoft is also pushing governance patterns in the developer stack. Its Agent Governance Toolkit post describes a governed pipeline for MCP tool execution, including policy checks, suspicious tool scanning, response sanitization, audit events, and OpenTelemetry (Microsoft .NET Blog).

The important sentence is not that Microsoft has a toolkit. Toolkits come and go.

The important point is that governance is being placed around the tool call itself.

That is where the risk lives.

Google DeepMind is framing agents as controlled actors

Google DeepMind published its AI Control Roadmap on June 18. It is not an MCP-specific announcement, but it belongs in the same conversation.

The roadmap starts from a cautious assumption: capable AI agents may act in unexpected ways, so systems should be designed with monitoring, prevention, and response layers. Google describes agent security as a defense-in-depth problem, including sandboxing, prompt injection resistance, monitoring, supervisor models, and permission levels that increase only as behavior is verified (Google DeepMind).

That framing lines up with where MCP is going.

MCP gives agents a standard way to reach tools. AI control asks what should happen before, during, and after that reach.

For low-risk actions, delayed review may be enough. For high-risk actions, the system may need synchronous prevention. The difference matters. Reading a public document is not the same as deleting a repository. Drafting an email is not the same as sending it. Checking a price is not the same as buying inventory.

The industry is starting to admit that "the model seemed confident" is not a control plane.

Agents need external checks.

The action layer is becoming a category

Arcade's 60 million dollar Series A is another market signal. The company describes its focus as the secure action layer for production AI agents, with enforcement, execution, and governance around agent actions (Arcade.dev).

The exact product category is still forming, but the problem statement is becoming familiar: companies need to prove which agent took which action, on behalf of which user, against which resource.

That sentence keeps showing up in different forms across the ecosystem.

It shows up in MCP's authorization work.

It shows up in Windows auditability.

It shows up in Google's control roadmap.

It shows up in security research around MCP tool poisoning, prompt injection, and unsafe local execution.

It shows up every time a demo agent becomes a production agent and suddenly needs permission boundaries, logs, rollback behavior, and incident review.

This is where MCP becomes more than an integration convenience.

If agents are going to do real work, the tool interface becomes a control point. The MCP server is not just a wrapper around an API. It is the place where capabilities are described, permissions are enforced, state is exposed, and actions are recorded.

That makes MCP servers part of the trust boundary.

Security pressure is forcing better patterns

The security conversation around MCP has become sharper in 2026.

Researchers and vendors have raised concerns around tool poisoning, prompt injection, unsafe STDIO configurations, supply chain exposure, and remote code execution risks in specific implementations (OX Security, Cloud Security Alliance). Some of those debates are about the protocol itself. Some are about SDK behavior. Some are about applications accepting untrusted configuration and turning it into local process execution.

The distinction matters.

Not every MCP security problem is a flaw in MCP. Some are familiar software security problems wearing agent clothes: untrusted input, overbroad permissions, weak package hygiene, missing sandboxing, and logs that arrive too late.

But the effect is still real. MCP makes it easier for agents to reach tools, so the security bar around tools has to rise.

A practical MCP deployment now needs answers to questions like:

Can this server be discovered by the right clients only?
Can tool descriptions be scanned before the model sees them?
Can sensitive tools require explicit approval?
Can responses be filtered before they re-enter the model context?
Can every tool call be tied to a user, policy, resource, and timestamp?
Can dangerous local execution paths be disabled or isolated?
Can the organization revoke access quickly?

The teams that answer those questions early will have a much easier time moving from prototype to production.

What builders should do now

The next few weeks are a good time to review MCP systems with production assumptions.

First, track the 2026-07-28 specification work. The release candidate contains breaking changes, and the final specification is planned for July 28. Teams running MCP servers should test stateless request handling, discovery, tool schema compatibility, and any features affected by deprecations.

Second, move state into explicit handles where that makes sense. Do not rely on hidden protocol sessions to carry workflow meaning. Make handles scoped, short-lived, auditable, and boring.

Third, treat authorization as part of the tool call, not just part of login. An agent should not inherit broad access because a user authenticated once. The system should decide whether this user, through this agent, can take this action, on this resource, right now.

Fourth, build logs for humans who were not in the room. A good audit trail should explain what the agent saw, what tool it called, what arguments it used, what policy applied, what the server did, and what result came back.

Fifth, separate reasoning from control. The model can decide what it wants to do. The control layer decides what it is allowed to do.

That separation is going to become one of the defining patterns of production agent infrastructure.

For AIvikings, this is not abstract. Domain operations are tool calls with real-world effects. A domain registration, renewal, nameserver update, or reconciliation job needs more than a clever prompt. It needs a control layer around the action. That is why our MCP server, docs, and comparison page focus on bounded domain operations rather than a giant pile of vague tools.

MCP is growing into the boring layer agents need

The first phase of MCP was about access.

Can the agent reach the database? Can it call the API? Can it list the tools? Can it pull the context into the conversation?

The next phase is about control.

Can the agent act safely? Can the system prove what happened? Can admins set policy? Can developers operate servers without special routing tricks? Can security teams see enough to trust the workflow?

That is why the current MCP moment matters.

The protocol is becoming more operational. Platforms are adding registries, containment, and auditability. Security teams are pushing harder on governance. Startups are raising money around the action layer. Research labs are treating agents as actors that need external supervision.

None of that is as flashy as a new model demo.

But it is probably more important.

Agent systems do not become useful when they get more tools. They become useful when they can use the right tools, under the right permissions, with a record everyone can understand later.

That is the MCP story to watch now. If you are building agents that need to own or operate domains, contact us.