chore: update spec.types.ts from upstream

[github-actions]

This PR updates packages/core/src/types/spec.types.ts from the Model Context Protocol specification.

Source file: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/8e192a2277251483768fb254fee4fc3b8da3944f/schema/draft/schema.ts

This is an automated update triggered by the nightly cron job.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0bcec2b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[claude]

🔴 The spec has restructured sampling/elicitation/roots out of the JSON-RPC request/response model: CreateMessageRequest/ElicitRequest/ListRootsRequest no longer extend JSONRPCRequest, their results no longer extend Result, the *ResultResponse wrappers are deleted, and all six are dropped from ServerRequest/ClientResult — they are now payloads embedded inside the new InputRequiredResult flow. The SDK still models these as standalone server→client wire requests (ServerRequestSchema/ClientResultSchema in schemas.ts:2107-2123, plus the server.createMessage()/elicitInput()/listRoots() APIs), so beyond the immediate spec.types.test.ts compile failures (lines 156/160/168/172/225/301/476/499 and hard references to the deleted SpecTypes.*ResultResponse types at 745-763 & 1019-1024), this sync leaves the SDK architecturally divergent from the protocol. Unlike the new-type additions, this isn't a mechanical "add schemas" fix — it requires redesigning the SDK's server-initiated-request APIs around InputRequiredResult/inputResponses, so this PR should be held until that companion work is ready.

Extended reasoning...

What changed

The upstream spec has fundamentally changed how a server obtains sampling, elicitation, and roots from the client. Previously these were ordinary server→client JSON-RPC requests: CreateMessageRequest, ElicitRequest, and ListRootsRequest each extended JSONRPCRequest, their results extended Result, each had a *ResultResponse envelope, and they were members of the ServerRequest / ClientResult unions. In this diff:

• CreateMessageRequest / ElicitRequest / ListRootsRequest drop extends JSONRPCRequest (and their *Params drop TaskAugmentedRequestParams/RequestParams).
• CreateMessageResult / ElicitResult / ListRootsResult drop extends Result.
• CreateMessageResultResponse, ElicitResultResponse, ListRootsResultResponse are deleted.
• All six are removed from the ServerRequest and ClientResult unions (lines 3284-3291).
• They are now referenced only via the new InputRequest / InputResponse aliases, which are carried inside InputRequiredResult.inputRequests and echoed back via InputResponseRequestParams.inputResponses (or tasks/input_response).

In other words, the spec no longer models "server asks client for sampling" as a standalone JSON-RPC request — it is now an embedded sub-request inside a resultType: 'input_required' result that the client must fulfill and replay on the next call.

Immediate breakage in this PR

packages/core/test/spec.types.test.ts fails to compile in two distinct ways:

1. Bidirectional assignability checks at lines 155-172, 223-225, 301, 476, 499 fail because the spec types no longer carry jsonrpc/id (requests) or the Result index signature (results), and the ServerRequest/ClientResult unions no longer line up with the SDK's.
2. Hard references to deleted types: lines 745-763 and 1019-1024 reference SpecTypes.CreateMessageResultResponse, SpecTypes.ListRootsResultResponse, and SpecTypes.ElicitResultResponse, which no longer exist — these are unconditional TS2694/TS2339-class errors, not just assignability mismatches.

So the package will not build / CI will be red on merge.

Architectural divergence (why this isn't just a test fix)

The SDK runtime does not import spec.types.ts (only the test does), so src/ still typechecks — but that is precisely the problem the drift guard exists to surface. schemas.ts:2107 (ClientResultSchema) and schemas.ts:2119 (ServerRequestSchema) still include CreateMessageRequestSchema / ElicitRequestSchema / ListRootsRequestSchema and their results, and the public SDK surface (server.createMessage(), ctx.elicitInput(), roots listing) still issues these as wire-level JSON-RPC requests. After this sync, an SDK server speaking to a spec-compliant client would send a sampling/createMessage JSON-RPC request that the client is no longer obligated to handle as a top-level request; conversely, the SDK has no machinery to emit InputRequiredResult from a tool/prompt/resource handler or to accept inputResponses on the retry.

Step-by-step proof

1. Before: spec.types.ts had interface CreateMessageRequest extends JSONRPCRequest { method: 'sampling/createMessage'; ... } and ServerRequest = PingRequest | CreateMessageRequest | ListRootsRequest | ElicitRequest | ....
2. After (this diff, ~line 2311): interface CreateMessageRequest { method: 'sampling/createMessage'; params: ... } — no jsonrpc, no id. ServerRequest (line 3291) is now PingRequest | GetTaskRequest | GetTaskPayloadRequest | ListTasksRequest | CancelTaskRequest only.
3. spec.types.test.ts:476 does (sdk: WithJSONRPCRequest<SDKTypes.CreateMessageRequest>, spec: SpecTypes.CreateMessageRequest) => { sdk = spec; }. spec has no jsonrpc/id, so sdk = spec fails: Type 'CreateMessageRequest' is missing the following properties: jsonrpc, id.
4. spec.types.test.ts:756 does spec: SpecTypes.ListRootsResultResponse — that export no longer exists → Namespace has no exported member 'ListRootsResultResponse'.
5. Meanwhile schemas.ts:2119-2123 still builds ServerRequestSchema from CreateMessageRequestSchema | ElicitRequestSchema | ListRootsRequestSchema | ..., so SDKTypes.ServerRequest ⊋ SpecTypes.ServerRequest and the union check at ~499 fails too.

Why this is distinct from the "new types need schemas" comment

A separate comment notes that ResultType, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest, etc. need new Zod schemas and specTypeSchema allowlist entries. That is additive, mechanical work. This finding is about the removal/restructuring of existing types and unions, whose remediation is not mechanical: you cannot simply add a schema — you have to (a) decide whether the SDK keeps server.createMessage()/elicitInput()/listRoots() as a compatibility shim or replaces them with an InputRequiredResult-returning API, (b) remove these from ServerRequestSchema/ClientResultSchema, and (c) rewrite the bidirectional test entries (drop the WithJSONRPCRequest<...> wrapper for these three, delete the *ResultResponse checks). The refutation that this is "the same finding" conflates detection mechanism (both trip spec.types.test.ts) with root cause and fix; reviewers need to see this called out separately because it is the part that requires API design, not a 10-line schema patch.

Recommended action

Hold this automated sync until a companion PR implements the InputRequiredResult flow in the SDK (new result/param schemas, updated ServerRequestSchema/ClientResultSchema, reworked createMessage/elicitInput/listRoots plumbing, and updated spec.types.test.ts entries for these six types plus removal of the three deleted *ResultResponse checks). Merging this alone breaks the build and publishes a spec snapshot the SDK cannot honor.

[claude]

🔴 This spec sync adds 10 new Multi Round-Trip types (ResultType, InputRequest/InputResponse/InputRequests/InputResponses, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest/TaskInputResponseRequestParams/TaskInputResponseResultResponse) and adds tasks/input_response to ClientRequest, but none of these have corresponding entries in schemas.ts, types.ts, or the sdkTypeChecks map — so spec.types.test.ts fails on the hardcoded type count (176 vs 182), the "comprehensive compatibility tests" coverage check, and the ClientRequest bidirectional assignability check. This automated cron PR needs companion SDK schema/type/test updates before it can land.

Extended reasoning...

What the bug is

This PR is the nightly automated sync of spec.types.ts from upstream. The upstream commit it pulls in introduces the new Multi Round-Trip machinery: ResultType, InputRequest, InputResponse, InputRequests, InputResponses, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest, TaskInputResponseRequestParams, and TaskInputResponseResultResponse, plus a new tasks/input_response member of the ClientRequest union. None of these names appear anywhere else in packages/core/src — schemas.ts has no Zod schemas for them, types.ts has no SDK-side type aliases, and test/spec.types.test.ts has no sdkTypeChecks entries for them. The repo's spec↔SDK drift guard catches exactly this situation and fails the build.

Code path that triggers it

packages/core/test/spec.types.test.ts enforces three invariants that all break:

1. Type count — line ~1089 hardcodes expect(specTypes).toHaveLength(176). After this sync the file exports 182 types (10 added, 4 removed: URLElicitationRequiredError, CreateMessageResultResponse, ListRootsResultResponse, ElicitResultResponse), so this assertion fails.
2. Coverage check — the should have comprehensive compatibility tests test (lines ~1098-1108) parses every exported name from spec.types.ts, skips the MISSING_SDK_TYPES allowlist (currently only ['Error', 'URLElicitationRequiredError']), and asserts each remaining name has an entry in sdkTypeChecks. The 10 new types have no entry, so 10 assertions fail. Additionally, URLElicitationRequiredError was removed from the spec but is still in MISSING_SDK_TYPES, which will fail the "Missing SDK Types" suite that asserts every allowlisted name actually exists in the spec file.
3. ClientRequest bidirectional check — tsc shows the assignability check at ~line 496 failing because the spec ClientRequest union now contains TaskInputResponseRequest while the SDK ClientRequest union does not.

Why existing code doesn't prevent it

That's by design — spec.types.test.ts is the guard that turns an automated spec pull into a forcing function for SDK updates. The cron job only updates spec.types.ts; it does not (and cannot) generate the matching Zod schemas, SDK type aliases, or sdkTypeChecks entries. Note: the specTypeSchemas allowlist drift guard from #1993 (specTypeSchema.test.ts:162) does not trip here — that guard compares schemas.ts exports against the SPEC_SCHEMA_KEYS allowlist, not against spec.types.ts. The guard that trips is the runtime coverage check in spec.types.test.ts.

Step-by-step proof

Running cd packages/core && pnpm vitest run test/spec.types.test.ts on this branch:

• should define some expected types → FAIL: expected 182 to be 176
• should have comprehensive compatibility tests → FAIL: ResultType, InputRequest, InputResponse, InputRequests, InputResponses, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest, TaskInputResponseRequestParams, TaskInputResponseResultResponse each produce expected undefined to be defined

And tsc --noEmit on packages/core fails because spec.types.test.ts still references the now-removed CreateMessageResultResponse / ListRootsResultResponse / ElicitResultResponse / URLElicitationRequiredError (lines ~745-760, ~1019-1024, ~1069), and because spec.ClientRequest is no longer assignable to sdk.ClientRequest once TaskInputResponseRequest is in the union.

Impact

CI is red on this PR. Merging it as-is would break main. Beyond the test failures, downstream consumers using isSpecType / specTypeSchemas (#1887) would have no runtime validators for any of the new Multi Round-Trip messages, and the SDK ClientRequest union would be out of sync with the wire protocol.

How to fix

This needs a companion commit on top of the cron sync:

• Add Zod schemas for ResultType, InputRequests, InputResponses, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest, TaskInputResponseRequestParams, TaskInputResponseResultResponse (and InputRequest/InputResponse aliases) in schemas.ts, and register them in specTypeSchemas.
• Add the corresponding SDK types in types.ts and add TaskInputResponseRequest to the SDK ClientRequest union.
• In spec.types.test.ts: bump the toHaveLength(176) count, add sdkTypeChecks entries for all 10 new types, remove the entries/references for CreateMessageResultResponse / ListRootsResultResponse / ElicitResultResponse / URLElicitationRequiredError, and drop URLElicitationRequiredError from MISSING_SDK_TYPES.

(This is separate from the resultType required-field assignability breakage tracked elsewhere — even if resultType is made optional upstream, every failure listed here still occurs.)

[claude]

🔴 The new resultType: ResultType field on the base Result interface is declared as required even though the JSDoc says @default "complete" — this makes every Result subtype (InitializeResult, CallToolResult, ReadResourceResult, GetPromptResult, EmptyResult, all the Paginated/Task results, etc.) require resultType. The SDK's ResultSchema in schemas.ts does not produce this field, so tsc --noEmit on @modelcontextprotocol/core now fails with 30+ TS2741 errors in spec.types.test.ts and CI will not pass. Given the @default annotation, the upstream spec almost certainly intended resultType?: ResultType; either the upstream schema.ts needs to be fixed before this is re-pulled, or this PR needs an accompanying SDK-side ResultSchema change before it can land.

Extended reasoning...

What the bug is

This automated spec sync adds a new field to the base Result interface in packages/core/src/types/spec.types.ts:

export interface Result {
    _meta?: MetaObject;
    /**
     * Indicates the type of the result, which allows the client to determine
     * how to parse the result object.
     *
     * @default "complete"
     */
    resultType: ResultType;
    [key: string]: unknown;
}

The field is declared without a ?, making it required on Result and on every interface that extends Result. The @default "complete" JSDoc strongly implies the spec author intended it to be optional and defaulted server-side, but the TypeScript declaration does not reflect that.

How it manifests / proof

The SDK maintains bidirectional-assignability checks between the spec types and the SDK's Zod-inferred types in packages/core/test/spec.types.test.ts (e.g. Result: (sdk, spec) => { sdk = spec; spec = sdk; }). The SDK's ResultSchema is defined in packages/core/src/types/schemas.ts:111 as:

export const ResultSchema = z.looseObject({
    _meta: ...
});

It has no resultType field, and a grep for resultType under packages/core/src finds it only in spec.types.ts — no SDK schema, handler, or result-construction site sets it.

Running pnpm tsc --noEmit -p packages/core/tsconfig.json on this branch produces 30+ errors of the form:

test/spec.types.test.ts: error TS2741: Property 'resultType' is missing in type
'{ _meta?: ...; }' but required in type 'Result'.

repeated for Result, EmptyResult, PaginatedResult, CompleteResult, ListToolsResult, CallToolResult, ListResourcesResult, ListResourceTemplatesResult, ReadResourceResult, ListPromptsResult, GetPromptResult, InitializeResult, CreateTaskResult, GetTaskResult, ListTasksResult, CancelTaskResult, GetTaskPayloadResult, JSONRPCResultResponse, JSONRPCMessage, ServerResult, ClientResult, and more.

Step-by-step

1. spec.types.ts now says Result requires resultType: 'complete' | 'input_required'.
2. schemas.ts infers the SDK Result type from ResultSchema = z.looseObject({ _meta: ... }), which has no resultType key.
3. spec.types.test.ts does spec = sdk; for Result and every derived result type.
4. TypeScript rejects the assignment because { _meta?: ... } lacks the required resultType property → TS2741.
5. The same failure cascades to every extends Result interface and to JSONRPCResultResponse (whose result: Result field inherits the requirement).

Why existing code doesn't prevent it

Result has an index signature [key: string]: unknown, but index signatures do not satisfy explicitly-declared required properties — TypeScript still demands resultType be present by name. Nothing in this PR touches schemas.ts or any handler to add the field on the SDK side.

Impact

• CI typecheck fails, so this PR cannot merge as-is.
• Even if the typecheck were bypassed, every SDK consumer constructing a result literal (e.g. return { content: [...] } from a tool handler) would no longer satisfy Spec.CallToolResult, and downstream consumers typing against the spec types would see the same breakage.

How to fix

The cleanest fix is upstream: change the spec's schema.ts to resultType?: ResultType; (matching the @default "complete" semantics) and re-run pnpm run fetch:spec-types. If the spec genuinely intends the field to be required on the wire, then this PR must be accompanied by an SDK change that adds resultType: z.enum(['complete', 'input_required']).default('complete') (or equivalent) to ResultSchema and updates all result-construction sites — but that is a much larger, non-mechanical change that should not land in an automated nightly sync.

[claude]

🔴 TaskInputResponseRequestParams carries only inputResponses — it has no taskId (and no requestState, since it extends bare RequestParams rather than InputResponseRequestParams), unlike every other tasks/* method (tasks/get, tasks/result, tasks/cancel), which all take { taskId: string }. A server with more than one task in input_required status has no spec-defined way to route the responses to the correct task. This is the same class of upstream schema.ts defect as the resultType-required finding — it should be fixed upstream (add taskId: string) and re-pulled before the SDK encodes this shape into a Zod schema.

Extended reasoning...

What the bug is

The new tasks/input_response request's params type is:

export interface TaskInputResponseRequestParams extends RequestParams {
    inputResponses: InputResponses;
}

RequestParams (spec.types.ts:112) contains only _meta?: RequestMetaObject, so the only data this request carries on the wire is { inputResponses, _meta? }. There is no taskId, and because it extends bare RequestParams rather than InputResponseRequestParams, there is also no requestState — so neither of the two routing mechanisms available elsewhere in the Multi Round-Trip flow is present here.

Why this is inconsistent with the rest of tasks/*

Every other task-targeting method in the spec identifies the task explicitly:

method	params	line
tasks/get	{ taskId: string }	spec.types.ts:1957
tasks/result	{ taskId: string }	spec.types.ts:1992
tasks/cancel	{ taskId: string }	spec.types.ts:2078
tasks/input_response	{ inputResponses } — no taskId	spec.types.ts:2050

The InputRequests JSDoc says only that keys are "server-assigned identifiers"; it does not require them to be globally unique across tasks. Relying on the server to embed task identity in those keys would be an undocumented implicit contract that contradicts the explicit-taskId convention used by every sibling method.

Step-by-step proof

1. Client creates two tasks; both reach status: 'input_required'.
2. Client calls tasks/result with { taskId: 'task-A' } → server returns InputRequiredResult { inputRequests: { 'req-1': <ElicitRequest> } }.
3. Client calls tasks/result with { taskId: 'task-B' } → server returns InputRequiredResult { inputRequests: { 'req-1': <ElicitRequest> } } (nothing in the spec forbids reusing 'req-1' per-task).
4. Client now sends tasks/input_response with params: { inputResponses: { 'req-1': <ElicitResult> } }.
5. The server receives { inputResponses: { 'req-1': … } } and has no field telling it whether this fulfills task-A or task-B. InputRequiredResult itself carries no taskId, and TaskInputResponseRequestParams carries no taskId and no requestState. The request is unroutable by spec.

Why existing code doesn't prevent it

The synchronous path is fine: CallToolRequestParams / GetPromptRequestParams / ReadResourceRequestParams now extend InputResponseRequestParams, which carries requestState — the server can stash routing info there. But TaskInputResponseRequestParams extends RequestParams, not InputResponseRequestParams, so it gets neither requestState nor a taskId. And the SDK's task plumbing (packages/core/src/shared/taskManager.ts) keys everything by taskId, so when the companion work from comment #2 adds a tasks/input_response handler, it will have nothing to look up.

Impact

This doesn't independently break CI (unlike resultType-required), but it blocks correct implementation of the companion SDK work this PR demands. If the SDK adds TaskInputResponseRequestSchema matching this shape, it bakes an unroutable request into the public surface and will need a breaking change once upstream adds taskId.

How to fix

Same remediation path as the resultType-required finding: file upstream against modelcontextprotocol/schema/draft/schema.ts to add taskId: string to TaskInputResponseRequestParams (and likely requestState?: string, or have it extend InputResponseRequestParams), then re-run pnpm run fetch:spec-types. Don't add a Zod schema for this type in its current shape.

[claude]

🟡 Nit (upstream): the field/interface comments here use plain /* ... */ instead of /** ... */ JSDoc, so the TS language service / TypeDoc will not surface them — and InputResponseRequestParams ends up with no doc comment and no @category Multi Round-Trip tag at all, unlike every sibling type in this section. Since spec.types.ts is not re-exported from this package the SDK's own docs are unaffected, but it's worth folding into the same upstream schema.ts fix as the resultType issue so the spec repo's generated docs and the forthcoming hand-written schemas.ts mirror get proper descriptions.

Extended reasoning...

What the issue is

In the new Multi Round-Trip block, several comments use plain block-comment syntax /* ... */ instead of JSDoc syntax /** ... */:

• InputRequiredResult.inputRequests (lines 394-396)
• InputRequiredResult.requestState (lines 398-402)
• the interface-level comment on InputResponseRequestParams (lines 406-408)
• InputResponseRequestParams.inputResponses (lines 410-413)
• InputResponseRequestParams.requestState (lines 415-416)

Because the opening delimiter is /* (single asterisk) rather than /**, TypeScript's language service and TypeDoc treat these as ordinary comments, not documentation. Additionally, since InputResponseRequestParams has no /** */ block at all, it also has no @category Multi Round-Trip tag — every other exported type in this section (InputRequests, InputResponses, InputRequiredResult, TaskInputResponseRequest, etc.) carries that tag.

Why this is an upstream slip, not intentional

This is not the file's convention. Every surrounding declaration in the same diff hunk uses proper /** ... */ JSDoc: ResultType (148-156), InputRequests (354-362), InputResponses (366-375), InputRequiredResult itself (380-392), TaskInputResponseRequest (2031-2039), TaskInputResponseRequestParams (2046-2056). The pre-existing /* Empty result */ and /* Cancellation */ lines are one-line section dividers, not API documentation, so they are not precedent for multi-line field descriptions. The five blocks above are the only multi-line API descriptions in the file using /* — a clear authoring inconsistency in the upstream commit.

Addressing the "not SDK-public" objection

It is true that spec.types.ts is not part of this SDK's public surface — packages/core/src/types/index.ts re-exports constants/enums/errors/guards/schemas/specTypeSchema/types but not spec.types, and the only importer in the package is test/spec.types.test.ts. So this has zero effect on the typescript-sdk's generated docs or consumer .d.ts, and CLAUDE.md's "JSDoc for public APIs" rule does not directly apply to this file in this repo.

The reason it is still worth a (nit-level) mention is that this file is a verbatim mirror of the spec repo's schema/draft/schema.ts, which is the source for the protocol's own TypeDoc site. In the upstream output, InputResponseRequestParams will render with no description and will be uncategorised (it will not appear under the "Multi Round-Trip" group), and the normative "client must treat this as an opaque blob" guidance on requestState will be invisible in IDE hover for anyone consuming the spec types. The fix lives in the same upstream file that already needs editing for the resultType? optionality issue flagged elsewhere on this PR, so the marginal cost of including it in that upstream report is near zero.

Step-by-step proof

1. Hover InputResponseRequestParams at line 409 in VS Code → tooltip shows only interface InputResponseRequestParams extends RequestParams with no description, because lines 406-408 start with /* not /**.
2. Hover InputRequiredResult at line 393 → tooltip shows the full "An InputRequiredResult sent by the server…" text, because lines 380-392 start with /**.
3. Hover requestState at line 403 → no description; the "client must treat this as an opaque blob" note (398-402) is dropped.
4. Run TypeDoc over upstream schema.ts → InputRequests, InputResponses, InputRequiredResult are grouped under Multi Round-Trip; InputResponseRequestParams is not (no @category tag, because there is no JSDoc block to carry one).

How to fix

In upstream schema.ts, change /* → /** on the five blocks listed above and add @category Multi Round-Trip to the InputResponseRequestParams doc comment, then re-run pnpm run fetch:spec-types. No change is appropriate in this repo directly (the file header says DO NOT EDIT). This is purely documentation rendering — it does not affect type-checking, the drift guard, or runtime behaviour — hence nit, raised only because an upstream schema.ts fix is already on the table for this sync.

[claude]

🟡 Upstream design gap worth flagging alongside the other schema.ts feedback: InputRequiredResult extends Result without redeclaring resultType: 'input_required', and none of the "complete" subtypes (CallToolResult/ReadResourceResult/GetPromptResult/GetTaskPayloadResult) narrow to resultType: 'complete' either — so the new result: CallToolResult | InputRequiredResult unions (lines 1122/1455/1650/2028) are not TypeScript discriminated unions and if (r.resultType === 'input_required') will not narrow. This is orthogonal to the "resultType is required" comment above (fixing one doesn't fix the other) and constrains the SDK from modeling these with z.discriminatedUnion('resultType', ...) while keeping the bidirectional spec↔SDK assignability check green.

Extended reasoning...

What the bug is

The spec introduces ResultType = 'complete' | 'input_required' and adds resultType: ResultType to the base Result interface (line 165), with the JSDoc explicitly stating its purpose is to "allow the client to determine how to parse the result object." It then defines InputRequiredResult extends Result (line 393) and unions it into four response envelopes — CallToolResultResponse.result: CallToolResult | InputRequiredResult (1650), and likewise for ReadResourceResultResponse (1122), GetPromptResultResponse (1455), and GetTaskPayloadResultResponse (2028).

However, InputRequiredResult does not redeclare resultType: 'input_required', and none of CallToolResult / ReadResourceResult / GetPromptResult / GetTaskPayloadResult redeclare resultType: 'complete'. A grep confirms resultType appears exactly once in spec.types.ts — only on the base Result. So every arm of every X | InputRequiredResult union has resultType typed as the full 'complete' | 'input_required', and TypeScript's discriminated-union narrowing does not engage.

Step-by-step proof

1. Result.resultType: 'complete' | 'input_required' (line 165).
2. InputRequiredResult extends Result { inputRequests?: ...; requestState?: ... } (line 393) — inherits resultType: 'complete' | 'input_required' unchanged.
3. CallToolResult extends Result { content: ...; ... } — also inherits resultType: 'complete' | 'input_required' unchanged.
4. Given declare const r: CallToolResult | InputRequiredResult:

   if (r.resultType === 'input_required') {
     r.inputRequests; // ❌ TS error: Property 'inputRequests' does not exist on type 'CallToolResult | InputRequiredResult'
   }

   TypeScript cannot eliminate CallToolResult from the union because CallToolResult['resultType'] also includes 'input_required'. Narrowing requires the discriminant property to have disjoint literal types across union members.
5. Additionally, since Result carries [key: string]: unknown and InputRequiredResult's only additions (inputRequests?, requestState?) are optional, InputRequiredResult is structurally a subtype of CallToolResult — the union is effectively degenerate at the type level.

Why this is distinct from the existing "resultType is required" comment

The comment on line 165 is about resultType being declared required despite @default "complete", which breaks SDK→spec assignability for every result. This finding is about resultType not being narrowed on subtypes, which breaks discriminated-union narrowing within the spec types themselves. They are orthogonal: making resultType optional on Result does not give InputRequiredResult a narrowed discriminant, and adding resultType: 'input_required' to InputRequiredResult does not make the base field optional. Both should be raised upstream together.

Impact on the SDK

The companion schemas.ts work (already requested in another comment on this PR) will need to define InputRequiredResultSchema and the four result: X | InputRequiredResult unions. The natural Zod encoding is z.discriminatedUnion('resultType', [...]), which requires each arm to declare a z.literal(...) discriminant. But if the SDK narrows InputRequiredResultSchema to resultType: z.literal('input_required'), the spec→SDK direction of the bidirectional assignability check in spec.types.test.ts fails: the spec's InputRequiredResult['resultType'] is 'complete' | 'input_required', which is not assignable to the SDK's 'input_required'. So the SDK is forced to either (a) use a non-discriminated z.union and lose narrowing, or (b) narrow anyway and add a carve-out in the bidirectional test — neither is great, and both go away if upstream narrows the discriminant.

At runtime the wire-level discriminator still works (a client can string-compare resultType and cast), so this is a type-ergonomics / SDK-modeling defect rather than a protocol-correctness one.

How to fix

Upstream in schema.ts: add resultType: 'input_required'; to InputRequiredResult, and add resultType?: 'complete'; (or required 'complete', depending on how the optionality question is resolved) to each concrete "complete" result that participates in an | InputRequiredResult union — at minimum CallToolResult, ReadResourceResult, GetPromptResult, GetTaskPayloadResult. Then re-run pnpm run fetch:spec-types. Batch this with the resultType? optionality fix and the other upstream feedback already noted on this PR.

[claude]

🔴 🔴 The spec deletes URL_ELICITATION_REQUIRED = -32042 / URLElicitationRequiredError (replaced by the InputRequiredResult flow), but the SDK still ships this mechanism as public API: ProtocolErrorCode.UrlElicitationRequired (enums.ts:15), the UrlElicitationRequiredError class + ProtocolError.fromError() special-case (errors.ts:23-48), the public re-export (exports/public/index.ts:103), the tool-handler rethrow at packages/server/src/server/mcp.ts:211, and the examples/{client,server}/src/elicitationUrlExample.ts apps (plus docs/README links and test/integration/test/server/mcp.test.ts:1892-1937). None of these import spec.types.ts, so unlike the other findings on this PR they are silent — no typecheck or drift-guard failure surfaces them. The companion work needs to deprecate/remove the public error class + enum member (breaking change → migration.md), strip the mcp.ts special-case, and rewrite/remove the elicitationUrlExample apps.

Extended reasoning...

What changed in the spec

This sync deletes the entire -32042 error-response mechanism from the protocol. Before, the spec defined an implementation-specific JSON-RPC error code URL_ELICITATION_REQUIRED = -32042 and a URLElicitationRequiredError interface (a JSONRPCErrorResponse whose error.data.elicitations carried ElicitRequestURLParams[]). A server could respond to tools/call with this error to demand that the client open a browser URL before retrying. The diff removes both the constant and the interface; the replacement is the new InputRequiredResult result (with resultType: 'input_required' and inputRequests), which is delivered as a successful response, not an error. The error path is gone from the protocol entirely.

What the SDK still ships

The SDK implemented the -32042 flow end-to-end and exported it publicly. All of the following survive untouched after this PR:

• packages/core/src/types/enums.ts:15 — ProtocolErrorCode.UrlElicitationRequired = -32_042, an error code the spec no longer defines.
• packages/core/src/types/errors.ts:21-48 — ProtocolError.fromError() special-cases code -32042 and constructs a UrlElicitationRequiredError; the UrlElicitationRequiredError class itself wraps elicitations: ElicitRequestURLParams[] into error.data.
• packages/core/src/exports/public/index.ts:103 — export { ProtocolError, UrlElicitationRequiredError } puts the class on the package's public surface.
• packages/server/src/server/mcp.ts:211-213 — the tools/call handler catches thrown errors and, if error.code === ProtocolErrorCode.UrlElicitationRequired, rethrows so the framework serialises it onto the wire as a JSON-RPC error response instead of wrapping it into a CallToolResult with isError: true. This is runtime behaviour that emits a non-spec error code.
• examples/server/src/elicitationUrlExample.ts:58,102 — tool handlers throw new UrlElicitationRequiredError([...]).
• examples/client/src/elicitationUrlExample.ts:26,741 — client catches UrlElicitationRequiredError and drives the browser flow.
• test/integration/test/server/mcp.test.ts:1892-1937 — integration test asserting the round-trip.
• docs/client.md:471,626, docs/server.md:477, examples/{client,server}/README.md — documentation linking to the example apps.

Why this is silent (and distinct from the other comments)

Every other finding on this PR is surfaced by spec.types.test.ts or tsc because the affected code references spec.types.ts. This one is not: enums.ts, errors.ts, mcp.ts, and the example apps do not import spec.types.ts. The enum member is a hand-written numeric literal (-32_042); the error class is a hand-written subclass of ProtocolError; the mcp.ts rethrow checks the enum, not the spec interface. Nothing in CI fails when URL_ELICITATION_REQUIRED and URLElicitationRequiredError are removed from spec.types.ts. A reviewer addressing only the existing comments would fix the schemas, the unions, and the test allowlists — and ship a release that still publicly exports an error class for a protocol mechanism that no longer exists.

This is also not a duplicate of the existing comments. Comment #3206453743 (line 3291) covers the server→client request restructuring (createMessage/elicitInput/listRoots becoming InputRequiredResult payloads) and its remediation list is scoped to ServerRequestSchema/ClientResultSchema and the server.createMessage()/elicitInput()/listRoots() APIs — it never mentions the -32042 error-response path, which is a completely separate code path (a tool handler throws, mcp.ts rethrows onto the wire as a JSON-RPC error). Comment #3206453749 (line 418) mentions URLElicitationRequiredError only as a stale entry in the MISSING_SDK_TYPES allowlist affecting the spec.types.test.ts type count; it does not mention enums.ts, errors.ts, the public re-export, mcp.ts:211, or the example apps.

Step-by-step proof

1. Before (spec.types.ts pre-diff): export const URL_ELICITATION_REQUIRED = -32042; and export interface URLElicitationRequiredError extends Omit<JSONRPCErrorResponse, 'error'> { error: Error & { code: typeof URL_ELICITATION_REQUIRED; data: { elicitations: ElicitRequestURLParams[]; ... } } }.
2. After (this diff): both are deleted; the only remaining server-side mechanism for "need browser-based input before continuing" is to return { resultType: 'input_required', inputRequests: { ... } } as a successful result.
3. SDK runtime (mcp.ts:200-215): a tool handler runs, throws new UrlElicitationRequiredError([...]). The catch block at line 211 sees error.code === ProtocolErrorCode.UrlElicitationRequired (i.e., -32_042) and rethrows. Protocol then serialises this into a JSON-RPC error response with error.code = -32042 and error.data.elicitations = [...].
4. Wire: the SDK is now emitting an error code and error-data shape that the protocol no longer defines. A spec-compliant client built against the post-sync schema has no URLElicitationRequiredError type to deserialise this into and no -32042 constant to switch on.
5. Public surface: import { UrlElicitationRequiredError } from '@modelcontextprotocol/sdk' still works (exports/public/index.ts:103), and examples/server/src/elicitationUrlExample.ts actively demonstrates throwing it from a tool handler — teaching consumers a pattern the protocol just removed.
6. No CI signal: grep -r 'spec.types' packages/core/src/types/{enums,errors}.ts packages/server/src/server/mcp.ts returns nothing — these files have no compile-time link to the spec snapshot, so neither tsc nor spec.types.test.ts flags them.

Impact

After this sync the SDK publicly exports, documents, demonstrates in two example apps, and special-cases at runtime a protocol mechanism that the spec has removed. New consumers following docs/server.md and elicitationUrlExample.ts will build servers that emit non-spec error responses; spec-compliant clients will see an unrecognised -32042 error instead of an InputRequiredResult they know how to fulfil.

How to fix

This is non-mechanical, public-API companion work that must accompany the sync (or its companion PR):

• Decide deprecate-vs-remove for UrlElicitationRequiredError and ProtocolErrorCode.UrlElicitationRequired. Either remove them outright (breaking → add a migration.md entry and a major changeset) or mark them @deprecated with JSDoc pointing at the InputRequiredResult replacement and schedule removal.
• Strip the mcp.ts:211-213 rethrow special-case (and the ProtocolError.fromError() branch at errors.ts:23-28).
• Rewrite or remove examples/{client,server}/src/elicitationUrlExample.ts to use the InputRequiredResult / inputResponses flow (this dovetails with the redesign already requested in comment #3206453743), and update the four README/docs links that point at them.
• Delete test/integration/test/server/mcp.test.ts:1892-1937 (or rewrite it for the new flow).

[claude]

🟡 Upstream spec inconsistency to batch with the other schema.ts feedback: this sync strips extends TaskAugmentedRequestParams from CreateMessageRequestParams/ElicitRequestFormParams/ElicitRequestURLParams (and extends JSONRPCRequest from their requests), so task-augmented sampling/elicitation no longer exists in the protocol — yet ClientCapabilities.tasks.requests.{sampling.createMessage, elicitation.create} (spec.types.ts:628-647, untouched by this diff) still advertise support for it. The SDK mirrors these flags in ClientTasksCapabilitySchema (schemas.ts:349-365) and gates on them at runtime in assertClientRequestTaskCapability (experimental/tasks/helpers.ts:78-96), so after the InputRequiredResult redesign those schema fields and switch arms become unreachable. Should be raised upstream so schema.ts drops tasks.requests.{sampling,elicitation}, after which the SDK can prune the dead capability schema and helper branches.

Extended reasoning...

What the bug is

This sync removes the mechanism for task-augmented sampling/elicitation but leaves the capability advertisement for it in place. Concretely, the diff drops extends TaskAugmentedRequestParams from CreateMessageRequestParams (line 2245), ElicitRequestFormParams (2883) and ElicitRequestURLParams (2916), and drops extends JSONRPCRequest from CreateMessageRequest/ElicitRequest/ListRootsRequest — sampling and elicitation are no longer wire-level requests at all, and can no longer carry a params.task field. They now exist solely as payloads embedded inside InputRequiredResult.inputRequests (per comment #1).

But ClientCapabilities.tasks.requests at spec.types.ts:628-647 — not touched by this diff — still defines:

requests?: {
    sampling?: {
        /** Whether the client supports task-augmented `sampling/createMessage` requests. */
        createMessage?: JSONObject;
    };
    elicitation?: {
        /** Whether the client supports task-augmented elicitation/create requests. */
        create?: JSONObject;
    };
};

These two are the only members of tasks.requests, and their JSDoc explicitly references "task-augmented sampling/elicitation requests" — a flow this same upstream commit just deleted. The spec is now internally inconsistent: it advertises a capability for a mechanism it no longer defines.

Why this isn't just dead prose — concrete SDK surface affected

The SDK mirrors and acts on these flags:

• ClientTasksCapabilitySchema (schemas.ts:349-365) defines requests.sampling.createMessage / requests.elicitation.create as Zod schema fields.
• assertClientRequestTaskCapability (experimental/tasks/helpers.ts:69-97) switches on method, with arms for 'sampling/createMessage' (checks requests.sampling?.createMessage, line 79-87) and 'elicitation/create' (checks requests.elicitation?.create, line 89-96), throwing SdkErrorCode.CapabilityNotSupported if absent.
• That helper is called from server.ts:414 and client.ts:709, and re-exported from the public surface (exports/public/index.ts:122).

After the InputRequiredResult redesign, no caller can ever reach those switch arms with a task-augmented request — CreateMessageRequest/ElicitRequest are no longer JSON-RPC requests, so the SDK will never dispatch them through the path that calls assertClientRequestTaskCapability. The capability flags, the schema fields, and the two switch arms all become unreachable protocol surface.

Step-by-step proof

1. Before this sync: CreateMessageRequestParams extends TaskAugmentedRequestParams → a server could send { method: 'sampling/createMessage', params: { task: {...}, messages: [...] } } as a wire request. The client advertises support via capabilities.tasks.requests.sampling.createMessage = {}, and assertClientRequestTaskCapability(caps.tasks?.requests, 'sampling/createMessage', ...) validates it before sending.
2. After this sync: CreateMessageRequestParams has no extends clause (line 2245) → no task field. CreateMessageRequest has no extends JSONRPCRequest (line 2314) → not a wire request. It is now only reachable as a value inside InputRequests (line 348: InputRequest = CreateMessageRequest | ListRootsRequest | ElicitRequest), which is embedded in InputRequiredResult.inputRequests.
3. Yet ClientCapabilities.tasks.requests.sampling.createMessage (line 636) is unchanged. There is no longer any request shape in the spec for which this flag could meaningfully gate behaviour.
4. Therefore assertClientRequestTaskCapability's case 'sampling/createMessage' and case 'elicitation/create' arms (helpers.ts:79-96) can never be reached by a spec-compliant flow, and ClientTasksCapabilitySchema.requests (schemas.ts:349-365) validates fields the protocol no longer uses.

Why this is distinct from the existing comments

Comment #1 covers the SDK's request/result-handler divergence (ServerRequestSchema/ClientResultSchema, server.createMessage()/elicitInput() APIs) — i.e., the SDK still treating these as wire requests. This finding is about the spec being internally inconsistent with itself: the same upstream commit that removed task-augmented sampling/elicitation left the capability advertisement for it in ClientCapabilities. None of comments #1-#6 mention ClientCapabilities.tasks.requests or assertClientRequestTaskCapability. It's the same class of upstream-defect feedback as comment #4 (taskId missing) and #6 (discriminant not narrowed): doesn't break CI (all fields optional), but identifies something schema.ts should fix before the SDK encodes the new shape.

Impact

No CI breakage — tasks.requests and its children are all optional, and this diff doesn't touch ClientCapabilities, so the bidirectional assignability check still passes for that type. But it leaves orphaned protocol surface that will confuse implementers (a client setting tasks.requests.sampling.createMessage is now a no-op), and it identifies concrete SDK code that the companion work should prune rather than carry forward.

How to fix

Upstream in schema.ts: drop requests.sampling and requests.elicitation from ClientCapabilities.tasks (which empties tasks.requests entirely — it can be removed too unless other request types are planned). Batch with the resultType? (#3), taskId (#4), JSDoc (#5), and discriminant-narrowing (#6) feedback. Once re-pulled, the SDK companion work can delete ClientTasksCapabilitySchema.shape.requests (schemas.ts:349-365) and the 'sampling/createMessage' / 'elicitation/create' arms of assertClientRequestTaskCapability (helpers.ts:79-96).

[claude]

🟡 Upstream design gap to batch with the other schema.ts feedback: InputResponse = CreateMessageResult | ListRootsResult | ElicitResult admits only success payloads, and the InputResponseRequestParams.inputResponses comment says every inputRequests key "must appear here". In the pre-sync model these were full JSON-RPC requests so a client could return a JSONRPCErrorResponse for user-denied sampling / LLM provider error / no roots configured; that error channel is gone with no replacement (ElicitResult has action: 'decline'|'cancel', but CreateMessageResult and ListRootsResult have no refusal field). The SDK redesign called for in the earlier comment will have no spec-defined way to propagate per-request failures and would have to invent an out-of-spec workaround that breaks once upstream adds a real error variant — suggest upstream add an InputResponseError arm (mirroring the JSON-RPC {code, message, data} shape) or relax the must-appear rule.

Extended reasoning...

What the bug is

InputResponse (spec.types.ts:351) is defined as CreateMessageResult | ListRootsResult | ElicitResult — a union of three success payloads only. InputResponses (line 376-378) is { [key: string]: InputResponse }, and the normative-sounding comment on InputResponseRequestParams.inputResponses (lines 410-413) says: "For each key in the response's inputRequests field, the same key must appear here with the associated response." So per the spec text, the client must supply a value for every requested key, and that value must be one of the three success result shapes.

In the pre-sync model these three exchanges were ordinary server→client JSON-RPC requests (CreateMessageRequest extends JSONRPCRequest, etc.), so a client that could not or would not fulfil one returned a JSONRPCErrorResponse carrying { code: number; message: string; data?: unknown }. By stripping extends JSONRPCRequest / extends Result and embedding the exchange inside the InputRequests/InputResponses maps, the spec discarded that error channel without adding a replacement.

Why the existing types don't cover it

• ElicitResult happens to carry action: 'accept' | 'decline' | 'cancel', so elicitation can encode refusal in-band.
• CreateMessageResult (line ~2335) is SamplingMessage & { model: string; stopReason?: ... } — required model/role/content, no refusal/error field, no index signature now that extends Result is dropped.
• ListRootsResult (line ~2826) is bare { roots: Root[] } — same story.

The asymmetry (only ElicitResult has a decline arm) suggests this is an oversight rather than an intentional "refusal-via-abandonment" design — if abandoning the retry were the intended refusal signal, ElicitResult would not need action: 'decline' either.

Step-by-step proof

1. Server returns CallToolResultResponse with result: InputRequiredResult { inputRequests: { 's1': <CreateMessageRequest>, 'e1': <ElicitRequest> } }.
2. Client presents the elicitation; user accepts → { action: 'accept', content: {...} }.
3. Client attempts the sampling call; the LLM provider returns HTTP 429 / content-policy refusal / the user denies the sampling-consent prompt.
4. Client must now construct inputResponses for the retry. Per lines 410-413, both 's1' and 'e1' must appear. 'e1' is fine. For 's1' the only spec-permitted shapes are CreateMessageResult | ListRootsResult | ElicitResult — none of which can express "this request failed with code X / message Y".
5. The client's only options are: (a) omit 's1' — textually non-compliant with the must-appear rule; (b) abandon the whole retry / call tasks/cancel — loses the successful elicitation and gives the server no error code/message to act on; (c) stuff a fake CreateMessageResult or an off-spec { error: {...} } object into 's1' — out of spec.

Why this matters for the SDK companion work

Today a client-side setRequestHandler(CreateMessageRequestSchema, …) can throw / reject and the SDK serialises a JSONRPCErrorResponse; the server's await ctx.sample() rejects with a ProtocolError carrying the code and message, and the tool handler can catch it and fall back. The redesign called for in comment #1 must preserve some equivalent of those semantics, but there is no spec-defined wire shape to carry them. Whatever workaround the SDK picks (drop the key, cancel the whole flow, invent an envelope) becomes public API that breaks once upstream adds a real error variant.

This is distinct from comment #1 (about the SDK still issuing these as wire requests), comment #4 (about tasks/input_response lacking taskId), and comment #6 (about the resultType discriminant) — none of those address the missing error arm in the InputResponse payload union itself.

Addressing "all-or-nothing is the intended design"

It is plausible the spec intends atomic fulfilment (client either satisfies every input or abandons). But (a) that loses the error code/message — the server cannot distinguish rate-limit vs. content-policy vs. user-denied, which is a real expressiveness regression vs. the JSON-RPC model; (b) it is contradicted by ElicitResult.action: 'decline'|'cancel' existing at all; and (c) even under that reading, the SDK still has to pick a public error-propagation contract for ctx.sample() rejection in the new flow, and it is better to do so against a spec-defined error variant than to guess.

How to fix

Raise upstream alongside the resultType? / taskId / discriminant fixes: either add an error arm, e.g.

export interface InputResponseError {
    code: number;
    message: string;
    data?: unknown;
}
export type InputResponse = CreateMessageResult | ListRootsResult | ElicitResult | InputResponseError;

(mirroring the removed JSON-RPC Error shape), or relax the "must appear" wording on inputResponses and define omission as refusal. Then re-run pnpm run fetch:spec-types. Don't encode InputResponsesSchema in schemas.ts until this is settled. Filed as a nit because it doesn't independently break CI and abandon-the-flow is a viable (if lossy) fallback — same tier as comments #5/#6.

[claude]

🔴 Beyond the 10 Multi Round-Trip types already flagged in the earlier comment, this updated sync brings in a second, disjoint batch of new exports with no SDK counterparts: DiscoverRequest/DiscoverResult/DiscoverResultResponse, SubscriptionFilter, SubscriptionsListenRequest/SubscriptionsListenRequestParams, SubscriptionsAcknowledgedNotification/SubscriptionsAcknowledgedNotificationParams, UnsupportedProtocolVersionError, MissingRequiredClientCapabilityError, and the MISSING_REQUIRED_CLIENT_CAPABILITY = -32003 constant. None of these appear in schemas.ts/types.ts/specTypeSchema.ts/enums.ts, so each one trips the spec.types.test.ts coverage check and widens the toHaveLength(176) delta further; ServerNotification now includes SubscriptionsAcknowledgedNotification and ServerResult now includes DiscoverResult, so those bidirectional union checks fail too. This is the additive half of the stateless-protocol overhaul — the subtractive half (deleted Initialize*/Ping*/SetLevel*/Subscribe*/Unsubscribe*/RootsListChangedNotification) is filed separately.

Extended reasoning...

What changed

The latest force-push to this PR layers a stateless-protocol overhaul on top of the Multi Round-Trip changes that the earlier comment (#3206453749) already enumerates. That earlier comment lists exactly 10 types (ResultType, InputRequest/InputResponse/InputRequests/InputResponses, InputRequiredResult, InputResponseRequestParams, TaskInputResponseRequest/TaskInputResponseRequestParams/TaskInputResponseResultResponse). This finding covers a second, fully disjoint batch of new exports introduced by the same diff:

New export	Replaces / purpose
DiscoverRequest / DiscoverResult / DiscoverResultResponse	replacement for initialize
SubscriptionFilter	opt-in notification selector
SubscriptionsListenRequest / SubscriptionsListenRequestParams	replacement for resources/subscribe/unsubscribe + the HTTP GET stream
SubscriptionsAcknowledgedNotification / SubscriptionsAcknowledgedNotificationParams	first message on a subscriptions/listen stream
UnsupportedProtocolVersionError	new error envelope (code: INVALID_PARAMS, data.supported/data.requested)
MissingRequiredClientCapabilityError	new error envelope (code: -32003, data.requiredCapabilities)
MISSING_REQUIRED_CLIENT_CAPABILITY = -32003	new error-code constant

A grep for DiscoverRequest|DiscoverResult|SubscriptionFilter|SubscriptionsListen|SubscriptionsAcknowledged|UnsupportedProtocolVersionError|MissingRequiredClientCapability|MISSING_REQUIRED_CLIENT_CAPABILITY|-32003|32_003 across packages/core/src matches only spec.types.ts — no schemas.ts Zod schemas, no types.ts aliases, no specTypeSchema.ts registrations, no guards.ts predicates, and enums.ts has no ProtocolErrorCode member for -32003.

How it manifests in CI

packages/core/test/spec.types.test.ts enforces three invariants that this batch breaks (independently of the 10 Multi Round-Trip types and independently of the deletions filed in the sibling comment):

1. Coverage check — should have comprehensive compatibility tests (lines ~1098-1107) parses every export (interface|type) <Name> from spec.types.ts, skips the MISSING_SDK_TYPES allowlist (['Error', 'URLElicitationRequiredError']), and asserts sdkTypeChecks[<Name>] is defined. DiscoverRequest, DiscoverResult, DiscoverResultResponse, SubscriptionFilter, SubscriptionsListenRequest, SubscriptionsListenRequestParams, SubscriptionsAcknowledgedNotification, SubscriptionsAcknowledgedNotificationParams, UnsupportedProtocolVersionError, and MissingRequiredClientCapabilityError each produce expected undefined to be defined. (MISSING_REQUIRED_CLIENT_CAPABILITY is export const, so the extractExportedTypes regex does not pick it up — but the lack of a ProtocolErrorCode enum member for -32003 is still a real SDK gap that needs addressing alongside the schema work.)
2. Type count — expect(specTypes).toHaveLength(176) (line ~1089) was already off by the Multi Round-Trip delta; this batch widens it by another +10 exported interfaces/types on the additive side.
3. Union assignability — the diff adds SubscriptionsAcknowledgedNotification to ServerNotification (line 3289) and DiscoverResult to ServerResult (line 3308). The bidirectional spec = sdk; sdk = spec; checks for ServerNotification/ServerResult fail because the SDK unions in schemas.ts contain neither.

Why existing code doesn't prevent it

By design — spec.types.test.ts is the drift guard whose purpose is to turn the automated cron sync into a forcing function for SDK updates. The cron job updates only spec.types.ts; nothing generates the matching Zod schemas, SDK type aliases, specTypeSchemas registrations, ProtocolErrorCode enum members, or sdkTypeChecks entries.

Step-by-step proof

1. After this diff, spec.types.ts:377-405 exports UnsupportedProtocolVersionError and MissingRequiredClientCapabilityError; lines ~554-619 export DiscoverRequest/DiscoverResult/DiscoverResultResponse; lines ~1170-1257 export SubscriptionFilter/SubscriptionsListenRequest/SubscriptionsListenRequestParams/SubscriptionsAcknowledgedNotification/SubscriptionsAcknowledgedNotificationParams.
2. spec.types.test.ts's extractExportedTypes regex (/^export (interface|type) (\w+)/gm) picks up all 10 names.
3. None of those 10 names appears in MISSING_SDK_TYPES (only 'Error' and 'URLElicitationRequiredError').
4. None has an sdkTypeChecks entry → 10 × expect(sdkTypeChecks[name]).toBeDefined() failures.
5. SDKTypes.ServerNotification (from ServerNotificationSchema in schemas.ts) has no notifications/subscriptions/acknowledged arm, so sdk = spec fails for ServerNotification; likewise SDKTypes.ServerResult has no DiscoverResult arm, so sdk = spec fails for ServerResult.
6. grep -r '32003' packages/core/src/types/enums.ts → no match; the SDK has no name for the new error code.

Why this is distinct from the existing PR comments

Comment #3206453749 enumerates only the 10 Multi Round-Trip types — it does not mention any of the Discover*/Subscription* types, the two error envelopes, or -32003. The sibling "deletions" comment covers the removal of Initialize*/Ping*/SetLevel*/Subscribe*/Unsubscribe*/RootsListChangedNotification and the lifecycle redesign that forces; this comment covers the additions whose remediation is mechanical schema work plus a new ProtocolErrorCode enum member. The split mirrors the PR's existing comment-#1/#2 structure for the InputRequiredResult flow (architectural removal vs. mechanical additions).

How to fix

Companion commit on top of the cron sync:

• schemas.ts: add DiscoverRequestSchema/DiscoverResultSchema/DiscoverResultResponseSchema, SubscriptionFilterSchema, SubscriptionsListenRequestSchema/...ParamsSchema, SubscriptionsAcknowledgedNotificationSchema/...ParamsSchema, UnsupportedProtocolVersionErrorSchema, MissingRequiredClientCapabilityErrorSchema; add SubscriptionsAcknowledgedNotificationSchema to ServerNotificationSchema and DiscoverResultSchema to ServerResultSchema; add DiscoverRequestSchema/SubscriptionsListenRequestSchema to ClientRequestSchema.
• enums.ts: add ProtocolErrorCode.MissingRequiredClientCapability = -32_003.
• types.ts / specTypeSchema.ts: add the corresponding SDK aliases and specTypeSchemas registrations.
• spec.types.test.ts: add sdkTypeChecks entries for all 10 new names (or add the two error envelopes to MISSING_SDK_TYPES if the SDK chooses to model them as ProtocolError subclasses rather than schemas, mirroring the prior URLElicitationRequiredError treatment), and update the toHaveLength(...) count once both the additive and subtractive halves are reconciled.

[claude]

🔴 🔴 The cron commit now pulled into this PR is the stateless-protocol overhaul, which goes far beyond the InputRequiredResult/Multi-Round-Trip changes the existing nine comments cover: InitializeRequest/InitializeResult/InitializeResultResponse/InitializedNotification are deleted (replaced by DiscoverRequest/DiscoverResult, method server/discover), PingRequest/PingResultResponse are deleted, SetLevelRequest/SetLevelResultResponse are deleted (replaced by per-request _meta['io.modelcontextprotocol/logLevel']), SubscribeRequest/UnsubscribeRequest are deleted (replaced by SubscriptionsListenRequest + SubscriptionsAcknowledgedNotification), RootsListChangedNotification is deleted, RequestParams._meta becomes required with three mandatory io.modelcontextprotocol/* keys, and ClientRequest/ClientNotification/ServerRequest are rewritten accordingly. The SDK's entire connection lifecycle is built on the deleted types — client.connect() sends initialize/notifications/initialized, server.ts registers an initialize handler and gates on it, Protocol.ping(), setLoggingLevel()/subscribeResource()/unsubscribeResource()/sendRootsListChanged(), plus InitializeRequestSchema/PingRequestSchema/SetLevelRequestSchema/SubscribeRequestSchema/UnsubscribeRequestSchema/InitializedNotificationSchema/RootsListChangedNotificationSchema in schemas.ts/types.ts/guards.ts/specTypeSchema.ts — and spec.types.test.ts hard-references all ~16 deleted SpecTypes.* names so tsc fails outright. None of the prior comments mention initialize→discover, ping removal, setLevel→_meta logLevel, subscribe/unsubscribe→subscriptions/listen, or RootsListChangedNotification removal; this is a separate, larger architectural divergence requiring an SDK handshake/keep-alive/log-level/subscription/roots-signalling redesign — not a mechanical schema add — so this PR must be held until that companion redesign exists.

Extended reasoning...

What changed

The latest commit pulled by this cron sync (8e192a22…, replacing 5c252088…) is the upstream stateless-protocol overhaul. The protocol no longer has a connection-lifecycle handshake; instead every request carries the handshake metadata in _meta. Concretely the diff:

• Deletes InitializeRequest / InitializeRequestParams / InitializeResult / InitializeResultResponse / InitializedNotification and replaces them with DiscoverRequest / DiscoverResult / DiscoverResultResponse (method server/discover, optional, returns supportedVersions: string[] instead of a single negotiated protocolVersion).
• Deletes PingRequest / PingResultResponse outright — no replacement; ServerRequest no longer contains a ping at all.
• Deletes SetLevelRequest / SetLevelRequestParams / SetLevelResultResponse — replaced by an optional per-request _meta['io.modelcontextprotocol/logLevel'] key.
• Deletes SubscribeRequest / SubscribeRequestParams / SubscribeResultResponse / UnsubscribeRequest / UnsubscribeRequestParams / UnsubscribeResultResponse — replaced by a single long-lived SubscriptionsListenRequest (method subscriptions/listen) carrying a SubscriptionFilter, plus a server→client SubscriptionsAcknowledgedNotification.
• Deletes RootsListChangedNotification and reduces ClientCapabilities.roots to {} (the listChanged flag is gone).
• Makes RequestParams._meta required and adds three required keys to RequestMetaObject: 'io.modelcontextprotocol/protocolVersion', 'io.modelcontextprotocol/clientInfo', 'io.modelcontextprotocol/clientCapabilities' (plus optional '…/logLevel').
• Adds UnsupportedProtocolVersionError / MissingRequiredClientCapabilityError / MISSING_REQUIRED_CLIENT_CAPABILITY = -32003.
• Rewrites the unions: ClientRequest drops PingRequest/InitializeRequest/SetLevelRequest/SubscribeRequest/UnsubscribeRequest and adds DiscoverRequest/SubscriptionsListenRequest; ClientNotification drops InitializedNotification/RootsListChangedNotification; ServerRequest drops PingRequest; ServerNotification adds SubscriptionsAcknowledgedNotification; ServerResult swaps InitializeResult→DiscoverResult.

Immediate breakage

packages/core/test/spec.types.test.ts hard-references the deleted names — e.g. SpecTypes.InitializeRequest/InitializeRequestParams/InitializeResult/InitializeResultResponse/InitializedNotification/PingRequest/PingResultResponse/SetLevelRequest/SetLevelRequestParams/SetLevelResultResponse/SubscribeRequest/SubscribeRequestParams/SubscribeResultResponse/UnsubscribeRequest/UnsubscribeRequestParams/UnsubscribeResultResponse/RootsListChangedNotification at lines ~42/58/62/81/139/143/287/304/308/312/479/483/671/675/812/816-817/823/886/940/948/955-956/963-964/973/987-989. Each becomes an unconditional TS2694: Namespace '…spec.types' has no exported member '…' — the package will not compile. The hardcoded type-count assertion and the ClientRequest/ClientNotification/ServerRequest/ServerResult bidirectional checks all fail too. (The earlier comments' "176 vs 182" / "10 added, 4 removed" numbers were written against a smaller previous revision; the current diff removes ~17 and adds ~20 types, so even those comments' counts are stale.)

Architectural divergence (the part that matters)

The SDK's runtime is built around the very flows this commit deletes:

• Handshake: packages/client/src/client/client.ts:connect() sends { method: 'initialize', params: { protocolVersion, capabilities, clientInfo } } and then notifications/initialized; packages/server/src/server/server.ts registers an 'initialize' handler and a 'notifications/initialized' handler and gates every other request behind assertInitialized().
• Keep-alive: Protocol.ping() sends { method: 'ping' }.
• Logging level: client.setLoggingLevel() sends logging/setLevel; server.ts registers a 'logging/setLevel' handler.
• Resource subscriptions: client.subscribeResource() / unsubscribeResource() send resources/subscribe / resources/unsubscribe.
• Roots change signalling: client.sendRootsListChanged() sends notifications/roots/list_changed.
• Schemas/types/guards: schemas.ts defines InitializeRequestSchema / InitializedNotificationSchema / PingRequestSchema / SetLevelRequestSchema / SubscribeRequestSchema / UnsubscribeRequestSchema / RootsListChangedNotificationSchema, all referenced from types.ts, guards.ts, specTypeSchema.ts, and the ClientRequestSchema / ServerRequestSchema / ClientNotificationSchema unions.

After this sync, an SDK client talking to a spec-compliant server would send an initialize request the server is not obligated to handle, would never populate the now-required _meta.{protocolVersion,clientInfo,clientCapabilities} on each request, would attempt ping/logging/setLevel/resources/subscribe calls that no longer exist, and has no implementation of server/discover or subscriptions/listen. Conversely, an SDK server would reject every request from a spec-compliant client because assertInitialized() never sees an initialize.

Step-by-step proof

1. Before (spec.types.ts @ 5c252088): export interface InitializeRequest extends JSONRPCRequest { method: 'initialize'; params: InitializeRequestParams }, and ClientRequest = PingRequest | InitializeRequest | … | SetLevelRequest | … | SubscribeRequest | UnsubscribeRequest | ….
2. After (this diff, lines 566-569): export interface DiscoverRequest extends JSONRPCRequest { method: 'server/discover'; params?: RequestParams }. Grepping the new file for InitializeRequest / 'initialize' / PingRequest / 'ping' / SetLevelRequest / 'logging/setLevel' / SubscribeRequest / 'resources/subscribe' / 'resources/unsubscribe' / RootsListChangedNotification / 'notifications/roots/list_changed' returns nothing.
3. spec.types.test.ts:139 does (sdk: WithJSONRPCRequest<SDKTypes.InitializeRequest>, spec: SpecTypes.InitializeRequest) => { … } → TS2694 "no exported member 'InitializeRequest'". Same for ~16 other deleted names → tsc --noEmit -p packages/core fails before any test runs.
4. packages/server/src/server/server.ts registers this.setRequestHandler(InitializeRequestSchema, …) and this.setNotificationHandler(InitializedNotificationSchema, …); packages/client/src/client/client.ts:connect() does await this.request({ method: 'initialize', … }, InitializeResultSchema) then this.notification({ method: 'notifications/initialized' }). None of these have a spec counterpart anymore.
5. RequestParams._meta is now non-optional with three required io.modelcontextprotocol/* keys, but schemas.ts's RequestParamsSchema declares _meta optional with no such keys, so the Request/RequestParams/RequestMetaObject bidirectional checks in spec.types.test.ts also fail.

Why this is distinct from the existing nine comments

• #3206453743 covers only sampling/elicitation/roots moving into InputRequiredResult.
• #3206453749 covers only the 10 new Multi-Round-Trip type additions.
• #3206453753 / #3214351594 cover resultType required/discriminant.
• #3214351591 covers tasks/input_response lacking taskId.
• #3214351593 covers JSDoc /* */ vs /** */.
• #3216586348 covers -32042/URLElicitationRequiredError removal.
• #3216586352 / #3216586357 cover tasks.requests capability and InputResponse error arm.

None of them mention initialize→discover, ping removal, setLevel→_meta logLevel, subscribe/unsubscribe→subscriptions/listen, RootsListChangedNotification removal, the required _meta keys, or the new UnsupportedProtocolVersionError/MissingRequiredClientCapabilityError types. Their type-count arithmetic ("182") confirms they were written against an earlier, smaller revision of this PR.

Recommended action

Hold this automated sync until a companion redesign lands. That work is not "add schemas" — it is:

• Replace the connect()-time initialize/initialized handshake with per-request _meta injection (protocolVersion/clientInfo/clientCapabilities) and an optional server/discover call; rip out assertInitialized() gating on the server.
• Remove Protocol.ping() (or repoint it at a transport-level liveness check).
• Replace setLoggingLevel() with a per-request _meta['io.modelcontextprotocol/logLevel'] setter.
• Replace subscribeResource()/unsubscribeResource() with a subscriptions/listen stream + SubscriptionsAcknowledgedNotification handling.
• Remove sendRootsListChanged() and the roots.listChanged capability plumbing.
• Add schemas for DiscoverRequest/DiscoverResult/DiscoverResultResponse/SubscriptionFilter/SubscriptionsListenRequest/SubscriptionsListenRequestParams/SubscriptionsAcknowledgedNotification/SubscriptionsAcknowledgedNotificationParams/UnsupportedProtocolVersionError/MissingRequiredClientCapabilityError/MISSING_REQUIRED_CLIENT_CAPABILITY; delete the seven now-orphaned *Schema definitions and their references in types.ts/guards.ts/specTypeSchema.ts and the ClientRequestSchema/ServerRequestSchema/ClientNotificationSchema unions.
• Update spec.types.test.ts: remove the ~17 deleted sdkTypeChecks entries, add the new ones, and fix the type-count assertion.

[claude]

🟡 🟡 Upstream spec gap to batch with the other schema.ts feedback: SubscriptionsListenRequest extends JSONRPCRequest (so it carries an id and per JSON-RPC 2.0 must eventually receive exactly one response object), but unlike every other *Request extends JSONRPCRequest in this file it has no SubscriptionsListenResult / SubscriptionsListenResultResponse, and ServerResult includes none. The spec instead has the server send SubscriptionsAcknowledgedNotification "as the first message on the stream" — a notification (no id), not a response — so the wire contract for completing/closing the subscriptions/listen request is undefined, and when the SDK adds SubscriptionsListenRequestSchema it will have no spec-defined result schema to pair with Protocol.request() (the pending-request map would leak the id if the server never responds). Suggest upstream either add SubscriptionsListenResultResponse { result: EmptyResult } (sent on stream close) or document that this request is intentionally never JSON-RPC-responded so the SDK can special-case its id bookkeeping.

Extended reasoning...

What the bug is

SubscriptionsListenRequest (spec.types.ts:1223) is declared as:

export interface SubscriptionsListenRequest extends JSONRPCRequest {
    method: 'subscriptions/listen';
    params: SubscriptionsListenRequestParams;
}

Because it extends JSONRPCRequest, it carries jsonrpc: '2.0' and id: RequestId. Per JSON-RPC 2.0 §4.2, a request object that includes an id MUST eventually receive exactly one response object (either a result or an error) carrying that same id. But the spec defines no SubscriptionsListenResult or SubscriptionsListenResultResponse, and ServerResult (line 3296+) has no member for it. The only server reaction the spec defines is SubscriptionsAcknowledgedNotification — "sent by the server as the first message on a subscriptions/listen stream" — which extends JSONRPCNotification and therefore has no id and cannot satisfy the JSON-RPC response requirement.

Why this is uniquely inconsistent

Grepping the file shows 11 concrete interfaces that extends JSONRPCRequest (DiscoverRequest, PaginatedRequest and its derivatives, ReadResourceRequest, SubscriptionsListenRequest, GetPromptRequest, CallToolRequest, GetTaskRequest, GetTaskPayloadRequest, TaskInputResponseRequest, CancelTaskRequest, CompleteRequest) and 15 *ResultResponse extends JSONRPCResultResponse wrappers. Every JSONRPCRequest subtype has a paired *ResultResponse — except SubscriptionsListenRequest. The deleted predecessors it replaces (SubscribeRequest / UnsubscribeRequest) both had explicit { result: EmptyResult } wrappers (SubscribeResultResponse / UnsubscribeResultResponse), so this is a regression in spec completeness, not an established convention for "streaming" requests. ServerResult does include EmptyResult, so a server could respond with that on stream close, but the spec does not say so and there is no SubscriptionsListenResultResponse documenting it.

Step-by-step proof

1. Client sends { jsonrpc: '2.0', id: 7, method: 'subscriptions/listen', params: { notifications: {...} } } (this is a JSON-RPC request because SubscriptionsListenRequest extends JSONRPCRequest, line 1223).
2. Server replies with { jsonrpc: '2.0', method: 'notifications/subscriptions/acknowledged', params: { notifications: {...} } } (line 1255 — extends JSONRPCNotification, no id).
3. Per JSON-RPC 2.0, message (2) is a notification, not a response to id: 7. The client's pending-request entry for id: 7 is still outstanding.
4. The spec defines no message that ever carries id: 7 back. There is no SubscriptionsListenResultResponse; ServerResult has no dedicated arm; the JSDoc on SubscriptionsListenRequest does not say "the server never responds" or "the server responds with EmptyResult on stream close".
5. Three behaviours are therefore equally spec-compliant and mutually incompatible: (a) server sends { id: 7, result: {} } immediately and then streams notifications; (b) server sends { id: 7, result: {} } only when the stream closes; (c) server never responds and the client must special-case the id. The wire contract is undefined.

Concrete SDK impact

The SDK's Protocol.request() API takes a request and a result schema, stores the id in a pending-request map, and resolves the returned promise when a matching response arrives. When the companion work (already requested in comment #3223937253) adds SubscriptionsListenRequestSchema, there is no spec-defined result schema to pass as the second argument. If the SDK uses EmptyResultSchema and a server follows interpretation (c), the promise never resolves and the pending-request map leaks id: 7 for the lifetime of the connection. If the SDK special-cases this method to not await a response and a server follows interpretation (a), the SDK will receive an unsolicited { id: 7, result: {} } it has no handler for. Either way, encoding SubscriptionsListenRequestSchema before this is settled bakes a guess into the public surface that breaks once upstream picks one.

Why this is distinct from existing PR comments

Comment #3223937253 lists SubscriptionsListenRequest/SubscriptionsListenRequestParams among the "new types needing SDK schemas" but does not note that there is no response type to pair them with — it assumes mechanical schema work, which is precisely what this gap blocks. Comment #3223937258 covers the SDK lifecycle redesign (subscribeResource()/unsubscribeResource() → subscriptions/listen) but does not address the spec's own JSON-RPC response-contract gap. This is the same class of upstream-schema.ts design feedback as #3214351591 (taskId missing), #3214351594 (discriminant not narrowed), and #3216586357 (InputResponse error arm) — concrete enough to block correct SDK implementation, but doesn't independently break CI (the drift guard checks for types that exist, not types that should exist), hence nit.

How to fix

Raise upstream alongside the other schema.ts feedback. Two options:

• Add a response wrapper: export interface SubscriptionsListenResultResponse extends JSONRPCResultResponse { result: EmptyResult; } and document that the server sends it when the stream closes (or immediately after the ack notification, depending on intended semantics). This matches the deleted SubscribeResultResponse/UnsubscribeResultResponse precedent.
• Document the no-response contract: state explicitly in the SubscriptionsListenRequest JSDoc that the server MUST NOT send a JSON-RPC response for this request and that clients MUST NOT track its id in their pending-request map (or, more cleanly, change it to extend JSONRPCNotification so it carries no id at all — though that loses the ability to error-respond).

Then re-run pnpm run fetch:spec-types. Don't add SubscriptionsListenRequestSchema to schemas.ts until this is settled.

[claude]

🟡 Upstream spec self-inconsistency to batch with the other schema.ts feedback: RequestParams._meta is now required with three required client-identity keys (io.modelcontextprotocol/{protocolVersion,clientInfo,clientCapabilities}), but RequestParams is still referenced from contexts where that doesn't fit — DiscoverRequest.params? and PaginatedRequest.params? are still optional (so a client can type-validly omit the "Required" handshake metadata entirely, and discovery is circular: you must commit to a protocolVersion to ask which versions are supported); the server→client ListTasksRequest inherits PaginatedRequestParams → RequestParams, forcing a server sending tasks/list with a cursor to populate the client's clientInfo/clientCapabilities; and the server-authored ListRootsRequest (now only an InputRequest payload) kept params?: RequestParams while its siblings CreateMessageRequest/ElicitRequest had their RequestParams inheritance stripped. Suggest upstream make the three keys optional (or split RequestMetaObject by direction), make params non-optional on client wire requests, exempt server/discover, and drop the RequestParams reference from ListRootsRequest.

Extended reasoning...

What the issue is

This sync changes RequestParams (line 145) from _meta?: RequestMetaObject to _meta: RequestMetaObject and adds three required keys to RequestMetaObject (lines 82/89/97): 'io.modelcontextprotocol/protocolVersion', 'io.modelcontextprotocol/clientInfo', and 'io.modelcontextprotocol/clientCapabilities', each with JSDoc explicitly saying "Required." The intent — moving the handshake from a one-time initialize to per-request _meta — is clear, but RequestParams is still used in three places where mandatory client-identity metadata is either omittable, semantically wrong, or circular. This is the spec being internally inconsistent, distinct from comment #3223937258 which only notes that the SDK's RequestParamsSchema doesn't match the new required _meta.

Surface 1 — params? still optional on client wire requests

DiscoverRequest.params?: RequestParams (line 568) and PaginatedRequest.params?: PaginatedRequestParams (line 1014, inherited by ListResourcesRequest / ListResourceTemplatesRequest / ListPromptsRequest / ListToolsRequest / ListTasksRequest) declare params as optional. So { jsonrpc: '2.0', id: 1, method: 'tools/list' } is type-valid yet carries no _meta and therefore none of the "Required" handshake metadata — the spec contradicts itself. Pre-sync this was consistent because _meta was optional; the upstream commit tightened _meta without tightening params.

The DiscoverRequest case is additionally circular. Per its JSDoc, server/discover exists so the client can learn supportedVersions for use in subsequent requests, and per the JSDoc on protocolVersion (line 80) the server MUST return UnsupportedProtocolVersionError if the value is not supported. But if the client supplies params, it must include _meta['io.modelcontextprotocol/protocolVersion'] — i.e., commit to a version before learning which versions are supported. Either DiscoverRequest should not use RequestParams, or protocolVersion should be optional/exempt for discovery; the params? escape hatch is at best implicit and contradicts the unconditional "Required." prose.

Surface 2 — server→client wire request inherits client-direction keys

ServerRequest (line 3280) = GetTaskRequest | GetTaskPayloadRequest | ListTasksRequest | CancelTaskRequest. Three of these use inline params: { taskId: string } and escape, but ListTasksRequest (line 2155) extends PaginatedRequest → params?: PaginatedRequestParams (line 1004) extends RequestParams → _meta: RequestMetaObject with required clientInfo/clientCapabilities. The JSDoc on those keys is unambiguously client→server ("Identifies the client software making the request", "The client's capabilities for this specific request", "Servers MUST NOT infer capabilities from prior requests"). So per the type, a server sending tasks/list with a pagination cursor must fabricate the client's identity and capabilities — semantically nonsensical. Concrete SDK consequence: when the companion work adds per-request _meta injection to Protocol.request(), the server-side outbound path has no sensible value to put here.

Surface 3 — server-authored embedded ListRootsRequest payload

ListRootsRequest (line 2820) dropped extends JSONRPCRequest (it is now only an InputRequest payload embedded in server-emitted InputRequiredResult.inputRequests, per InputRequest = CreateMessageRequest | ListRootsRequest | ElicitRequest at line 438), but unlike its two siblings it kept params?: RequestParams (line 2822). The siblings were cleaned: CreateMessageRequestParams (line 2257) and ElicitRequestFormParams/ElicitRequestURLParams (lines 2880/2913) all dropped extends TaskAugmentedRequestParams, so they no longer reference RequestParams/_meta at all. ListRootsRequest was missed — likely because it had no dedicated *Params wrapper to edit. params? is optional so a server can omit it, but a server wanting to attach e.g. _meta.progressToken would be type-forced to also fabricate clientInfo/clientCapabilities/protocolVersion for a server-authored embedded payload.

Step-by-step proof

1. RequestMetaObject (lines 74-97) declares 'io.modelcontextprotocol/protocolVersion': string, '…/clientInfo': Implementation, '…/clientCapabilities': ClientCapabilities — none with ?.
2. RequestParams (line 145) declares _meta: RequestMetaObject — no ?.
3. PaginatedRequest (line 1014) declares params?: PaginatedRequestParams — with ?. PaginatedRequestParams extends RequestParams (line 1004).
4. ListToolsRequest extends PaginatedRequest → a client may send { jsonrpc:'2.0', id:1, method:'tools/list' } with no params → no _meta → no protocolVersion/clientInfo/clientCapabilities. Type-valid, but the JSDoc on each key says "Required."
5. ListTasksRequest extends PaginatedRequest and is a member of ServerRequest (line 3280). A server paginating tasks/list constructs params: { cursor: '…', _meta: { 'io.modelcontextprotocol/clientInfo': ???, 'io.modelcontextprotocol/clientCapabilities': ???, … } } — there is no value a server can sensibly put for the client's identity.
6. ListRootsRequest (line 2822) keeps params?: RequestParams, while CreateMessageRequest.params: CreateMessageRequestParams and ElicitRequest.params: ElicitRequestParams no longer extend RequestParams — ListRootsRequest is the odd one out among the three InputRequest members.

Impact

None of these independently break CI beyond what comment #3223937258 already documents (the SDK↔spec RequestParams assignability failure). They are upstream design gaps in the same tier as comments #3214351591 (taskId missing), #3214351594 (discriminant not narrowed), #3216586352 (tasks.requests orphaned), and #3216586357 (InputResponse no error arm) — they don't add new red CI, but they identify shapes the SDK should not encode as-is. In particular, the server-side Protocol.request() _meta-injection redesign called for in #3223937258 cannot follow the same logic as the client side while RequestMetaObject is client-direction-only.

How to fix

Raise upstream alongside the other schema.ts feedback. Plausible fixes (any one resolves all three surfaces, or they can be combined):

• Make the three io.modelcontextprotocol/* keys optional on RequestMetaObject (or split into ClientRequestMetaObject / ServerRequestMetaObject), and have client→server wire request types make params non-optional so the handshake metadata is actually carried.
• Have DiscoverRequest use a params type that does not extend RequestParams (or document an explicit exemption from the protocolVersion rejection rule for server/discover).
• Have server→client request params (concretely ListTasksRequest via PaginatedRequest) not extend RequestParams, or use a server-direction _meta shape.
• Change ListRootsRequest.params? to a bare { _meta?: MetaObject } or drop params entirely, matching CreateMessageRequest/ElicitRequest.

Then re-run pnpm run fetch:spec-types.

[claude]

🟡 🟡 The companion redesign also has transport-layer work in packages/{server,client}/src/**/streamableHttp.ts that none of the existing comments mention and that nothing in CI surfaces (those files don't import spec.types.ts — same silent class as the -32042 finding). (1) This JSDoc says subscriptions/listen "Replaces the previous HTTP GET endpoint" — the server transport still implements that endpoint (handleGetRequest / _standaloneSseStreamId='_GET_stream', streamableHttp.ts:234/358/404/433/937/964) and the client transport still opens a bare GET stream for unsolicited notifications (_startOrAuthSse, streamableHttp.ts:233/251/647) instead of issuing subscriptions/listen. (2) The new RequestMetaObject JSDoc (lines 77-80) and the UnsupportedProtocolVersionError/MissingRequiredClientCapabilityError JSDoc add three HTTP MUSTs — _meta protocolVersion MUST match the MCP-Protocol-Version header else 400, and both error envelopes MUST be HTTP 400 — but validateProtocolVersion() (streamableHttp.ts:889) checks only the header (never cross-checks body _meta), and Protocol-layer JSON-RPC errors flow through send() into a hardcoded HTTP 200 (lines 817/1022/1024) with no error-code→HTTP-status hook. The redesign needs to: route subscriptions/listen to the long-lived SSE stream (and decide GET back-compat vs 405); have the client transport send subscriptions/listen instead of opening GET; add header↔_meta cross-validation; and add a Protocol→transport hook so these two error envelopes surface as HTTP 400.

Extended reasoning...

What this finding covers

Two transport-layer normative changes in this sync land in JSDoc prose only and affect packages/server/src/server/streamableHttp.ts and packages/client/src/client/streamableHttp.ts. Neither file imports spec.types.ts, so — like the -32042 / UrlElicitationRequiredError finding (#3216586348) — there is zero CI signal: tsc, spec.types.test.ts, and the specTypeSchema allowlist guard all stay green for these files. None of the 13 existing PR comments mention streamableHttp.ts, the GET handler, or HTTP-status-code mapping; comments #3223937253/#3223937258 cover the schema/lifecycle/subscribeResource() side of subscriptions/listen, and #3231781722 covers its missing JSON-RPC result type, but the transport plumbing is a separate code path.

(1) GET standalone-SSE endpoint replaced by subscriptions/listen

The SubscriptionsListenRequest JSDoc (this line) explicitly says it "Replaces the previous HTTP GET endpoint and ensures consistent behavior between HTTP and STDIO." The Streamable HTTP transport implements that GET endpoint as core functionality:

• Server (packages/server/src/server/streamableHttp.ts): case 'GET' → handleGetRequest() at lines 358-359/404; the standalone notification stream is keyed by _standaloneSseStreamId = '_GET_stream' (line 234) with 409-conflict handling (line 433), close/cleanup (449/469), and the unsolicited-message send path / event-store replay routed through it (lines 937/964/967).
• Client (packages/client/src/client/streamableHttp.ts): _startOrAuthSse() issues method: 'GET' (lines 233/251) to open the unsolicited-notification stream, kicked off after notifications/initialized (line 647) and on resume (lines 535/756), with reconnect at 347.

After this sync the spec no longer defines a GET endpoint for the standalone notification stream; a spec-compliant server is not obligated to accept GET. The client transport already tolerates a 405 on GET (lines 285-288), so it would not crash against such a server — but it would silently degrade to never receiving any unsolicited server notifications, because nothing in the client transport sends subscriptions/listen. Conversely, the server transport has no path that routes an incoming subscriptions/listen JSON-RPC request to the long-lived SSE stream — the only way to open that stream is GET.

(2) New HTTP-400 MUSTs with no transport hook

This sync adds three HTTP-transport-specific MUST clauses in JSDoc:

• RequestMetaObject['io.modelcontextprotocol/protocolVersion'] (lines 77-80): "For the HTTP transport, this value MUST match the MCP-Protocol-Version header; otherwise the server MUST return a 400 Bad Request."
• UnsupportedProtocolVersionError (line ~383): "For HTTP, the response status code MUST be 400 Bad Request."
• MissingRequiredClientCapabilityError (line ~413): "For HTTP, the response status code MUST be 400 Bad Request."

The server transport's validateProtocolVersion() (streamableHttp.ts:889-898) reads the MCP-Protocol-Version header on every request and 400s if it's not in _supportedProtocolVersions, but it never cross-checks the header against the body params._meta['io.modelcontextprotocol/protocolVersion'] (which the SDK doesn't populate yet — that's the per-request _meta injection work in #3223937258). And Protocol-layer JSON-RPC errors generated by handlers flow back through the transport's send() into an already-opened HTTP 200 SSE/JSON body (lines 817/1022/1024) — there is no hook by which Protocol can tell the transport "this particular JSONRPCErrorResponse should be delivered as HTTP 400 instead of inside a 200." So once the redesign starts emitting UnsupportedProtocolVersionError (INVALID_PARAMS + data.supported/requested) or MissingRequiredClientCapabilityError (-32003), they will go out as HTTP 200, violating the new MUSTs.

Step-by-step proof

GET → subscriptions/listen:

1. Spec post-sync: SubscriptionsListenRequest JSDoc says it "Replaces the previous HTTP GET endpoint"; the GET endpoint is no longer part of the transport spec.
2. SDK client connects, completes handshake, and at streamableHttp.ts:647 calls _startOrAuthSse({}), which issues fetch(url, { method: 'GET', headers: { Accept: 'text/event-stream', … } }) (line 251).
3. A spec-compliant server with no GET handler returns 405. Client hits line 287 and silently returns — no error, no notification stream, no subscriptions/listen sent. The user's ToolListChangedNotification/ResourceUpdatedNotification handlers never fire.
4. Conversely, an SDK server receiving a POST { method: 'subscriptions/listen', … } would dispatch it through handlePostRequest → Protocol._onrequest like any RPC; nothing wires it to _standaloneSseStreamId, so unsolicited send() calls (line 937/967) still look up '_GET_stream' and find nothing.

HTTP-400 MUSTs:

1. After the redesign, client sends POST with header MCP-Protocol-Version: 2026-03-01 and body params._meta['io.modelcontextprotocol/protocolVersion'] = '2025-11-07'.
2. validateProtocolVersion() (line 889) reads only req.headers.get('mcp-protocol-version'), sees '2026-03-01' ∈ _supportedProtocolVersions, returns undefined. The header↔body mismatch is never checked → no 400, contrary to lines 77-80.
3. Separately, a tool handler determines the request needs elicitation but _meta.clientCapabilities.elicitation is absent, and (per the redesign) emits a MissingRequiredClientCapabilityError (code: -32003). Protocol serialises it and calls transport.send(errorResponse, { relatedRequestId }).
4. send() finds the pending stream for that request and either writes an SSE event into the already-200 stream or calls stream.resolveJson(Response.json(responses[0], { status: 200, … })) (lines 1022/1024). The -32003 error reaches the client inside an HTTP 200 body — violating the "MUST be 400" clause.

Why existing code doesn't prevent it

streamableHttp.ts (both packages) does not import spec.types.ts, so the drift guard / spec.types.test.ts cannot see this. The new requirements are JSDoc prose, not types, so even the bidirectional-assignability checks would not catch them. And the existing comments' remediation lists are scoped to schemas.ts/types.ts/client.ts/server.ts — a reviewer following only those could replace subscribeResource() with a subscriptions/listen API and add the two error-envelope schemas without ever touching the transport's GET handler or its hardcoded-200 send path.

Impact

This is forward-looking scoping for the companion redesign rather than an independent blocker (the SDK doesn't yet emit -32003 or populate _meta.protocolVersion, and keeping GET as a back-compat shim is a viable transitional state). But it identifies two non-obvious design decisions the redesign must make at the transport layer — (a) how subscriptions/listen is wired to the long-lived SSE stream and what happens to handleGetRequest, and (b) a new Protocol→transport hook to map specific JSON-RPC error envelopes to non-200 HTTP status — that someone doing pure schemas.ts/server.ts work would plausibly miss.

How to fix

In the companion redesign:

• Server transport: route method: 'subscriptions/listen' to the long-lived SSE stream (taking over the role of _standaloneSseStreamId/event-store replay); decide whether handleGetRequest stays as a back-compat shim or returns 405. Extend validateProtocolVersion() (or add a sibling) to compare the MCP-Protocol-Version header against body params._meta['io.modelcontextprotocol/protocolVersion'] and 400 on mismatch. Add an error-code→HTTP-status hook so send() (or the pre-stream path) can emit HTTP 400 when the outgoing JSONRPCErrorResponse is an UnsupportedProtocolVersionError (INVALID_PARAMS + data.supported/requested) or MissingRequiredClientCapabilityError (-32003).
• Client transport: replace _startOrAuthSse's bare GET with a POST subscriptions/listen carrying a SubscriptionFilter, and treat the resulting SSE stream (and SubscriptionsAcknowledgedNotification) as the unsolicited-notification channel; keep a GET fallback only if back-compat with pre-spec servers is desired.

[claude]

🟡 Upstream spec gap to batch with the other schema.ts feedback: ElicitationCompleteNotification (line 3243, "informing it of a completion of a out-of-band elicitation request") survives in ServerNotification (line 3291), but after this sync there is no spec-defined channel to deliver it. ElicitRequest is now only an InputRequest payload inside InputRequiredResult (so the originating request's stream is closed when the result arrives), and the standalone GET stream is replaced by subscriptions/listen — whose SubscriptionFilter is an explicit opt-in allowlist with only four fields (toolsListChanged/promptsListChanged/resourcesListChanged/resourceSubscriptions) and JSDoc saying the server "MUST NOT send notification types the client has not explicitly requested here." So per the spec's own MUST NOT, a server cannot push elicitation-complete on the only out-of-band channel; a client doing a URL-mode elicitation can only poll by blindly retrying. (TaskStatusNotification, also in ServerNotification and absent from SubscriptionFilter, arguably has the same gap.) Same tier as comments #9/#12/#13 — suggest upstream either add elicitationComplete?: boolean (and taskStatus?: boolean) to SubscriptionFilter, or remove ElicitationCompleteNotification from ServerNotification if poll-via-retry is the intended model.

Extended reasoning...

What the bug is

ElicitationCompleteNotification (spec.types.ts:3243, method notifications/elicitation/complete, JSDoc: "informing it of a completion of a out-of-band elicitation request") survives this diff and remains a member of ServerNotification (line 3291). But after the stateless overhaul there is no spec-defined channel on which a server can actually deliver it.

The pre-sync flow was: a server emitted URLElicitationRequiredError (-32042) or sent an ElicitRequest JSON-RPC; the client opened the URL in a browser; the server detected completion out-of-band and pushed ElicitationCompleteNotification on the standalone HTTP GET/SSE stream so the client knew when to retry.

Post-sync, both halves of that delivery path are gone:

• (a) ElicitRequest no longer extends JSONRPCRequest — it is only an InputRequest payload embedded inside InputRequiredResult (line 438). The InputRequiredResult is the terminal result of the originating tools/call/prompts/get/resources/read/tasks/result request, so that request's response stream is closed once the result is delivered. There is no still-open per-request stream to carry a later notification.
• (b) The standalone HTTP GET stream is replaced by subscriptions/listen (line 1223; its JSDoc at 1214-1216 says it "Replaces the previous HTTP GET endpoint"). That stream's SubscriptionFilter (lines 1179-1197) is a closed, explicit opt-in allowlist with exactly four fields — toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions — and the JSDoc at lines 1174-1175 (and again at 1206-1208) is normative: "Each notification type is opt-in; the server MUST NOT send notification types the client has not explicitly requested here." There is no field for elicitation-complete.

So per the spec's own MUST NOT, ElicitationCompleteNotification is undeliverable on the only out-of-request channel, and there is no in-request channel left. The notification type is in ServerNotification but unreachable.

Step-by-step proof

1. Client sends tools/call. Server returns CallToolResultResponse { result: InputRequiredResult { inputRequests: { 'e1': { method: 'elicitation/create', params: { mode: 'url', url: 'https://…', elicitationId: 'abc' } } } } }. The tools/call request is complete; its response stream closes.
2. Client opens https://… in a browser. The user completes the OAuth/consent flow there. The server learns this out-of-band (callback, webhook, etc.).
3. The server now wants to send { method: 'notifications/elicitation/complete', params: { elicitationId: 'abc' } } so the client knows to retry the tools/call with inputResponses.
4. Per-request stream: gone — the originating tools/call already returned in step 1.
5. subscriptions/listen stream: the client could only have requested { toolsListChanged?, promptsListChanged?, resourcesListChanged?, resourceSubscriptions? } — there is no elicitationComplete field in SubscriptionFilter. Per lines 1174-1175 the server "MUST NOT send notification types the client has not explicitly requested", so sending notifications/elicitation/complete on this stream violates the spec's own normative text.
6. There is no third channel. The client's only option is to poll: blindly retry tools/call (with requestState) on a timer until the server stops returning input_required.

Cross-checking the other ServerNotification members

This isn't a general "SubscriptionFilter is incomplete for everything" complaint — most ServerNotification members do have a defined channel:

Member	Delivery channel
CancelledNotification / ProgressNotification / LoggingMessageNotification	per-request stream (request-scoped)
SubscriptionsAcknowledgedNotification	first message on the subscriptions/listen stream itself
ResourceListChangedNotification / ResourceUpdatedNotification / ToolListChangedNotification / PromptListChangedNotification	subscriptions/listen, gated by the four SubscriptionFilter fields
ElicitationCompleteNotification	none — by definition out-of-band, no SubscriptionFilter field
TaskStatusNotification	arguably none — also absent from SubscriptionFilter; tasks at least have tasks/get polling as a documented fallback, whereas URL elicitation has none

ElicitationCompleteNotification is the clear odd-one-out (and TaskStatusNotification strengthens the case that the closed allowlist is incomplete rather than that elicitation-complete was intentionally dropped).

Why this is distinct from existing PR comments

None of comments #1-#13 mention ElicitationCompleteNotification. Comment #7 (#3216586348) covers the -32042/UrlElicitationRequiredError SDK-side removal (the error path), not this notification's reachability. Comments #11/#12 cover subscriptions/listen (the missing result wrapper and the new types needing schemas) but not the gap in SubscriptionFilter's allowlist. This is the same tier as #9 (InputResponse no error arm), #12 (SubscriptionsListenRequest no result), and #13 (RequestParams._meta direction mismatch): an upstream schema.ts self-inconsistency that doesn't independently break CI but identifies a shape the SDK should not encode as-is.

Impact

Doesn't independently break CI — ElicitationCompleteNotification itself is unchanged by the diff, so no assignability/coverage check trips on it specifically. But when the companion work adds SubscriptionFilterSchema to schemas.ts (per comment #10), encoding only the four fields bakes in a filter that can never permit elicitation-complete, and when it rewrites the URL-elicitation flow (per comments #1/#7) it will have no spec-defined replacement for the "server pushes when browser flow completes" signal. The SDK would have to either (a) ship a poll-on-timer client API, or (b) invent an off-spec extra SubscriptionFilter field — both break once upstream picks the real answer.

How to fix

Raise upstream alongside the other schema.ts feedback. Two options:

• Extend SubscriptionFilter: add elicitationComplete?: boolean (or elicitationIds?: string[] for per-elicitation granularity), and probably taskStatus?: boolean for symmetry. This keeps ElicitationCompleteNotification deliverable on the subscriptions/listen stream and matches the four existing list-changed fields.
• Remove ElicitationCompleteNotification from ServerNotification if poll-via-retry is the intended model — i.e., the client just re-issues the original request with requestState until resultType !== 'input_required'. In that case the notification type is dead and should be deleted alongside the other elicitation cleanup.

Then re-run pnpm run fetch:spec-types. Don't add SubscriptionFilterSchema to schemas.ts until this is settled. Filed as a nit because it doesn't add new red CI and poll-via-retry is a viable (if ugly) fallback — same tier as comments #5/#6/#8/#9/#12/#13.

[claude]

🟡 🟡 Upstream spec self-inconsistency to batch with the other schema.ts feedback (server-side analogue of comment #3216586352): the same diff that deletes SubscribeRequest/UnsubscribeRequest and makes all list-changed notifications opt-in via SubscriptionFilter leaves ServerCapabilities.resources.subscribe (line 776) and {prompts,resources,tools}.listChanged (755/780/795) untouched, and adds no capability flag for subscriptions/listen itself. The flags are not dead — each maps 1:1 to a SubscriptionFilter field — but their documented semantics have silently shifted from "server will push unsolicited *_list_changed" / "server accepts the resources/subscribe RPC" to "server will honor the corresponding SubscriptionFilter opt-in on a subscriptions/listen stream", and the JSDoc/@example references still describe the old model. Suggest upstream either re-document these four flags for the opt-in model or fold them into a structured subscriptions: { listen?, resourceSubscriptions?, …ListChanged? } capability so the SDK's subscriptions/listen client API (replacing the client.ts:599 gate) has an unambiguous flag to check.

Extended reasoning...

What the issue is

This sync replaces the per-resource resources/subscribe / resources/unsubscribe RPCs and unsolicited *_list_changed pushes with a single opt-in subscriptions/listen stream: the client sends a SubscriptionFilter naming which notification types it wants, and the server echoes back what it will honor in SubscriptionsAcknowledgedNotification.params.notifications (the JSDoc on SubscriptionFilter says the server "MUST NOT send notification types the client has not explicitly requested"). But ServerCapabilities — structurally untouched by this diff beyond the @category initialize → server/discover rename at line 721 — still declares:

• resources.subscribe?: boolean (line 776) — "Whether this server supports subscribing to resource updates"
• prompts.listChanged?: boolean / resources.listChanged?: boolean / tools.listChanged?: boolean (lines 755/780/795) — "Whether this server supports notifications for changes to the … list"

and adds no field advertising whether the server implements subscriptions/listen at all.

Addressing the "these flags map cleanly to SubscriptionFilter" objection

A reasonable counter-read is that these four flags are not orphaned: each corresponds 1:1 to a SubscriptionFilter field (resources.subscribe ↔ resourceSubscriptions, {prompts,resources,tools}.listChanged ↔ {prompts,resources,tools}ListChanged), the underlying notifications (ResourceUpdatedNotification, the three *ListChangedNotification types) all still exist in ServerNotification, and the JSDoc text on resources.subscribe ("subscribing to resource updates") is mechanism-agnostic. Under this reading, the static DiscoverResult.capabilities flags tell a client what to put in its SubscriptionFilter before opening a stream, and SubscriptionsAcknowledgedNotification confirms per-stream what was honored — two different purposes, not duplication. That counter-read is largely correct, and is why this is not the same as comment #3216586352's ClientCapabilities.tasks.requests case (where the advertised concept — task-augmented sampling/elicitation wire requests — was deleted entirely).

What that reading does not address is that the semantics of these flags changed without the spec saying so. Pre-sync, tools.listChanged: true meant "this server will send unsolicited notifications/tools/list_changed"; post-sync, per the SubscriptionFilter JSDoc, the server MUST NOT send that notification unless the client opts in on a subscriptions/listen stream — so the flag now means "this server will honor toolsListChanged: true in your filter." Pre-sync, resources.subscribe: true meant "this server accepts resources/subscribe requests" (and client.ts:599 gates on exactly that); post-sync, that RPC does not exist, so the flag must mean "this server will honor resourceSubscriptions: [...] in your filter." Neither shift is reflected in the JSDoc, and the @example {@includeCode ./examples/ServerCapabilities/resources-subscription-*.json} references (lines 763-770) still point at example files written for the old model. An implementer reading ServerCapabilities in isolation would reasonably conclude the server pushes list-changed notifications unprompted and accepts a resources/subscribe RPC — both now wrong.

Separately, there is no explicit capability for subscriptions/listen itself. Under the reinterpretation above, support is implied by any of the four sub-flags being present — but that is undocumented inference, and a server that implements subscriptions/listen for (say) LoggingMessageNotification only, with none of the four sub-flags, has no way to advertise the endpoint exists.

Step-by-step proof

1. Diff deletes SubscribeRequest / UnsubscribeRequest / SubscribeResultResponse / UnsubscribeResultResponse; ClientRequest (line 3256) no longer contains either.
2. Diff adds SubscriptionFilter (line 1176) with toolsListChanged? / promptsListChanged? / resourcesListChanged? / resourceSubscriptions?: string[] and JSDoc "the server MUST NOT send notification types the client has not explicitly requested here." SubscriptionFilter.resourceSubscriptions JSDoc (line 1194) explicitly says "Replaces the former resources/subscribe RPC."
3. ServerCapabilities body (lines 723-833) is byte-identical to pre-sync apart from the @category tag. resources.subscribe (776), prompts.listChanged (755), resources.listChanged (780), tools.listChanged (795) all survive with pre-sync JSDoc. Grep for subscriptions under ServerCapabilities → no match.
4. Pre-sync semantics of prompts.listChanged: true: server will send notifications/prompts/list_changed whenever its prompt set changes (no client opt-in required). Post-sync semantics per step 2: server MUST NOT send it unless the client included promptsListChanged: true in a subscriptions/listen filter. The JSDoc at line 753 still reads "Whether this server supports notifications for changes to the prompt list" — silent on the new opt-in requirement.
5. SDK surface: packages/client/src/client/client.ts:599 does if (method === 'resources/subscribe' && !this._serverCapabilities.resources.subscribe) throw …. After the redesign already requested in comment #3223937258 that branch is removed, and the new subscriptions/listen client API will need a capability gate — under the current spec it must either reuse resources.subscribe/*.listChanged under their reinterpreted meaning, or ship ungated.

Why this is distinct from existing PR comments

Comment #3216586352 covers the client-side mirror (ClientCapabilities.tasks.requests orphaned by InputRequiredResult). Comment #3223937258 covers the SDK lifecycle redesign, including replacing subscribeResource()/unsubscribeResource() — but that comment is about what the SDK must change, not about the upstream schema.ts leaving ServerCapabilities documenting the old subscription model. Comment #3231781722 covers SubscriptionsListenRequest lacking a JSON-RPC response wrapper. None of #1-#13 mention ServerCapabilities.resources.subscribe / *.listChanged or a missing subscriptions capability.

Impact

No independent CI breakage — all four fields are optional, the ServerCapabilities body is untouched, so spec.types.test.ts's bidirectional check for ServerCapabilities still passes. This is upstream documentation/modeling feedback in the same tier as #3214351593 (JSDoc), #3216586352 (tasks.requests), #3231781731 (RequestParams direction). Filed as nit.

How to fix

Raise upstream alongside the other schema.ts feedback. Two coherent options:

• Re-document in place: keep the four flags, update their JSDoc to reference SubscriptionFilter (e.g., resources.subscribe → "Whether this server will honor resourceSubscriptions on a subscriptions/listen stream"; *.listChanged → "Whether this server will honor *ListChanged on a subscriptions/listen stream"), and refresh the @example JSON files. Optionally add a top-level subscriptions?: JSONObject to advertise the endpoint independently of which filter fields are honored.
• Restructure: replace the four scattered flags with subscriptions?: { listen?: JSONObject; resourceSubscriptions?: boolean; toolsListChanged?: boolean; promptsListChanged?: boolean; resourcesListChanged?: boolean } so the capability shape mirrors SubscriptionFilter.

Then re-run pnpm run fetch:spec-types. Once re-pulled, ServerCapabilitiesSchema in schemas.ts and the client.ts capability gate for the new subscriptions/listen API can follow whichever shape upstream picks.

[claude]

🔴 Another silent transport-layer divergence (same class as #3216586348/#3239359153, distinct surface): the Streamable HTTP server transport's entire Mcp-Session-Id lifecycle is hard-keyed on isInitializeRequest() (packages/server/src/server/streamableHttp.ts:666) — sessionId minting (678), _initialized = true (679), and the public onsessioninitialized hook (683-684) only fire for method: 'initialize'; any other first request hits validateSession() and 400s "Server not initialized" in stateful mode (847-856). After this sync InitializeRequest is gone — a spec-compliant client sends server/discover or just tools/list-with-_meta and never initialize, so a stateful SDK HTTP server 400s every request and never establishes a session. Lines 720-722 also read the deleted initRequest.params.protocolVersion (version now lives in _meta['io.modelcontextprotocol/protocolVersion']). And grepping post-sync spec.types.ts for "session" returns zero matches — the stateless overhaul appears to have dropped Mcp-Session-Id semantics entirely, so the redesign must explicitly decide remove-sessions vs. mint-on-first-request vs. re-key-on-server/discover, and update the public isInitializeRequest guard (guards.ts:93, exports/public/index.ts:111) and sessionIdGenerator/onsessioninitialized/onsessionclosed transport options (streamableHttp.ts:80/89/101) accordingly.

Extended reasoning...

What this finding covers

The Streamable HTTP server transport's session-ID bootstrap is hard-wired to the deleted initialize method, and the post-sync spec appears to have dropped Mcp-Session-Id session semantics entirely. This is a third silent transport-layer divergence in packages/server/src/server/streamableHttp.ts that neither comment #3223937258 (Protocol-layer server.ts/client.ts initialize handling) nor comment #3239359153 (streamableHttp.ts GET→subscriptions/listen + HTTP-400 MUSTs) covers.

The code path

handlePostRequest in packages/server/src/server/streamableHttp.ts:

• Line 666: const isInitializationRequest = messages.some(element => isInitializeRequest(element)) — isInitializeRequest (guards.ts:93) checks for method: 'initialize'.
• Lines 667-685 (the if (isInitializationRequest) block): this.sessionId = this.sessionIdGenerator?.() (678), this._initialized = true (679), and await this._onsessioninitialized(this.sessionId) (683-684). This is the only place sessionId is minted and _initialized is flipped.
• Lines 687-694 (the else path): every non-initialize POST goes through validateSession(req).
• validateSession() (847-856): in stateful mode (sessionIdGenerator set), if (!this._initialized) → return this.createJsonErrorResponse(400, -32_000, 'Bad Request: Server not initialized').
• Lines 720-722: const initRequest = messages.find(m => isInitializeRequest(m)); const clientProtocolVersion = initRequest ? initRequest.params.protocolVersion : … — reads params.protocolVersion, a field of the deleted InitializeRequestParams. In the new model the protocol version lives in params._meta['io.modelcontextprotocol/protocolVersion'].

Why nothing in CI surfaces it

streamableHttp.ts imports isInitializeRequest from @modelcontextprotocol/core (guards.ts), not from spec.types.ts. InitializeRequestSchema still exists in schemas.ts, so guards.ts still typechecks; the transport never references spec.types.ts at all. Neither tsc --noEmit, spec.types.test.ts, nor the specTypeSchema allowlist guard sees this — same silent class as #3216586348 (-32042) and #3239359153 (GET endpoint).

Step-by-step proof

1. User constructs the documented stateful server: new StreamableHTTPServerTransport({ sessionIdGenerator: () => crypto.randomUUID(), onsessioninitialized: id => sessions.set(id, …) }) (per the JSDoc example at streamableHttp.ts:195).
2. A spec-compliant client built against the post-sync schema connects. Per this diff there is no initialize method; the client either sends { method: 'server/discover' } first or goes straight to { method: 'tools/list', params: { _meta: { 'io.modelcontextprotocol/protocolVersion': …, 'io.modelcontextprotocol/clientInfo': …, 'io.modelcontextprotocol/clientCapabilities': … } } }.
3. handlePostRequest parses the body. isInitializeRequest({ method: 'server/discover', … }) → false (it checks for 'initialize'). isInitializationRequest = false.
4. Control falls to line 687-691 → validateSession(req). sessionIdGenerator is set, this._initialized is still false (never flipped) → returns 400 "Bad Request: Server not initialized".
5. The client retries; same result. No request ever succeeds, sessionId is never minted, onsessioninitialized never fires, the user's session map stays empty.
6. Separately, even if a legacy client sent initialize, line 722 reads initRequest.params.protocolVersion — fine for legacy clients, but once the redesign re-keys the bootstrap on server/discover (whose params?: RequestParams has no protocolVersion field), this read returns undefined and the priming-event protocol-version logic silently picks the wrong branch.

The bigger design question

grep -i session packages/core/src/types/spec.types.ts post-sync → zero matches. The stateless overhaul has apparently dropped Mcp-Session-Id from the protocol entirely (consistent with "every request carries its own _meta handshake"). That means the SDK's public stateful-mode surface — sessionIdGenerator (line 80), onsessioninitialized (89), onsessionclosed (101), the Mcp-Session-Id header read at 859, the DELETE-ends-session path at 838, plus the four middleware READMEs and streamableHttp.examples.ts that demonstrate per-session transport maps keyed on isInitializeRequest — is now unanchored from the spec. The redesign must explicitly choose one of:

• (a) Remove sessions from the transport (stateful mode goes away; sessionIdGenerator/onsessioninitialized/onsessionclosed deprecated → breaking change, migration.md entry).
• (b) Mint on first request regardless of method (re-key the bootstrap on "first POST without Mcp-Session-Id header" instead of "is initialize").
• (c) Re-key on server/discover (closest 1:1 swap, but server/discover is optional per its JSDoc, so clients that skip it would still 400).

Whichever is chosen, the public isInitializeRequest guard (re-exported at exports/public/index.ts:111, used verbatim in the four middleware READMEs and streamableHttp.examples.ts for per-session routing) needs deprecation or replacement, and lines 720-722 need to read _meta['io.modelcontextprotocol/protocolVersion'] instead of params.protocolVersion.

Why this is distinct from existing comments

• #3223937258 (stateless overhaul) is scoped to the Protocol layer: client.connect() sending initialize, server.ts registering an initialize handler / assertInitialized() gating, and the schemas/guards cleanup. Its remediation list never mentions the transport's isInitializeRequest-gated session bootstrap, sessionIdGenerator, _initialized, onsessioninitialized, validateSession(), or the Mcp-Session-Id lifecycle.
• #3239359153 is the only existing comment touching streamableHttp.ts, and it covers exactly two things: (1) GET→subscriptions/listen (handleGetRequest/_standaloneSseStreamId) and (2) the new HTTP-400 MUSTs (validateProtocolVersion() header↔body cross-check, error-code→status hook). It does not mention the session-ID bootstrap path, isInitializationRequest, or the params.protocolVersion read at 720-722.

A reviewer following only those two comments would rip out assertInitialized() in server.ts and rewire the GET handler — and still ship a stateful HTTP transport that 400s every request from a spec-compliant client.

How to fix

Add to the companion-redesign scope:

• Decide (a)/(b)/(c) above for the Mcp-Session-Id lifecycle and update streamableHttp.ts:664-700 + validateSession() accordingly.
• Replace the initRequest.params.protocolVersion read (720-722) with params._meta['io.modelcontextprotocol/protocolVersion'] (or the header, since the bootstrap branch will no longer be exempt from header validation).
• Deprecate or repurpose isInitializeRequest (guards.ts:93, public re-export at exports/public/index.ts:111) and update packages/middleware/{node,hono,fastify,express}/README.md + streamableHttp.examples.ts which use it for per-session transport routing.
• If sessions are removed, deprecate sessionIdGenerator/onsessioninitialized/onsessionclosed (breaking → changeset + migration.md).

[claude]

🟡 Nit (upstream): the JSDoc on ResourceListChangedNotification (line 1158), PromptListChangedNotification (1602), and ToolListChangedNotification (1741) still say "This may be issued by servers without any previous subscription from the client", which now directly contradicts the new SubscriptionFilter JSDoc here ("the server MUST NOT send notification types the client has not explicitly requested"). The same diff did update ResourceUpdatedNotification's JSDoc (line 1277) to the opt-in wording, so this looks like a partial migration that missed the three *ListChanged siblings — worth replacing the offending sentence on all three with wording mirroring the updated ResourceUpdatedNotification text and re-pulling. (Distinct from comment #3239359160, which covers the stale ServerCapabilities.{*.listChanged,resources.subscribe} JSDoc, and from #3239359156, which covers SubscriptionFilter's allowlist gaps.)

Extended reasoning...

What the issue is

Three notification-type JSDoc blocks — all untouched by this diff — still describe the pre-opt-in delivery model:

• ResourceListChangedNotification (spec.types.ts:1158): "This may be issued by servers without any previous subscription from the client."
• PromptListChangedNotification (spec.types.ts:1602): identical sentence.
• ToolListChangedNotification (spec.types.ts:1741): identical sentence.

The new SubscriptionFilter JSDoc introduced by this same sync (lines 1174-1175, repeated at 1206-1208 on SubscriptionsListenRequestParams.notifications) is normative the opposite way: "Each notification type is opt-in; the server MUST NOT send notification types the client has not explicitly requested here." And SubscriptionFilter explicitly enumerates toolsListChanged / promptsListChanged / resourcesListChanged as the gates for exactly these three notifications. So the spec file now contains a direct internal contradiction: the type-level JSDoc says "may be issued without any previous subscription"; the channel-level JSDoc says "MUST NOT be sent unless explicitly subscribed."

Why this is a partial-migration slip, not intentional

This is not a case of the upstream author leaving older prose alone wholesale. The same diff hunk did update the fourth sibling, ResourceUpdatedNotification (spec.types.ts:1277), from:

"This should only be sent if the client previously sent a resources/subscribe request."

to:

"This is only sent for resources the client opted in to via the resourceSubscriptions field of a subscriptions/listen request."

So the upstream author migrated one of four notification descriptions to the new opt-in model and missed the other three. A grep for "may be issued by servers without any previous subscription" finds exactly three surviving instances — the classic partial-migration signature.

Step-by-step proof

1. After this sync, the only out-of-request channel for unsolicited server notifications is subscriptions/listen (line 1223; its JSDoc at 1214-1216 says it "Replaces the previous HTTP GET endpoint").
2. SubscriptionsListenRequestParams.notifications: SubscriptionFilter (line 1209) is the opt-in selector; the JSDoc at 1174-1175 says the server "MUST NOT send notification types the client has not explicitly requested here."
3. SubscriptionFilter.toolsListChanged (line 1182) gates notifications/tools/list_changed; .promptsListChanged (1186) gates notifications/prompts/list_changed; .resourcesListChanged (1190) gates notifications/resources/list_changed.
4. Therefore, per the spec's own MUST NOT, none of these three notifications can be "issued by servers without any previous subscription from the client." The sentence at lines 1158/1602/1741 is now affirmatively wrong, not merely stale.
5. An implementer hovering ToolListChangedNotification in their IDE sees only the type's own JSDoc — "may be issued without any previous subscription" — and would reasonably build a server that pushes it unprompted, violating the new MUST NOT.

Why this is distinct from the existing PR comments

• Comment #3239359160 covers stale ServerCapabilities.{prompts,resources,tools}.listChanged / resources.subscribe JSDoc (lines 755/776/780/795) — different location, different fix (capability-flag semantics vs. notification-type delivery semantics).
• Comment #3239359156 covers SubscriptionFilter's allowlist being incomplete for ElicitationCompleteNotification / TaskStatusNotification — about missing filter fields, not about contradictory prose on the three notifications that do have filter fields.
• None of the 16 prior comments mention lines 1158/1602/1741 or the "may be issued … without any previous subscription" sentence.

Impact

Same tier as comments #3214351593 (JSDoc /* vs /**) and #3239359160 — pure upstream prose, no CI/type impact, spec.types.ts is not re-exported from this package. Filed as a nit to fold into the same upstream schema.ts batch already on the table.

How to fix

In upstream schema.ts, replace "This may be issued by servers without any previous subscription from the client." on all three with wording mirroring the already-updated ResourceUpdatedNotification JSDoc, e.g.:

• ResourceListChangedNotification: "This is only sent if the client opted in via the resourcesListChanged field of a {@link SubscriptionsListenRequest | subscriptions/listen} request."
• PromptListChangedNotification: "…via the promptsListChanged field…"
• ToolListChangedNotification: "…via the toolsListChanged field…"

Then re-run pnpm run fetch:spec-types. No change is appropriate in this repo directly (the file header says DO NOT EDIT).

[claude]

🟡 Upstream spec self-inconsistency, materially broader than #3216586352: after this sync CallToolRequestParams is the only remaining extends TaskAugmentedRequestParams (client→server only), so no server→client message can carry params.task and the client's task store is unpopulatable — yet ServerRequest (this line) is now exclusively GetTaskRequest | GetTaskPayloadRequest | ListTasksRequest | CancelTaskRequest, all of which query that store. The entire ServerRequest union, the four task arms of ClientResult (3276), TaskStatusNotification ∈ ClientNotification (3273), and ClientCapabilities.tasks.{list,cancel} (678/682) are therefore unreachable, and the SDK's matching silent public surface — ClientTasksCapabilityWithRuntime (client.ts:148), the capabilities.tasks.{taskStore,taskMessageQueue,…} constructor handling (client.ts:249/256-260), and packages/client/src/experimental/tasks/client.ts — becomes dead with no CI signal. Following #3216586352's fix ("drop tasks.requests.{sampling,elicitation}") would leave all of this in place; suggest upstream either drop client-side tasks entirely (ClientCapabilities.tasks, the four ServerRequest members, the four ClientResult arms, TaskStatusNotification from ClientNotification) or restore a client-side task creation path, after which the SDK can prune the client TaskManager wiring.

Extended reasoning...

What the bug is

After this sync, CallToolRequestParams is the sole remaining extends TaskAugmentedRequestParams in the file (spec.types.ts:1716; grep confirms exactly two hits — the definition at line 127 and the one usage at 1716). CallToolRequest is client→server only (∈ ClientRequest, line 3264). The three server→client param types that previously carried task?: TaskMetadata — CreateMessageRequestParams (2257), ElicitRequestFormParams (2880), ElicitRequestURLParams (2913) — all dropped extends TaskAugmentedRequestParams in this diff, and per comment #3206453743 their requests are no longer wire requests at all. So no server→client message can create a client-side task.

But the spec leaves the entire client-side task consumption surface in place:

• ServerRequest (line 3280) = GetTaskRequest | GetTaskPayloadRequest | ListTasksRequest | CancelTaskRequest — every member queries a client-side task store by taskId. With no way to populate that store, the entire ServerRequest union is unreachable. (Comment #3223937258 notes that PingRequest/CreateMessageRequest/ElicitRequest/ListRootsRequest were removed from ServerRequest; it does not note that what remains is dead.)
• ClientResult (line 3276) = EmptyResult | GetTaskResult | GetTaskPayloadResult | ListTasksResult | CancelTaskResult — the four task arms are unreachable for the same reason; only EmptyResult survives, and nothing in ServerRequest returns it.
• TaskStatusNotification ∈ ClientNotification (line 3273) — a client notifying the server of a client-side task's status change; unreachable.
• ClientCapabilities.tasks.{list, cancel} (lines 678/682) — advertise that the client answers tasks/list/tasks/cancel; orphaned. (Comment #3216586352 covers only the nested .requests.{sampling,elicitation} sub-object.)

SDK surface affected (silent — same class as comments #3216586348/#3239359153)

The SDK ships a full client-side task store/manager that nothing in CI ties to spec.types.ts:

• packages/client/src/client/client.ts:148 — ClientTasksCapabilityWithRuntime = NonNullable<ClientCapabilities['tasks']> & TaskManagerOptions, the public option type for configuring a client-side task store.
• client.ts:249 — super({ ..., tasks: extractTaskManagerOptions(options?.capabilities?.tasks) }) wires a TaskManager into the client's Protocol base.
• client.ts:256-260 — strips taskStore/taskMessageQueue/defaultTaskPollInterval/maxTaskQueueSize from the wire-advertised tasks capability.
• packages/client/src/experimental/tasks/client.ts — the public client-side task façade.

None of these import spec.types.ts, so neither tsc nor spec.types.test.ts flags them. After this sync, all of it is dead protocol surface: a server has no spec-defined way to put a task into the client's store, so it has nothing to query.

Step-by-step proof

1. Pre-sync: server sends { method: 'sampling/createMessage', params: { task: {...}, messages: [...] } } (valid because CreateMessageRequestParams extends TaskAugmentedRequestParams). Client's TaskManager creates a task and stores it. Server later sends { method: 'tasks/get', params: { taskId } } (valid because GetTaskRequest ∈ ServerRequest). Client responds with GetTaskResult ∈ ClientResult.
2. Post-sync: CreateMessageRequestParams (line 2257) has no extends clause → no task field. CreateMessageRequest (line 2326) drops extends JSONRPCRequest → not a wire request. Same for ElicitRequest. There is no server→client request type whose params extend TaskAugmentedRequestParams (grep: only definition + CallToolRequestParams).
3. Therefore the client's task store is always empty.
4. Therefore every member of ServerRequest (line 3280) would return not-found / empty-list, and every task arm of ClientResult (line 3276) is unreachable. TaskStatusNotification ∈ ClientNotification (line 3273) is never sent.
5. SDK consequence: new Client({ capabilities: { tasks: { taskStore: new InMemoryTaskStore(), list: {}, cancel: {} } } }) — the documented pattern — configures a store that nothing can populate, and registers handlers for tasks/get/tasks/list/tasks/cancel that no spec-compliant server can meaningfully invoke.

Why this is distinct from existing PR comments

• #3216586352 (tasks.requests orphaned): same root cause, but scoped to ClientCapabilities.tasks.requests.{sampling,elicitation} and the assertClientRequestTaskCapability switch arms. Its "How to fix" says "drop tasks.requests.{sampling,elicitation}" — a reviewer following only that would leave ServerRequest, the ClientResult task arms, TaskStatusNotification ∈ ClientNotification, tasks.{list,cancel}, ClientTasksCapabilityWithRuntime, the client.ts:247-260 constructor handling, and experimental/tasks/client.ts all in place. This finding is the broader superset.
• #3206453743 / #3223937258: cover what was removed from ServerRequest/ClientResult; neither observes that what remains is unreachable.
• #3231781731: discusses ListTasksRequest ∈ ServerRequest inheriting client-direction _meta keys, treating the request as still meaningful — this finding shows it (and the whole union) is dead.

Impact

No independent CI breakage beyond what #3223937258 already documents — the client-side task store is dead-but-harmless (configuring it is a no-op, not a misbehavior, unlike #3216586348's -32042 which actively emits non-spec wire traffic). But it identifies a much larger pruning target than #3216586352 for both upstream schema.ts and the SDK companion work, and it flags silent SDK public surface (ClientTasksCapabilityWithRuntime, the capabilities.tasks.{taskStore,...} constructor options, experimental/tasks/client.ts) that the drift guard cannot catch.

How to fix

Raise upstream alongside #3216586352. Two coherent options:

• Remove client-side tasks entirely: drop ClientCapabilities.tasks (the whole object, not just .requests); drop the four task members from ServerRequest (leaving it empty / never until a real server→client request exists); drop the four *TaskResult arms from ClientResult; drop TaskStatusNotification from ClientNotification. Then in the SDK companion work: remove ClientTasksCapabilityWithRuntime, the capabilities.tasks constructor handling at client.ts:247-260, and packages/client/src/experimental/tasks/client.ts.
• Or restore a client-side task creation path (e.g., a server→client task-augmentable wire request) — but that contradicts the InputRequiredResult redesign's stateless intent.

Then re-run pnpm run fetch:spec-types. Filed at the same tier as #3216586352/#3231781731/#3239359156/#3239359160 (upstream-spec self-inconsistency, no independent CI red).

[claude]

🟡 🟡 Upstream design gap to batch with the other schema.ts feedback (response-side sibling of the missing-taskId finding on this same block): TaskInputResponseResultResponse.result is bare Result — the only one of the 15 *ResultResponse interfaces in this file whose result is not narrowed to a concrete XxxResult or XxxResult | InputRequiredResult union, so the redeclaration is a no-op over JSONRPCResultResponse.result and conveys nothing about what the server actually returns after tasks/input_response. Three plausible answers — EmptyResult (ack-only; client resumes polling tasks/get), a Task-shaped result (updated metadata, like CancelTaskResult), or GetTaskPayloadResult | InputRequiredResult (the task ran synchronously to the next checkpoint) — and the SDK's companion TaskInputResponseResultResponseSchema will have to guess, becoming public API that breaks once upstream specifies. Suggest upstream narrow to a concrete type (likely EmptyResult, or reuse GetTaskPayloadResult | InputRequiredResult if tasks/input_response is meant to synchronously continue the task) before the SDK encodes it.

Extended reasoning...

What the issue is

TaskInputResponseResultResponse (spec.types.ts:2115-2117) is declared as:

export interface TaskInputResponseResultResponse extends JSONRPCResultResponse {
    result: Result;
}

The result field is the bare base Result type. JSONRPCResultResponse.result (line 252) is already Result, so this redeclaration adds zero information — the wrapper exists but says nothing about what the server returns after a client sends tasks/input_response.

Why this is uniquely inconsistent

Enumerating every extends JSONRPCResultResponse in the file gives 15 concrete *ResultResponse interfaces. All 14 others narrow result to either a concrete subtype or an XxxResult | InputRequiredResult union:

Wrapper	result
DiscoverResultResponse	DiscoverResult
ListResourcesResultResponse	ListResourcesResult
ListResourceTemplatesResultResponse	ListResourceTemplatesResult
ReadResourceResultResponse	ReadResourceResult | InputRequiredResult
ListPromptsResultResponse	ListPromptsResult
GetPromptResultResponse	GetPromptResult | InputRequiredResult
ListToolsResultResponse	ListToolsResult
CallToolResultResponse	CallToolResult | InputRequiredResult
CreateTaskResultResponse	CreateTaskResult
GetTaskResultResponse	GetTaskResult
GetTaskPayloadResultResponse	GetTaskPayloadResult | InputRequiredResult
CancelTaskResultResponse	CancelTaskResult
ListTasksResultResponse	ListTasksResult
CompleteResultResponse	CompleteResult
TaskInputResponseResultResponse	Result ← only un-narrowed one

The pre-sync convention for ack-only responses (the now-deleted PingResultResponse, SubscribeResultResponse, UnsubscribeResultResponse, SetLevelResultResponse) was result: EmptyResult, not bare Result — so even if the intended semantics here are "just an ack", writing Result is at minimum inconsistent with the file's own convention.

The substantive ambiguity

The bare Result admits at least three mutually-incompatible interpretations of what tasks/input_response returns:

• (a) EmptyResult — the server just acknowledges receipt of the input responses; the client should resume polling tasks/get / tasks/result to learn whether the task progressed.
• (b) A Task-shaped result — like CancelTaskResult / GetTaskResult, the server returns the updated task metadata (new status, etc.) so the client knows immediately whether to poll again or fetch the payload.
• (c) GetTaskPayloadResult | InputRequiredResult — tasks/input_response synchronously continues the task to the next checkpoint and returns either the final payload or the next round of input requests, exactly like GetTaskPayloadResultResponse.

Note that since base Result now carries resultType: 'complete' | 'input_required', result: Result technically permits an InputRequiredResult-shaped object — but without typing it as such the client has no static guarantee inputRequests/requestState are present, and (per comment #3214351594) cannot discriminate on resultType anyway.

"Intentional polymorphism because the wrapped task is arbitrary" was considered and rejected: GetTaskPayloadResult already exists for exactly that polymorphic case, and GetTaskPayloadResultResponse narrows to GetTaskPayloadResult | InputRequiredResult. If tasks/input_response were meant to synchronously continue the task, it would use the same narrowing. Bare Result looks like an oversight consistent with the other defects already noted in this same block (missing taskId, InputResponse no error arm).

Step-by-step proof

1. Client has a task in status: 'input_required'. It calls tasks/result → server returns GetTaskPayloadResultResponse { result: InputRequiredResult { inputRequests: { 'r1': <ElicitRequest> } } }.
2. Client fulfils the elicitation and sends { method: 'tasks/input_response', params: { inputResponses: { 'r1': <ElicitResult> } } }.
3. Server replies { jsonrpc: '2.0', id: N, result: ??? }. Per TaskInputResponseResultResponse, result is anything assignable to Result — { resultType: 'complete' }, { resultType: 'complete', task: {...} }, { resultType: 'input_required', inputRequests: {...} }, or a full GetTaskPayloadResult are all type-valid.
4. The SDK's companion work (per comment #3206453749) must add TaskInputResponseResultResponseSchema to schemas.ts and a client.sendTaskInputResponse() (or equivalent) that calls Protocol.request(req, <resultSchema>). There is no spec-defined <resultSchema> to use. Whichever of (a)/(b)/(c) the SDK picks becomes public API: the inferred return type of the client method, the entry in specTypeSchemas, and the bidirectional check in spec.types.test.ts all encode that guess.
5. When upstream later narrows result to a concrete type, any guess that doesn't match becomes a breaking change.

Why this is distinct from the existing PR comments

• Comment #3206453749 lists TaskInputResponseResultResponse only as one of 10 types that "need a schema" — it does not note that the result type is uniquely un-narrowed and that the schema author has to guess the semantics.
• Comment #3214351591 covers TaskInputResponseRequestParams missing taskId — the request side of tasks/input_response. This finding is the response side of the same method.
• Comment #3231781722 covers SubscriptionsListenRequest having no result wrapper at all. This wrapper exists but is a no-op.

Impact

Doesn't independently break CI — Result is the base of JSONRPCResultResponse.result, so assignability holds and the drift guard would be satisfied by ResultSchema. One mitigating factor: since EmptyResult = Result (line 435), if upstream later narrows to EmptyResult an SDK that used ResultSchema is still spec-exact and nothing breaks. So this is weaker than the missing-taskId finding (which makes the request unroutable) — hence nit — but it is still worth raising upstream so the SDK doesn't have to guess between (a)/(b)/(c) when wiring client.sendTaskInputResponse().

How to fix

Raise upstream alongside the taskId (#3214351591), InputResponse error-arm (#3216586357), and discriminant-narrowing (#3214351594) feedback: narrow result to a concrete type — most likely EmptyResult (matching the deleted SubscribeResultResponse/SetLevelResultResponse ack-only convention), or reuse GetTaskPayloadResult | InputRequiredResult if tasks/input_response is meant to synchronously continue the task to the next checkpoint. Then re-run pnpm run fetch:spec-types. Until settled, the safest SDK encoding is ResultSchema (spec-exact and forward-compatible with EmptyResult), but don't expose a typed convenience method that commits to (b) or (c).