ttlMs is a non-negative number

How to fix this

Make `ttlMs` a non-negative number of milliseconds. It is a freshness hint, so a negative or non-numeric value gives clients nothing to act on.

Example: failing and passing

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [{ "name": "get_weather", "inputSchema": { "type": "object" } }],
    "ttlMs": -1,
    "cacheScope": "public"
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "tools": [{ "name": "get_weather", "inputSchema": { "type": "object" } }],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

How the validator checks this

Probe P2.1, against a streamable-http server on the modern protocol. What it reports:

pass

Every ttlMs is a non-negative number

fail

ttlMs must be a non-negative number — got

Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.

This rule is checked deterministically: a fail here is a certain violation, not an inference.

Checked in the same request as MCP-HDR-008, MCP-HDR-009, MCP-RES-003, MCP-RES-006, MCP-RES-007, MCP-ERR-003, MCP-ERR-004, MCP-ERR-005, MCP-ERR-008, MCP-CAC-001, MCP-CAC-002, MCP-CAC-003, MCP-CAC-005, MCP-SCH-001, MCP-SCH-002, MCP-SCH-003, MCP-SCH-004, MCP-SCH-005, MCP-SCH-006, MCP-SCH-007, MCP-SEC-004, MCP-SEC-005, MCP-SEC-006, MCP-DEP-005.

Check your own server against MCP-CAC-004

Probe P2.1 checks MCP-CAC-004 in the same request as 24 other rules, so one run shows your server's result for this rule next to the rest. Validate a server or read how the validator works.

Background on this topic: ttlMs and cacheScope explained.

Other Caching metadata rules

• MCP-CAC-001ttlMs present on all five cacheable results
• MCP-CAC-002cacheScope present on all five cacheable results
• MCP-CAC-003cacheScope is exactly "public" or "private"
• MCP-CAC-005Authenticated or personalised results are not marked cacheScope: public