The whole internet read one word in the 2026-07-28 Model Context Protocol revision: stateless. Fair enough — deleting the session is the headline, and we wrote that story too. But the same release quietly shipped the other half of the trade, and it's the half that shows up on your bill: response caching.

If you only remember one thing: statelessness makes MCP cheap to deploy; caching is what keeps it cheap to run.

The two fields nobody mentioned#

In the new spec, list and resource-read results — the ones a client fetches to learn what your server can do — now carry caching metadata. Two fields, "modeled on HTTP Cache-Control" in the RC's own words:

That's it. Two fields. And they exist because of the word everyone did read.

Why stateless needs a cache#

Here's the mechanism the headlines skipped. In the old, session-based MCP, a server could keep a long-lived SSE stream open and push you a notification the moment its tool list changed. You held the connection; the server told you when to care.

Stateless requests can't be pushed to. There's no connection to hold. So how does a stateless client know its cached tool list is still valid? Before this spec, the honest answer was: it doesn't — so it re-requests tools/list defensively, often on every single turn.

That re-request is not free, and the round trip is the cheap part. The expensive part is what happens next: your client takes that tool catalog and injects it back into the model's context — every tool name, description, and JSON schema — so the model knows what it can call. Do that on every turn and you're paying, in input tokens, to re-teach the model a tool list that hasn't changed since breakfast.

ttlMs is the fix. It lets a stateless client trust the last catalog for a known window: skip the round trip, and — the part that matters — skip re-injecting an unchanged tool catalog into the prompt. Statelessness took away the push; caching gives back the "you can stop asking."

cacheScope is a security field wearing a performance costume#

ttlMs saves you money. cacheScope keeps you out of an incident review.

Picture a server whose tools/list varies by permission: an admin sees a delete_account tool, a regular user doesn't. Cache that response with a shared scope and your client can hand one user's tool set to another. That's not a slow page — that's an authorization leak served from cache.

The mental model is exactly the HTTP one the spec borrowed from: cacheScope is the difference between Cache-Control: public and Cache-Control: private. If a list depends on who is asking, it is per-user, full stop. When in doubt, scope it narrow — a cache miss costs tokens; a cache leak costs trust.

Don't confuse this with your model provider's prompt cache#

One clarification, because founders conflate these constantly. Provider prompt caching (Anthropic, OpenAI, and friends) caches the model's processing of a stable prompt prefix to cut input cost. MCP response caching lives one layer up, in the client↔server tool channel — it decides whether your client even asks the server for the tool list again, and whether it re-injects that list into the prompt at all.

They aren't rivals; they compound. MCP caching keeps your tool catalog byte-stable across turns, which is precisely the condition provider prompt caching needs to score a hit on your system prompt. Get MCP caching right and you make the other cache work harder for free.

What to actually do before Monday#

The final spec lands July 28. The SDK betas are already out for Python, TypeScript, Go, and C#. Three moves, in order of payoff:

  1. On every list/resource handler, set ttlMs. If your tool list changes rarely, a generous TTL (minutes) is the single biggest per-turn saving you'll get from this whole migration.
  2. Set cacheScope deliberately, defaulting to per-user. Only mark a response shareable if it genuinely does not vary by who's asking.
  3. Make sure your client honors both. A stateless client that ignores ttlMs re-fetches forever — you'll have done the work and kept the bill.

The stateless story got the headline because subtraction is dramatic. But the two-field caching story is the one your finance dashboard will notice. If you're doing the migration anyway — and after July 28, you are — do both halves. The hands-on version, with code, is in our companion how-to: How to Add Response Caching to Your MCP Server.