Caching and pagination without data leaks

The mechanism

Caching reduces repeated discovery and context reads, but a cache can also cross an authorization boundary. Current cacheable results include a nonnegative ttlMs and cacheScope. Private results may only be reused within the same authorization context; a tenant label alone may not capture different scopes or object permissions.

Cache identity includes the method and result-affecting parameters. A resource URI, list cursor or protocol-sensitive argument can change the result. Responses produced through multi round-trip input are excluded from caching because they depend on additional state and input.

Pagination is a traversal mechanism, not a guarantee that the underlying list stays frozen. Treat the cursor as an opaque server token. Decide how a changing catalog affects deduplication, missing entries and user review.

Worked example

This is application pseudodata for a cache review. It intentionally uses an opaque authorization-context identifier instead of a raw bearer token. Never log tokens as cache keys. A production cache should derive a safe internal identity that changes when relevant grants change.

{"method":"resources/read","params":{"uri":"parcelops://incidents/INC-104"},
 "auth_context":"opaque-principal-and-grants-v3",
 "received_monotonic_ms":1000,"ttlMs":5000,"cacheScope":"private",
 "reusable_at_5999":true,"reusable_at_6000":false}

Practice: predict, inspect, explain

Offline exercise. Consider the same URI requested by two principals, one principal after scope revocation, and a second page with a different cursor. Explain which cache entries can be reused. Then insert a new tool between page requests and describe how your catalog renderer handles duplicates.

Expected observation: a private cache miss is correct when relevant authority changes. TTL expiry means revalidate when the data is next needed; it is not an instruction to start background polling. Keep result provenance visible so stale data is not mistaken for a new observation.

Troubleshooting and trade-offs

If users see another user’s records, disable the affected cache path and inspect authorization partitioning. If every request misses, check canonical parameter construction and accidental volatile metadata in the key. Do not invent a globally stable snapshot from paginated responses unless the server explicitly supplies that guarantee. Cache hints optimize access; they do not lock the underlying data.

Interview practice

Completion check

Explain the exact expiry boundary and reject cross-principal reuse without storing credentials in the key.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Caching
• Official documentation: Pagination
• Official documentation: Tools