Summary

Every list_tools(), list_prompts(), and list_resources() call makes a fresh network request. For high-traffic use cases (gateways, proxies, multi-tenant deployments), this creates significant redundant load on upstream MCP servers.

The SDK should explore offering opt-in client-side caching for these list operations, with invalidation driven by list_changed notifications (see #2107).

Open Questions

• Where does the cache live? In-memory on the Client/Session, or pluggable (Redis, etc.)?
• What is the cache key? Per-session? Per-server URL?
• What is the default TTL, if any, independent of list_changed notifications?
• Should this be a feature of Client, ClientSession, or a separate component?
• How does this interact with stateless HTTP mode where there is no persistent session to receive notifications?