The wire-schema validator introduced in #399 discriminates resultType === 'input_required' before falling back to the request method's result definition, but has no branch for resultType === 'task'. A well-formed SEP-2663 task envelope answering tools/call is therefore validated against CallToolResult and fails with must have required property 'content'.
The envelope shape cannot be present in the core spec schema, since tasks moved to an extension as of SEP-2663. So any SDK that implements the tasks extension and passes wire validation on everything else still fails these checks. In our runs (mcpkit) all 8 tasks scenarios fail exactly one check each (wire-schema-valid) for this reason but every other check in those scenarios passes.
Sample violation from tasks-lifecycle. here is the response that the validator rejected:
{
"origin": "implementation",
"specVersion": "2026-07-28",
"context": "response to 'tools/call'",
"errors": [
"CallToolResult: must have required property 'content' (result of 'tools/call')"
],
"message": {
"jsonrpc": "2.0",
"id": 2,
"result": {
"_meta": {
"io.modelcontextprotocol/serverInfo": {
"name": "tasks-v2-demo",
"version": "0.1.0"
}
},
"createdAt": "2026-07-29T20:36:13Z",
"lastUpdatedAt": "2026-07-29T20:36:13Z",
"pollIntervalMs": 1000,
"resultType": "task",
"status": "working",
"taskId": "task-42451aab21bbd828f4db0c0d",
"ttlMs": 300000
}
}
}
The result carries resultType: "task" and the SEP-2663 envelope fields. There is nothing for CallToolResult.content to match because it is not a CallToolResult.
Possible fixes, in rough order of preference:
- Treat an unrecognized
resultType value as an extension result and skip typed validation for it (fall back to the generic JSONRPCResultResponse envelope check), since resultType is exactly the discriminator the final revision added for this purpose.
- Vendor the tasks extension's envelope schema alongside the core schema and add a
task branch, if extension-aware validation is wanted.
Happy to contribute a PR for either direction if maintainers have a preference.
The wire-schema validator introduced in #399 discriminates
resultType === 'input_required'before falling back to the request method's result definition, but has no branch forresultType === 'task'. A well-formed SEP-2663 task envelope answeringtools/callis therefore validated againstCallToolResultand fails withmust have required property 'content'.The envelope shape cannot be present in the core spec schema, since tasks moved to an extension as of SEP-2663. So any SDK that implements the tasks extension and passes wire validation on everything else still fails these checks. In our runs (mcpkit) all 8 tasks scenarios fail exactly one check each (
wire-schema-valid) for this reason but every other check in those scenarios passes.Sample violation from
tasks-lifecycle. here is the response that the validator rejected:{ "origin": "implementation", "specVersion": "2026-07-28", "context": "response to 'tools/call'", "errors": [ "CallToolResult: must have required property 'content' (result of 'tools/call')" ], "message": { "jsonrpc": "2.0", "id": 2, "result": { "_meta": { "io.modelcontextprotocol/serverInfo": { "name": "tasks-v2-demo", "version": "0.1.0" } }, "createdAt": "2026-07-29T20:36:13Z", "lastUpdatedAt": "2026-07-29T20:36:13Z", "pollIntervalMs": 1000, "resultType": "task", "status": "working", "taskId": "task-42451aab21bbd828f4db0c0d", "ttlMs": 300000 } } }The result carries
resultType: "task"and the SEP-2663 envelope fields. There is nothing forCallToolResult.contentto match because it is not a CallToolResult.Possible fixes, in rough order of preference:
resultTypevalue as an extension result and skip typed validation for it (fall back to the genericJSONRPCResultResponseenvelope check), sinceresultTypeis exactly the discriminator the final revision added for this purpose.taskbranch, if extension-aware validation is wanted.Happy to contribute a PR for either direction if maintainers have a preference.