Two fields showed up in the 2026-07-28 MCP release candidate that look like a footnote and read like a performance tweak: ttlMs and cacheScope. They attach to the results of tools/list, prompts/list, resources/list, resources/read, and resources/templates/list — the five requests a client makes to find out what a server offers. The pitch, everywhere it's been written up, is stop your clients from re-polling. That's true of one of the two fields. The other one is a security boundary, and it is going to be mistaken for a performance knob for exactly as long as it takes someone to leak a user's data with it.
What SEP-2549 actually adds#
SEP-2549 — merged in May, riding into the July release candidate — models both fields on HTTP's Cache-Control header, and the borrowing is not cosmetic.
ttlMsis a freshness hint in milliseconds. It'smax-age: the server telling the client "you may treat this list as current for this long." It is explicitly not a polling interval. A client caches the result and re-fetches only when it needs the data and the clock has run out. The spec adds that a client which does insist on polling should apply jitter and backoff, and — importantly — TTL supplements the existinglistChangednotification rather than replacing it. A server can still push "your tool list changed" before the TTL expires. Belt and suspenders.
cacheScopetakes one of two values,"public"or"private", lifted verbatim fromCache-Control. It answers a different question: not how long, but who is allowed to keep a copy.
ttlMs is the one everyone will reach for, because it does the obvious thing — cuts chatter, shaves latency, keeps a busy client from hammering tools/list every turn. Get it wrong and the worst case is a stale list: the agent doesn't see a tool you added until the TTL lapses. Annoying, self-correcting, forgotten by lunch.
cacheScope is the one that deserves the attention ttlMs will get.
The word that isn't about speed#
Here's the throughline the RC is built around, stated plainly by the maintainers: with these fields, clients know exactly how long a tools/list response is fresh and whether it's safe to share across users. Read that second clause again. "Safe to share across users" is not a sentence about performance. It's a sentence about trust boundaries.
cacheScope: public doesn't make a response faster. It makes a response shareable — and shareable across principals is a security claim, not a caching one.
The reason this field exists is the same reason MCP just went stateless: the protocol is deliberately becoming plain HTTP so it can inherit HTTP's twenty years of scaling infrastructure. SEP-2567 removed protocol sessions and the Mcp-Session-Id header; SEP-2243 added Mcp-Method and Mcp-Name routing headers so a gateway can route without reading the body; SEP-2549 added these cache directives. The payoff is that a remote MCP server can now sit behind a round-robin load balancer, a shared gateway, and a CDN — the same commodity boxes that cache the rest of the web.
But a shared cache is shared. The moment a shared intermediary is allowed to store a response, "who may read it" stops being a question your application answers and becomes a question your cache directive answers. That's the whole reason Cache-Control: private exists in HTTP: in the 2000s, shared corporate and ISP proxies cached authenticated pages marked cacheable and cheerfully served one logged-in user's account page to the next person behind the same proxy. private was the fix — a one-word promise that says "a browser may keep this, a shared box between us may not." MCP just imported that exact word, and with it, the exact way to get burned.
The trap is the blanket default#
Now put the two facts together. The five methods that gained cacheScope split cleanly by nature:
tools/listandprompts/listare usually the same for everyone. A weather server offers the same tools to every caller. Marking thesepublicis a real, free win — a CDN can answer them and your server never sees the request.resources/readandresources/listalmost always return user-specific content. The resource is a user's file, a user's inbox, a row scoped to their account. This is precisely the response that must stayprivate.
The footgun is that these live on one server, and a server author under deadline sets one caching policy for the whole thing. Flip everything to public because the tools/list speedup looked great in the benchmark, and you've told every shared cache on the path that user A's resources/read result is fine to hand to user B. There's no error, no exception, no failed request. The cache does exactly what you authorized. The leak is silent, and it scales with your cache hit rate — the better your caching works, the worse the breach.
That's the non-obvious shape of this change: ttlMs and cacheScope sit next to each other in the schema and look like a matched pair of speed dials, but they belong to different departments. One is an optimization you tune. The other is an authorization you assert, per response, and the safe default — the one to reach for unless you can prove the response is identical for every principal who could ever request it — is private.
Cache the world's answers if you want the speed; MCP now gives you the vocabulary to do it behind ordinary HTTP infrastructure. Just remember that in a multi-tenant protocol, caching was never only a performance decision — and the field that admits it is spelled cacheScope, not ttlMs.
