An MCP server sits behind a shared caching gateway. Its resources/read results return each authenticated user's own open support tickets, so the content differs from one access token to the next. Which caching hint should the server attach to these results?
Select an answer to reveal the explanation.
Short Explanation
Think of a hotel key card: the front desk can photocopy the lobby map for everyone, but your room bill goes only to you. That's "private" — per-user content may be cached, just never handed to a different token. The trap is believing a short TTL makes "public" safe; it only shortens how long the wrong person sees your data.
Full Explanation
The 2026-07-28 caching model attaches two hints to cacheable results: ttlMs, a freshness hint in milliseconds, and cacheScope, which says who may share a cached copy. A value of "private" means the result contains data not meant to be shared between callers; it may be reused for the same authorization context, but caches must not be shared across authorization contexts, so a different access token needs a different cache. Per-user resources/read content is the textbook case. Marking it "public" with a short TTL still tells every gateway and proxy that any user may be served the stored copy, so the TTL only limits how long the leak lasts. A ttlMs of 0 alone does not express sharing scope at all; it marks the result immediately stale, and the server must still supply cacheScope. Omitting hints is also wrong: resources/read is explicitly listed with server/discover and the list operations as results that must carry caching hints when complete. Exam caveat: cacheScope is a caching instruction, not access control; the server must still enforce per-resource authorization on every read. Operational check: inspect a resources/read response for a user-specific URI and confirm cacheScope is "private" and the gateway keys its cache by access token.