MCP tools/list responses missing ttlMs/cacheScope (SEP-2549) since 1.33.0 — breaks Claude Code

[sachajw]

Summary

Since 1.33.0, fnox's mcp server negotiates MCP protocol version 2026-07-28 and returns tools/list results tagged resultType: "complete", but omits the caching-hint fields (ttlMs, cacheScope) that SEP-2549 requires to accompany that field for that protocol version. This causes strict-schema MCP clients (e.g. Claude Code) to reject the response entirely, so the fnox MCP server shows connected but tools cannot be fetched.

(Repo issues appear to be disabled, so posting here instead — happy to move this if there's a better venue.)

Reproduction

Client-side error (Claude Code /mcp):

Invalid result for tools/list: [
  {
    "expected": "number",
    "code": "invalid_type",
    "path": ["ttlMs"],
    "message": "Invalid input: expected number, received undefined"
  },
  {
    "code": "invalid_value",
    "values": ["public", "private"],
    "path": ["cacheScope"],
    "message": "Invalid option: expected one of \"public\"|\"private\""
  }
]

Confirmed via a direct hand-crafted MCP initialize + tools/list JSON-RPC handshake against the fnox binary itself (not just the client's interpretation) — the raw response includes "resultType":"complete" with no ttlMs/cacheScope keys present.

Root cause (as far as I can tell)

This tracks a dependency bump, not an fnox code change:

fnox version	rmcp (locked)
1.31.0	2.2.0
1.31.1	2.2.0
1.32.0	2.2.0 — works, old-style response (no resultType/ttlMs at all)
1.33.0	3.1.0 — breaks, resultType: "complete" present without ttlMs/cacheScope
1.33.1 (latest)	3.1.2

rmcp 3.x appears to have picked up the SEP-2549 "TTL for list results" caching feature (tagging responses with resultType) without also emitting the accompanying ttlMs/cacheScope fields the spec requires alongside it — so any client doing strict schema validation on that response shape rejects it.

Spec reference

Per the MCP spec for protocol 2026-07-28 (SEP-2549): a result with resultType: "complete" must also carry ttlMs (number, ms) and cacheScope ("public"|"private"). Omitting ttlMs/resultType entirely is a valid backward-compatible old-style response ("this should only occur in older server versions") — but tagging resultType: "complete" while omitting the other two fields is not spec-compliant.

Workaround

Pinning to fnox 1.32.0 (rmcp 2.2.0) restores a working MCP connection, since it predates the resultType field being emitted at all.

Suggested fix

Either populate ttlMs/cacheScope on responses that set resultType: "complete", or omit resultType until fnox is ready to fully support SEP-2549 caching semantics.

Happy to provide the full raw JSON-RPC transcript if useful.

[jdx]

Thanks for the detailed report. I reproduced the strict-schema failure with a direct 2026-07-28 initialize + tools/list handshake.

The fix is in #727. It adds the conservative cache hints ttlMs: 0 and cacheScope: "private", preserving the existing no-cache behavior while making the response compliant for strict clients. It also includes a regression test, and the direct wire response now contains all three fields.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.