Cacheability

Expanded Definition

Cacheability is the property of a response that allows it to be safely reused for a defined period instead of being recomputed on every request. In practice, it trades a small amount of freshness for lower latency, reduced backend load, and more predictable system behaviour. In the updated MCP model, cacheability is explicit because list responses can carry TTL metadata, so clients and intermediaries know when a result is still valid.

The boundary matters. A cacheable response is not a permanently stored answer, and it is not a license to ignore change events, authorization changes, or data sensitivity. The TTL defines the trust window, while the underlying source of truth still governs correctness. For practitioners, the common mistake is assuming that “faster” and “safe to reuse” are the same thing; they are only equivalent when the response is stable enough, scoped correctly, and invalidated on time.

Examples and Use Cases

• A tool lists available resources once, then reuses that list briefly while the user continues the same workflow, avoiding repeated discovery calls.
• An API gateway caches a response for a short TTL to reduce read pressure on a backend service during bursts of identical requests.
• A client caches a directory or catalog response, then refreshes it when the TTL expires so it does not keep using stale metadata.
• An MCP server marks a list response as cacheable when the result is expected to change slowly and the cost of recomputation is material.
• A build or orchestration system uses cached metadata to speed up repeated lookups, but still revalidates before any action that depends on the latest state.

The tradeoff is straightforward: longer cache life improves efficiency, but it also increases the chance of serving outdated data. Short TTLs reduce staleness but can erase the performance benefit if every request has to revalidate almost immediately.

Security Implications

Cacheability becomes a security issue when stale data is treated as authoritative. If cached responses outlive the state they describe, systems can expose outdated permissions, obsolete inventories, removed resources, or incorrect operational assumptions. That can lead to failed access decisions, inconsistent policy enforcement, or user actions being applied to objects that no longer exist.

It can also widen the blast radius of a bad response. If one incorrect list or metadata object is cached widely, multiple clients may keep consuming the same wrong view until the TTL expires or the cache is purged. A practical symptom is disagreement between what one component sees and what the source system currently reports. In security-sensitive workflows, that mismatch is often more dangerous than the performance cost the cache was meant to avoid.

For that reason, cacheability should be treated as a controlled freshness decision, not just an optimisation knob. The more security or governance significance a response has, the more carefully its reuse window should be bounded.

Security, Operational and Governance Implications

Cacheability matters because it defines how long a system is willing to trust prior state. That affects not only performance, but also operational consistency, auditability, and change control. When TTL metadata is well designed, teams can reason about freshness explicitly instead of relying on undocumented client behaviour or ad hoc invalidation.

In governance terms, cacheable responses should be reviewed like other stateful controls: who can reuse them, how long they remain valid, what happens when the underlying object changes, and how the system handles cache bypass or purge. In operational terms, the key question is whether the cached response is merely convenient or whether it is used to drive a downstream decision. The second case deserves much tighter expiry and validation discipline.

A good implementation makes the freshness boundary visible. A weak implementation hides stale data behind a performance gain.