AI agents may rediscover available tools repeatedly because MCP clients need an up-to-date list of what a server can do. SEP-2549 adds server-provided freshness and sharing metadata—ttlMs and cacheScope—to list results, including tools/list. These fields help clients avoid needless refetches, but they do not make a response immutable or safe to share across users by themselves.
What SEP-2549 changes for MCP list results
SEP-2549, “TTL for List Results,” adds ttlMs and cacheScope to results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list. The proposal is authored and sponsored by Caitie McCaffrey, is marked final, and is included in the 2026-07-28 MCP specification revision. See the SEP-2549 proposal and the 2026-07-28 specification.
The design separates responsibilities: the server returns the feature set authorized for the request along with freshness and scope metadata; the client or intermediary decides whether it may retain and reuse that exact response. A server hint cannot make a user-specific response safe for a shared cache, and a client cache policy cannot replace notification handling or correct authorization.
How to interpret ttlMs and cacheScope
ttlMs is a freshness estimate
A positive ttlMs tells a client how long to treat the response as fresh, measured from when it receives the response. A value of zero means the response is immediately stale. The SEP is explicit: “A TTL is a freshness estimate, not a guarantee.” Underlying data may change before the suggested interval ends, so expiry is not the only reason to refresh.
cacheScope controls who may reuse a response
public: A shared cache may serve the response across users when the result is not user-specific.private: The response is confined to the requesting user’s client; a shared cache must not serve it to another user.
Choose public only when the returned data genuinely does not depend on the requesting user’s identity or authorization. When a result varies by user, private is the appropriate scope, even if its tool definitions look similar to those returned for other users.
#1 Best Overall
Why authorization must be part of the cache key
MCP server documentation allows a tools/list response to reflect the authorization presented with the request. The available tool set can therefore differ by user or permission context. A cache must preserve the identity and authorization context that determine the response; matching only the server address or method name is not sufficient for user-dependent results. The MCP tools documentation also recommends deterministic ordering when the underlying set is unchanged.
Deterministic ordering makes equivalent lists serialize consistently, reducing needless differences when definitions are included in an LLM prompt and supporting better prompt-cache reuse. It does not prove that two users can share an entry: authorization can still yield different sets.
Choose freshness and sharing policies deliberately
| Choice | Trade-off | Practical approach |
|---|---|---|
| Short TTL or long TTL | Shorter freshness windows can reduce the time a changed result goes unnoticed but prompt more frequent refetches; longer windows reduce refetches while increasing stale-data exposure. | Choose according to how often results change and the cost of a stale tool description. SEP-2549 sets no universal duration. |
| Public or private scope | Public scope allows broader reuse; private scope protects user-dependent responses from cross-user reuse. | Use public only for results that are genuinely the same across users; use private for authorization-dependent results. |
| TTL expiry or notification invalidation | Expiry provides time-based refresh; a change notification can prompt a faster response to an update. | Use both where supported. TTL supplements the existing notification mechanism rather than replacing it. |
| Whole-list or per-page caching | A whole-list model is simpler, while pagination requires accounting for separate page freshness and the lack of a guaranteed cross-page snapshot. | Cache pages independently and treat invalid cursors as a reason to discard the cached pages and restart. |
| Protocol metadata or SDK cache | Protocol metadata communicates server freshness and sharing scope; an SDK cache is a particular client’s local behavior. | Use each for its own role. An SDK option does not replace the protocol’s scope, TTL, or notification semantics. |
Combine TTL with change notifications and early refresh
The proposal states: “TTL supplements rather than replaces the existing notification mechanism — both can coexist.” If a server advertises list-change notifications, it should send the corresponding notification when the data changes before TTL expiry. Clients should invalidate or refresh affected entries on notification rather than waiting for the timer.
A client may also refetch before expiry when it has reason to suspect a cached definition is stale—for example, when a tool call fails in a way that suggests the tool is no longer available or its definition has changed. If that refresh fails because of a network or server error, SEP-2549 permits serving the stale response as a resilience fallback. That may keep an application usable, but it trades freshness for availability; it is not the normal freshness rule.
Handle paginated results as independent pages
Each page has its own TTL and freshness clock. SEP-2549 does not guarantee that pages fetched at different times form one coherent snapshot. A client that reuses an earlier page and fetches a later one may therefore see results from different underlying states.
- Cache each page with its own TTL and scope metadata rather than assigning the first page’s freshness to the entire result set.
- If a cursor is rejected or invalid, discard cached pages and fetch again from the beginning.
- When polling for changes, use jitter and backoff to avoid synchronized bursts of repeated requests.
Keep SDK caching distinct from SEP-2549
Protocol metadata and SDK caching solve related but separate problems. The OpenAI Agents SDK MCP guide documents that agents may call list_tools() on each run and offers optional in-memory caching with explicit invalidation. The guide advises enabling that option only when tool definitions are unlikely to change. That is an SDK-specific choice, not a protocol-wide default and not a substitute for honoring server-provided TTLs, scope, and notifications.
Check deployment support before relying on the fields
SEP-2549 is identified as part of the final 2026-07-28 specification revision, but that does not establish universal support across every MCP server, client, or intermediary. Check the protocol revision and SDK versions deployed at both ends. Where a component does not implement these fields, do not assume it is applying SEP-2549 caching behavior.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
