ext-tasks

Imports borrowed types from the core spec's schema to avoid unresolved types generating as the equivalent of . Motivation and Context Fixes #14. How Has This Been Tested? Breaking Changes Types of changes [x] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context AI Use Disclosure: Generated with Kiro Crew.

While implementing the server-side Task Store role for , I used for runtime validation. Two constraints described by the TypeScript source and normative prose are absent from the generated JSON Schema, and both matter to an implementation that is not written in TypeScript. This report uses commit : (blob ) and (blob ). 1. and collapse to “anything” declares: Those names come from . The current generation does not inline their definitions, so in both become: Expected: and contain structural constraints for their three permitted request or response families. Actual: each exact definition is . Because an empty JSON Schema accepts every instance, these definitions also accept a value such as . 2. appears nowhere in the generated schema The extension prose and the JSDoc in require to be , and require for , , and . Expected: requires with the constant , and the three task-operation results require . Actual: the string does not occur anywhere in , so none of the four definitions contains or requires the discriminator. The normative requirement is present in the extension prose and repeated in JSDoc, but the structural result aliases do not encode the literal discriminators. The generated schema contains no corresponding or constraint, so the requirement is not machine-checkable from that artifact. Reproduction The following script prints and asserts the exact generated structures described above. The conclusion that each empty branch accepts every instance follows directly from JSON Schema semantics: From a clone of that commit: The repository vendors both upstream files with their commit and blob provenance, so this remains a reproducible record of the schemas inspected even after upstream changes. Question Should generation inline the six imported request and result member types, or should a resolved bundle be published next to ? And should the structural result types encode the literal constraints so the generated artifact enforces the normative requirement? Together, those changes would make the generated artifact enforce the constraints described by the source and normative prose. Today, a runtime implementation has to maintain its own mirror of the SDK request/response shapes and result discriminators, which creates an avoidable drift risk.

The spec cites for "Missing Required Client Capability". The canonical code is . Evidence: appears in no core schema version (, , , ). It looks like this came in with the SEP-2663 port in 29f83d5 — the added lines already read , whereas SEP-2663 says . Supporting this, one of the affected examples carries the comment immediately above the value, and that constant is exactly in the TypeScript SDK. Docs-only: error codes aren't encoded in or the generated , so no regeneration is needed. I noticed this while implementing the tasks extension capability negotiation in the Go SDK (modelcontextprotocol/go-sdk#755), which already implements this error as . CONTRIBUTING notes that changes should go through the Agents Working Group first. I've opened this directly since it's a factual correction rather than a design change — happy to take it to the WG instead if you'd prefer.