A client caches a tools/list result that carried a ttlMs of 300000. When should it fetch the list again?
Select an answer to reveal the explanation.
Short Explanation
ttlMs is a 'best before' date, not an alarm clock. You check it when you reach for the list and refetch only if it's stale, or right away if the server says the list changed. A polling timer is the trap.
Full Explanation
Cacheable results such as tools/list carry ttlMs, a server hint in milliseconds indicating how long the client may consider the result fresh, analogous to HTTP Cache-Control max-age; 300000 is five minutes. The client records when it received the response and treats it as fresh while the current time is earlier than the receipt time plus ttlMs. Once the TTL expires the response is stale, and the client SHOULD re-fetch on next access. The caching specification states that clients SHOULD NOT treat TTL as a polling interval that triggers automatic background refetches; freshness is checked when the data is needed, and implementations that do poll MUST apply jitter and backoff. A relevant notification, such as notifications/tools/list_changed, invalidates a still-fresh cache entry immediately. TTL is a freshness hint, not a guarantee, and servers may change data before it expires, so it cannot promise the list is unchanged. The rule that a response is immediately stale applies to a ttlMs of 0, or to an absent or negative value treated as 0, not to positive values. Exam caveat: cacheScope public or private controls who may share a cached response and is not an access-control mechanism. Operational check: confirm the client serves the cached list within five minutes, refetches on first use after expiry, and refetches immediately after a list_changed notification.