ttlMs is omitted by default where the 2026-07-28 draft makes it required #1546

Found by the agents conformance suite (#1545).

What

The 2026-07-28 draft schema makes ttlMs a required number on CacheableResult (ttlMs: number, minimum 0). mcpkit omits the field whenever no TTL is configured:

• tools/list, resources/list, resources/templates/list and prompts/list take listTTLMs, which is nil unless WithListTTLMs / WithListCacheControl is set (server/dispatch.go:583, :765, :841, :907).
• agents/list and agents/get take agents.Config.TTLMs, nil by default.

docs/LIST_TTL_MIGRATION.md treats an absent ttlMs and 0 as the same thing on the client side, which is still right for reading older servers. What we send on the draft wire is a separate question.

Evidence

sep-9998-agents-discovery grades list-cacheable and get-cacheable against the draft schema. With Config.TTLMs nil, both fail (26/28). The agents fixture sets a TTL, so #1545 runs green.

Open question

Should a server with no configured TTL send "ttlMs": 0 (immediately stale, which is what absent means to a client anyway) on the 2026-07-28 wire, and keep omitting it on 2025-11-25? A default change is a wire change, so it wants deciding before the 1.0 freeze, alongside #1356.

Closes when

On the 2026-07-28 wire, every CacheableResult mcpkit sends carries ttlMs, or there is a recorded decision that it should not, with the reason.