MCP Tool Bloat: The Stateless Spec Doesn't Fix It

The MCP specification published on 28 July 2026 removed the initialize/initialized exchange and the Mcp-Session-Id header from the protocol core. Every request now carries protocol version, client identity and client capabilities in _meta, so any server instance can answer any request with no shared session storage. The same release made list results cacheable, and a lot of the commentary since has read that second change as the answer to MCP tool bloat. It addresses a different bill.

What changed in the 2026-07-28 MCP spec

Three changes matter if you run an MCP server for other people.

The handshake is gone. The spec post says the release “officially retired the initialize/initialized exchange along with the Mcp-Session-Id header.” State that used to live in a session now travels on each request.

Mcp-Method and Mcp-Name became required headers on streamable HTTP requests, so gateways, rate limiters and firewalls can “route and meter on those headers instead of parsing JSON bodies.”

List results for tools, prompts and resources now carry ttlMs and cacheScope, modeled on HTTP Cache-Control. Clients can cache a tool catalogue and, in the spec’s own words, “keep upstream prompt caches stable across reconnects.”

Stateless MCP was overdue

Google’s engineering team published a write-up on 5 August on what session pinning did to a cloud-native MCP deployment. A plain round-robin load balancer would route a request to an instance that had never seen the handshake, and the client got back 400 Session Not Found. The usual workarounds were sticky sessions at the balancer or a shared session store such as Redis, and both of those turn something that looks like a stateless HTTP endpoint into a stateful service with its own failure modes.

Removing the handshake makes an MCP server behave like an ordinary HTTP API. Horizontal scaling, blue/green deploys and autoscaling stop needing special handling. For anyone shipping an MCP server as a product surface, this is the most useful change in the release.

Where MCP tool caching helps, and where it stops

An agent pays for its tools in two places, and the two are easy to conflate.

The first payment is the round trip that fetches the catalogue from the server. Set a sensible ttlMs, cache the response, and that cost approaches zero. Fewer tools/list calls means less serialization and less egress on the server side. That is a genuine win and the spec delivers it cleanly.

The second payment is the context window. Every definition the client hands the model, the name, the description and a JSON Schema for every parameter, occupies tokens in the request. Prompt caching at the model provider makes those tokens cheaper to bill, and the spec explicitly aims at keeping that prefix stable across reconnects. Cheaper is not the same as gone, and the definitions still sit in the context the model reasons over, where they compete with the task for the model’s attention.

The second bill: tool definition tokens in the context window

GitHub’s official MCP server exposes 94 tools whose definitions come to roughly 17,600 tokens, as measured by Atlassian’s mcp-compressor project. Those tokens are in the request before the agent reads the first word of the task.

One server is affordable, but real deployments are never one server. Connect an issue tracker, a CRM, a document store and an HRIS, and the catalogue an engineering lead is quietly shipping on every turn is several times that. StackOne covered why a cheaper model does not fix this in a separate post on why a cheaper model does not cut an agent’s token bill: the schemas, not the reasoning, are usually the larger line item.

Tool selection degrades before the context window fills

Token cost is the argument people reach for first, and it is the weaker half of the case. Context windows are large enough now that 17,600 tokens looks survivable.

Selection accuracy is the constraint that bites earlier. Anthropic’s engineering write-up on advanced tool use measured Claude Opus 4 choosing the correct tool 49% of the time with the full catalogue preloaded, against 74% when the model searched for tools on demand. The model and the tools were the same in both runs, so the 25-point swing comes entirely from how the tools were presented to it.

That result should change how you read the caching change. A perfectly cached catalogue is still a catalogue the model has to read past. Caching makes a big tool list cheap to serve and does nothing about the fact that a big tool list is harder to choose from.

What teams do instead: search, then execute

The pattern that has spread over the past year is a proxy that hides the catalogue behind two meta-tools. Atlassian’s mcp-compressor does exactly this: it replaces a server’s tool list with get_tool_schema and invoke_tool, and the README reports 70 to 97% token reduction depending on which server it wraps. The agent asks for what it needs, gets one schema, and calls it.

StackOne never had preloading available as an option. Our catalogue is 28,000+ actions across 450+ connectors, and no context window is going to hold that, so the agent gets two meta-tools by default: search the action catalogue, then execute the returned action by ID. The prompt footprint stays flat whether a customer has one connector enabled or two hundred. The site quotes 78% average tokens saved and 91.6% first-try tool selection on our internal S1 Search Bench. The retrieval side turned out to be a search problem rather than a model-size problem, covered in a separate post on how a 109M-parameter embedding model beat an 8B model on tool retrieval.

None of that is in the specification, and it does not need to be.

Transport is standard, tool discovery is not

The 2026-07-28 release standardised the part a protocol can standardise. Any MCP client now talks to any MCP server over plain stateless HTTP, gateways can route without parsing bodies, and clients have a defined way to cache a catalogue instead of refetching it. That is a good release, and if you operate an MCP server you should adopt it.

Tool discovery is still every vendor’s own invention. Proxies, filters, meta-tools, semantic search over actions, hand-curated allowlists, each team builds its own and none of them interoperate. That is also true of the governance layer, which the spec leaves as an execution gap for deployers to close: which agent may run which action against which system of record is not something the protocol tries to answer.

So when you audit your agent’s token bill this quarter, separate the two numbers. Measure what your server spends answering tools/list, then measure how many tool definition tokens enter the model on a turn where the agent needs exactly one of them. The spec improved the first of those numbers, and the second is still yours to manage.

If you want the mechanics of runtime action search, the StackOne docs cover how an agent finds and executes an action without preloading the catalogue.