Make spec type tests catch .optional() missing args too #1298

Activity

1. felixweinberger

   added

   enhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supported

   ready for workEnough information for someone to start working onEnough information for someone to start working on

   P2Moderate issues affecting some users, edge cases, potentially valuable featureModerate issues affecting some users, edge cases, potentially valuable feature

   on Dec 15, 2025
2. rechedev9

   added a commit that references this issue on Mar 9, 2026

   test: add compile-time key-parity assertions for spec type checks

   ...

   This issue will close once commit ff429d5 is merged into the 'main' branch.

   ff429d5
3. rechedev9 commented on Mar 9, 2026

   

   rechedev9

   on Mar 9, 2026

   Contributor

   More actions

   I've implemented a solution for this in PR #1652.

   Approach

   Added 151 compile-time key-parity assertions using three utility types:

   • KnownKeys<T> — strips index signatures, keeping only named keys
   • AssertExactKeys<A, B> — resolves to true when key sets match; produces a descriptive error type on mismatch
   • Assert<T extends true> — forces a compile error on mismatch

   Every sdkTypeChecks entry now has a corresponding assertion that fails at pnpm typecheck time if the SDK type has extra or missing keys relative to the spec.

   Coverage: 151 of 174 entries. 23 excluded with documentation (15 union types where key enumeration isn't meaningful, 8 primitive aliases).

   Discovered mismatches

   The new assertions immediately caught 7 genuine SDK/spec key differences:

   SDK Type	Issue
   PromptReference	Missing title from spec
   Resource	Missing size from spec
   PromptArgument	Missing title from spec
   ResourceLink	Missing size from spec
   ClientCapabilities	Missing extensions from spec
   ServerCapabilities	Missing extensions from spec
   RequestMetaObject	Extra io.modelcontextprotocol/related-task not in spec

   These are documented with @ts-expect-error — when the SDK catches up, the directive itself errors, prompting removal.

   Zero runtime overhead. Single file changed.
4. felixweinberger

   closed this as completedin #1652on Mar 30, 2026