The stateless MCP standard for voice AI

The co-creators and maintainers of Model Context Protocol did something unusual this week after they shipped the largest change in the protocol's twenty-month history. They told everyone how the changes will impact the cost to use MCP.

That candor is worth noting. The TL;DR: making the protocol stateless means information that used to be exchanged once now travels with every single request. Payloads get bigger.

Lead maintainer David Soria Parra, speaking to VentureBeat, said the payload increase barely registers: the extra bytes compress well, they're well understood, and they're still fairly small compared to, for example, an HTTP request on the web, which is something people don't notice.

Most of the coverage on the MCP updates reads that verdict against a coding-agent use case: A client holds one long session open with its tools, and going stateless means giving up on reusing it. Voice AI doesn't use MCP that way. A voice agent makes a handful of discrete tool calls within a two-minute conversation, each one operating as a self-contained request with a hard timeout and caller on the line. That difference matters in where this MCP update really provides value.

First, what "stateless" actually means

MCP is the standard that lets an AI agent talk to the software a business already uses: its CRM, booking engine, ticketing system. It has become the connective tissue for agentic AI, and usage is growing fast. Soria Parra says SDK downloads have doubled in six months, now at roughly 250 million per week.

Under the old protocol design, a conversation between an agent and one of those systems started with a handshake: The client introduced itself: “Here's my protocol version, here's what I can do,” and the server handed back a session ID. Every request from then on had to carry that ID, which meant every request had to return to the same server instance that issued it.

That's fine on a laptop. It's miserable in a data center. Cloud deployments run fleets of interchangeable machines that start and stop constantly, and the old design insisted that your agent keep talking to one specific machine. If that machine went down mid-task, the work went with it. Den Delimarsky, another lead maintainer of MCP, describes the old failure mode plainly: A compute pod goes down, and requests simply start failing.

The new spec removes the handshake and the session ID entirely. Every request now carries everything a server needs to understand it, meaning any server can handle any request, similar to how an internet browser works with any machine.

Nothing is free, however. If a server no longer remembers who you are, you’ll have to tell it every time. That's adds payload to every call.

Sessions were never the right abstraction for tool calls

This is where the coding-agent framing and the voice framing pull apart.

A coding agent holds one long session with its tools for the length of a task. Reusing that session was the entire point: handshake once, then lean on it repeatedly. For that use case, going stateless is a real trade-off: gain resilience, give up reuse.

One new mechanic is worth flagging, mostly to rule it out: how the spec handles requests that need input mid-task. Instead of holding a connection open, the server now returns early with a reference number, and the client gathers the answer and re-issues the request. That's a sensible pattern for a session-based system; but it doesn't map onto how Parloa’s tool calls work. When our agent needs something from the caller, it asks directly, then makes a fresh tool call with the answer. There's no session to re-issue into.

This is because Parloa's runtime for voice AI treats every MCP tool call as its own self-contained HTTP request (check a booking, update a CRM record, look up a ticket, etc.), with no session to reuse. There's nothing for us to give up here, because we were never spending it.

Tool discovery is the clearest example. The spec's new caching option lets an agent cache a server's tool list for a set freshness window, instead of re-fetching it every session. That's a real efficiency gain for anyone re-fetching tool lists live. For Parloa, however, tool discovery happens only once, at configuration time, making the update insignificant. An admin connects a server in AMP and selects the tools it exposes so it’s already cached, well before any call happens. 

So fetching doesn’t determine latency. Response time (and if there’s a response at all), does. Both are configurable through timeouts and a structured error path that tells the agent whether to retry, say something to the caller, or hand off. Neither of these are protocol behaviors. They both live in the harness.

Security improvements should also be in the headlines

We talk a lot about the pilot-to-production problem, and in the VentureBeat piece, Mazin Gilbert, Executive Director of the AAIF and a veteran of Google and AT&T, argues that security concerns are a key reason for that gap. That's why the three security changes shipped alongside the stateless core matter more to a regulated deployment than load balancing ever will.

1. Authorization got hardened.

Clients must now verify which identity server actually sent an authorization response, closing off a class of attack where a client can be fooled into trusting the wrong one.

2. Enterprise-managed authorization became stable.

Previously, every employee had to individually authorize every MCP server, producing IT ticket queues, no central audit trail, and no reliable way to cut off access when someone left. Now, an administrator approves a server once, using the identity provider the company already uses, and authorized staff inherit access as soon as they log in.

Parloa approaches authorization differently. We manage MCP connections at the tenant level, meaning an admin configures a connection once and every agent in that tenant uses it. The per-employee gap this feature closes already didn’t exist in our system. 

Important to note: Enterprise-managed authorization answers “may this agent reach this server.” It doesn't answer “may this agent cancel this policy? for this caller, on this call, right now.” The spec is explicit that the identity provider has no visibility into the traffic itself. Per-action decisions are a separate problem that belongs in the harness.

3. A deprecation policy was introduced.

In consultation with Google, Microsoft, and Amazon, a minimum of twelve months is now required between a feature being deprecated and it being removed. For a bank counting on its integrations to still work next year, this might be the most valuable part of the release.

As the protocol gets smaller, the harness gets bigger

The largest revision in MCP's history is mostly subtraction. And the maintainers are explicit that this was the point. Delimarsky confirms they deliberately shifted the responsibility of creating and managing state to the developers, so teams can handle it however suits their environment.

We've argued before that the model is rarely the bottleneck, and that the scaffolding around it, the configuration, the skills, the orchestration, the guardrails, is where enterprise performance is won or lost. This release is strong evidence for that argument, and the proof comes from the protocol's own authors. Every responsibility the spec moved out landed somewhere. In production, that somewhere is the harness.

For Parloa, that's not a new obligation. That’s the standard we’ve been building towards. Tool-call timeouts, structured error handling, retry decisions, tenant-level connection management, those all exist in the harness we already built because we never treated MCP tool calls as anything other than discrete, stateless requests inside a live conversation.