MCP's caching hints will hand Alice's tool list to Bob unless identity is in the key

The stable 2026-07-28 MCP specification defines caching hints for reusable results, letting a server declare a `cacheScope` of `public` or `private` alongside a `ttlMs` freshness window ^[1]. A dev.to walkthrough demonstrates that the declaration alone does not hold: with one shared client response cache and no partition, Bob's `tools/list` call returns Alice's private catalog ^[11][13].

The hint vocabulary is narrow and clear. Public results may be reused across authorization contexts even when the endpoint requires authentication ^[6]; private results may be reused only within the same authorization context ^[7]. The caching rules apply to discovery, tool and prompt lists, resource lists, resource templates, and resource reads ^[5] - which is to say, exactly the surfaces that differ per tenant. A server can attach a hint for `tools/list` with `ttlMs: 60_000` and `cacheScope: "private"` ^[8], a 60 second staleness budget ^[1].

The gap is on the client side. A cache key needs the method and every parameter that can change the result, but authorization identity normally travels outside the `tools/list` parameters, so the client needs a separate partition for it ^[9][10]. The hint communicates the server's intent and nothing about which caller made the request ^[4]. The unsafe configuration is small: two authorization contexts, one response cache, no partition ^[11].

The author's reproduction uses two in-process endpoints sharing the same MCP server identity, one exposing an Alice-only tool and one a Bob-only tool ^[12]. Alice populates the shared store first. Bob then issues the same method with the same parameters against the same server identity, and receives Alice's cached tool list while his own endpoint handles zero `tools/list` requests ^[13]. That detail is the operational sting: the leak leaves no request on the serving side to log, alert on, or rate limit. The official TypeScript SDK v2 caching guide warns that this configuration can serve one user's private response body to another, according to the post ^[14]. The regression test is written to pass when it reproduces the unsafe result, and needs no credentials, network service, model, or paid API call ^[15].

The fix is a stable `cachePartition` per authorization context, such as `subject:alice` and `subject:bob`; with it, both endpoints receive one request each and each client sees only its own tool ^[16][17]. The author's guidance is to derive that partition from a stable, opaque authorization identity covering every dimension that can change visibility - tenant, subject, role, effective scope - and warns that a raw bearer token is a poor partition because it is secret material and can rotate while the principal stays the same ^[18][19]. Public entries stay shareable across principal partitions, since the server explicitly declared them safe ^[20].

Two limits are worth writing on the whiteboard. `cacheScope` controls reuse, not access: the server must still authenticate the caller and authorize every uncached request ^[22]. And a TTL is a freshness hint, not revocation, so waiting for a private entry to expire may be too slow after a permissions change ^[23]; the spec puts invalidation on the client, though the source text breaks off mid-sentence on the trigger ^[24].

Watch three things in your own stack. Whether any gateway or multi-tenant proxy you run sets a partition at all when one store serves many principals ^[21]. Whether your SDK version refuses to cache private entries in an unpartitioned store or silently accepts it, which is the behaviour the demonstration exercises ^[13]. And whether your invalidation path can beat the TTL you configured when an entitlement is withdrawn ^[1][23].