MCP cacheScope addresses a subtle problem: a response can be fresh and still be unsafe for another user.
The stable 2026-07-28 MCP specification defines caching hints for reusable results. A server can mark a result public or private, while ttlMs says how long it may remain fresh. But a shared client cache still needs enough identity information to keep private entries apart.
If Alice warms a cache and Bob later uses the same store, an incomplete cache key can return Alice's result to Bob. I treat that as a security boundary worth testing.
Why MCP cacheScope needs a cache partition
The MCP caching specification covers discovery, tool and prompt lists, resource lists, resource templates, and resource reads.
