A client cached a tools/list result that carried a ttlMs of 300000. Two minutes later, while that cached list is still fresh, the client receives notifications/tools/list_changed on its subscriptions/listen stream. What should the client do with the cached list?
Select an answer to reveal the explanation.
Short Explanation
A TTL is the "best before" date on the milk carton, but the notification is someone telling you the milk just went sour. You don't wait for the date — you toss it now. The trap is treating ttlMs as a promise that nothing changes until it expires.
Full Explanation
TTL-based caching and change notifications are complementary in MCP. The ttlMs field lets a client avoid needless refetches while a result is fresh, and a list_changed notification acts as an immediate invalidation signal. The caching rules say that when a relevant notification arrives while a cached response is still fresh, the notification invalidates that response and it must be considered immediately stale; the next time the client needs the tool list it fetches tools/list again. Continuing to serve the old list for the rest of the TTL treats a freshness hint as a guarantee, which the spec explicitly says it is not; servers may change data before the TTL expires. Re-opening the subscription is unnecessary because a notification does not end a subscriptions/listen stream; the stream stays open until the client cancels it, the server ends it, or the transport closes. Calling server/discover does nothing for this problem, since capabilities did not change and discovery is not a prerequisite for list requests in a stateless protocol. Exam caveat: the client only receives this notification because it opted in with toolsListChanged true; without that, it relies on TTL alone. Operational check: after a list_changed event, confirm the client's next tool lookup issues a fresh tools/list instead of reading its cache.