tools/list returns a deterministic order

How to fix this

Return tools from `tools/list` in a deterministic order. A stable order is what lets clients cache the list and improves LLM prompt cache hit rates.

Example: failing and passing

POST /mcp HTTP/1.1
...

HTTP/1.1 200 OK
Content-Type: application/json

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

POST /mcp HTTP/1.1
...

HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc": "2.0", "id": 2, "result": {"resultType": "complete", "ttlMs": 300000, "cacheScope": "public",
  "tools": [{"name": "get_time", "description": "Get time", "inputSchema": {"type": "object"}}, {"name": "get_weather", "description": "Get weather", "inputSchema": {"type": "object"}}]}}

POST /mcp HTTP/1.1
...

HTTP/1.1 200 OK
Content-Type: application/json

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

POST /mcp HTTP/1.1
...

HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc": "2.0", "id": 2, "result": {"resultType": "complete", "ttlMs": 300000, "cacheScope": "public",
  "tools": [{"name": "get_weather", "description": "Get weather", "inputSchema": {"type": "object"}}, {"name": "get_time", "description": "Get time", "inputSchema": {"type": "object"}}]}}

How the validator checks this

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

pass

tools/list returned its … tools in the same order on two separate requests

warn

tools/list returned the same … tools in a different order on two requests (… / …). The spec says servers SHOULD keep a deterministic order.

skip

tools/list did not return a readable tools array on both samples, so ordering could not be compared

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-ERR-003, MCP-ERR-004, MCP-ERR-005, MCP-ERR-008, MCP-CAC-001, MCP-CAC-002, MCP-CAC-003, MCP-CAC-004, 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-RES-007

Probe P2.1 checks MCP-RES-007 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: the 2026-07-28 migration guide.

Other Result and message shape rules

• MCP-RES-001Every result includes resultType
• MCP-RES-002resultType is a value defined by core or an advertised extension
• MCP-RES-003Server sends no independent JSON-RPC requests on a response stream
• MCP-RES-004Accepted notification POST returns 202 with no body
• MCP-RES-005Response is application/json or text/event-stream; SSE terminates with the final response
• MCP-RES-006SSE responses set X-Accel-Buffering: no