2026-07-28 responses omit required `resultType` for most result types

[cclabadmin]

Describe the bug

When the Go SDK server handles requests declaring the 2026-07-28 protocol version, only three tested result types (CallToolResult, GetPromptResult, and ReadResourceResult) include the resultType field in their JSON responses. Other tested result types — including DiscoverResult, ListToolsResult, ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, and CompleteResult — omit resultType entirely.

The 2026-07-28 draft schema defines resultType as a required field on the base Result type:

"Result": {
    "required": ["resultType"],
    "properties": {
        "resultType": {
            "description": "... Servers implementing this protocol version MUST include this field. ..."
        }
    }
}

The same required constraint appears on the result schemas I checked in the generated schema.json, including Result, CacheableResult, CallToolResult, CompleteResult, DiscoverResult, GetPromptResult, InputRequiredResult, ListPromptsResult, ListResourceTemplatesResult, ListResourcesResult, ListToolsResult, PaginatedResult, ReadResourceResult, and SubscriptionsListenResult.

This appears to be a 2026-07-28 schema-compliance issue. The resultType field appears to be set only for the multi-round-trip (MRTR) result path, while the schema requires it on result objects generally.

Environment tested:

• main snapshot from 2026-06-28: 65ece5964304528e7568507e2b17351824ef73fc
• Server used: conformance/everything-server
• Transports: stdio and Streamable HTTP (stateless)

To Reproduce

Steps to reproduce the behavior:

1. Start the Go SDK server with 2026-07-28 support enabled.
2. Send a server/discover request with _meta.io.modelcontextprotocol/protocolVersion: "2026-07-28".
3. Observe that the response does not contain resultType.
4. Repeat with tools/list, prompts/list, resources/list, completion/complete.
5. Observe that none of these responses contain resultType.
6. Send a tools/call request for a known tool.
7. Observe that this response does contain "resultType": "complete".

Example request:

{
  "jsonrpc": "2.0",
  "id": 1001,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "repro", "version": "0.1.0"},
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Expected behavior

All result objects in 2026-07-28 responses should include "resultType": "complete" (or "input_required" when applicable). The schema required constraint and the spec text "Servers implementing this protocol version MUST include this field" apply to every result type, not only the three MRTR-capable types.

Observed behavior

Across both stdio and Streamable HTTP, the following pattern was observed:

Method	resultType present?
server/discover	No
tools/list	No
prompts/list	No
resources/list	No
resources/templates/list	No
completion/complete	No
tools/call	Yes ("complete")
prompts/get	Yes ("complete")
resources/read	Yes ("complete")

The three methods that do include resultType are the three MRTR-capable types: CallToolResult, GetPromptResult, ReadResourceResult. This is consistent with resultType being set only from handleMultiRoundTripResult in mcp/mrtr.go.

Additional context

• As a possible reference point, the Python SDK appears to include "resultType": "complete" at the model layer, where concrete Result subclasses declare result_type: ResultType = "complete" as a field default. That avoids relying on individual handlers or dispatch paths to add the field.
• In the Go SDK, resultType appears to be set only via handleMultiRoundTripResult (mcp/mrtr.go), which is invoked for the methods that go through the MRTR middleware. Other result types in mcp/protocol.go do not appear to have a resultType field.

[yarolegovich]

Thanks for reporting. Should be fixed, but I'd put it as a low severity because per the SEP:

If this field is not provided, the Client should assume a ResultType of "complete" for backwards compatibility.