MCP server: `tools/list` and `prompts/list` omit `resultType`, so 2026-07-28 clients get zero tools

[atej]

The MCP endpoint at https://mcp.specification.website/mcp connects fine but
serves no tools to any client that negotiates protocol revision 2026-07-28.
Claude Code has dropped all 6 tools and the audit_url prompt since roughly
2026-08-17 14:00 UTC.

The failure is quiet. initialize succeeds, so the client accepts the server
and loads its instructions — the server looks healthy in the client's server
list while exposing nothing.

What the client reports

tools/list failed (Invalid result for tools/list: missing required resultType —
servers implementing protocol revision 2026-07-28 MUST include it (the
absent-means-complete bridge applies only to earlier-revision servers));
retrying in 250ms
...
Failed to fetch tools: Invalid result for tools/list: missing required resultType
Failed to fetch commands: Invalid result for prompts/list: missing required resultType

Four retries with backoff, then both lists are discarded.

Reproduction

1. List results carry no resultType

curl -s -X POST https://mcp.specification.website/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | jq '.result | keys'

Actual:

["tools"]

Expected for revision 2026-07-28: a resultType member alongside tools.
prompts/list behaves the same way (["prompts"]).

2. initialize downgrades a 2026-07-28 request

curl -s -X POST https://mcp.specification.website/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
        "protocolVersion":"2026-07-28","capabilities":{},
        "clientInfo":{"name":"probe","version":"0.0.1"}}}' \
  | jq -r '.result.protocolVersion'

Actual: 2025-11-25
Expected: 2026-07-28

https://specification.website/mcp/ states the server speaks the 2026-07-28
revision, with 2025-11-25, 2025-06-18 and 2025-03-26 kept as deprecated
fallbacks. The initialize path does not appear to know the current revision at
all.

3. No handshake-less path either

The endpoint's CORS preflight advertises Mcp-Method and Mcp-Name in
Access-Control-Allow-Headers, which suggests the handshake-less mode the spec
page describes for 2026-07-28. It is not implemented:

curl -s -X POST https://mcp.specification.website/mcp \
  -H 'Content-Type: application/json' \
  -H 'Mcp-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' -d '{}'
# {"jsonrpc":"2.0","id":null,"error":{"code":-32601,"message":"Method not found: undefined"}}

A GET returns 405 with MCP endpoint requires POST with a JSON-RPC body.

So a 2026-07-28 client has no working route to the tool list.

Scope

Every list-shaped result the worker returns needs resultType when the
negotiated revision is 2026-07-28 — tools/list and prompts/list at minimum.
The tool schemas themselves are fine: all 6 tools carry valid inputSchema,
outputSchema, title and annotations.

Environment

• Endpoint: https://mcp.specification.website/mcp
• serverInfo: specification-website 0.2.0
• Client: Claude Code 2.1.237, Node 26.3.0, macOS
• First observed: between 2026-08-17 13:25 and 14:23 UTC. 101 consecutive
  sessions since, all failing identically. Earlier sessions on the same client
  version connected and listed tools normally.
• All three reproductions re-confirmed 2026-08-24.

[hsw]

Thanks for chasing this down. Your fourth point is the real bug, and #192 fixes it. The other three would send someone at the wrong part of the Worker, so they are worth untangling.

The bug is bigger than the report. resultType is required on the base Result type in 2026-07-28, which every concrete result inherits — so it is not just the list results. In the modern era the Worker is non-conforming on tools/list, prompts/list, tools/call and prompts/get alike. server/discover is the only exception, because that branch was written to the modern shape by hand.

There is a second half you did not hit: ListToolsResult and ListPromptsResult also require ttlMs and cacheScope (caching: "Servers MUST include caching hints on results with resultType: "complete" returned by the following operations: server/discover, tools/list, prompts/list, …"). The conformance suite reports all three at once:

[wire-schema-valid] FAILURE ListToolsResult: must have required property 'cacheScope';
                            must have required property 'resultType';
                            must have required property 'ttlMs'

That is why you see zero tools while initialize succeeds. The server looks healthy, then the client correctly rejects every result.

The three that are not bugs:

1. tools/list with only the protocol header omits resultType. Correct behaviour. The Worker picks its era from the body, not the header: a request carrying params._meta["io.modelcontextprotocol/protocolVersion"] is modern, anything else is legacy. resultType does not exist in 2025-11-25, so emitting it there would be the bug. Add the _meta key and you will reproduce the real failure.

2. initialize should return 2026-07-28. It must not. That revision removed the handshake — there is no InitializeResult in the schema at all. Sending initialize says the client speaks a handshake revision, so only a legacy version can come back — basic/versioning spells this out for a dual-era server: "An initialize request selects legacy semantics."

3. The handshake-less mode is not implemented. It is. server/discover and per-request negotiation both work. The Method not found: undefined comes from the repro sending -d '{}' — a body with no method member, which is exactly what the server reports.

One more thing that fell out while fixing it: ping and logging/setLevel were also removed in 2026-07-28, and the Worker was still answering both. Stamping them with resultType would have reported success for methods the era does not define, so they now return -32601 in the modern era and are unchanged in the legacy one.

The PR fixes it at the era boundary, so legacy responses stay byte-identical, and adds the Worker's first tests to keep it that way.