A ttlMs on tools/list is a promise, not a receipt

The 2026-07-28 MCP spec added `ttlMs` and `cacheScope` stamps to `tools/list` under SEP-2549, modeled on HTTP `Cache-Control` ^[1]. A write-up from the mcp-better project argues that those fields are a server's statement about later reuse, not evidence of it, and that a client confirming the fields are present and well-formed has proved only that the server said something ^[2][3].

The mechanism is dull and therefore likely. A server can emit `ttlMs: 60000` with `cacheScope: Public` and change its catalog on the very next call; the stamp remains syntactically valid and a presence-only probe still passes ^[4]. Sixty thousand milliseconds is a minute of a client happily calling tools that the server no longer lists ^[5]. The post's framing of the official pitch is that clients now know exactly how long `tools/list` is fresh ^[6]; its counter is that HTTP taught this lesson already, since `max-age=60` was never proof that the next GET returns the same bytes, and MCP imported the words without importing a test ^[7].

The interesting part is the author's own bug. Their `contrast-smoke` example paired a good server with a labeled liar, `mcp-worse`, and gated on one boolean: unstamped OR wrong catalog order ^[8]. Then `mcp-better` grew a third tool, `confirm_echo`, so the name mismatch became permanently true and the stamp half of the check stopped carrying weight ^[9]. Had `mcp-worse` later gained stamps, the example would still have printed OK, failing on contents alone, with the negative case for `ttlMs` silently gone ^[10]. The guard meant to keep the companion a reliable liar only fired when every clause went green at once, which makes partial decay invisible ^[11]. The author credits a commenter with naming it, and states the rule as one smallest lie per claim: a liar that fails for two reasons is weaker evidence than two liars that each fail for one ^[12][13].

The current tree splits the predicate into `is_unstamped` and `wrong_names`, both of which must stay true on the companion, and exits non-zero naming the clause that went green ^[14]. The published `v0.5.0` tag still ships the OR ^[15]. Captured output from 2026-08-19 shows the good server at `ttl=Some(60000) scope=Some(Public)` and the companion at `ttl=None scope=None` ^[16].

Even fixed, the author is explicit that this is not a cache test. Order is a property of the list the probe is holding and can be inspected; `ttlMs` and `cacheScope` describe how that list may be reused later ^[17]. Falsifying a TTL claim needs an observation pair that straddles a change, and since the lab's catalog is compiled in, the claim cannot be violated yet: declared, not falsified ^[18]. The related `order-restart-smoke` check compares `ttl_a == ttl_b` across two processes, which tests that the number is restart-stable, not that the caching behavior it describes holds ^[19].

The operator reading is short. If you are building an MCP client, invalidation has to be yours, because the stamp is the server's assertion about its own future. Watch for the moment catalogs stop being compiled in and start being generated: the post argues `ttlMs` is then the first stamp with room to lie and the clause with the least behind it ^[20].