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.

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.)

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.

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.

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.

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).

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.

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:

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.

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.

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.

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.

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.

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:

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.

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.

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).

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).

What changed in c47bd846

The latest cron force-push layers a third wholesale architectural removal on top of the two already documented (Multi-Round-Trip in #3206453743/#3206453749, stateless handshake in #3223937258): the entire tasks subsystem is deleted from the protocol. The diff removes the full /* Tasks */ block (~280 lines, ~24 exports): TaskAugmentedRequestParams, TaskStatus, TaskMetadata, RelatedTaskMetadata, Task, CreateTaskResult/CreateTaskResultResponse, GetTaskRequest/GetTaskResult/GetTaskResultResponse, GetTaskPayloadRequest/GetTaskPayloadResult/GetTaskPayloadResultResponse, CancelTaskRequest/CancelTaskResult/CancelTaskResultResponse, ListTasksRequest/ListTasksResult/ListTasksResultResponse, TaskStatusNotification/TaskStatusNotificationParams, ToolExecution, plus Tool.execution, ServerCapabilities.tasks, ClientCapabilities.tasks, the InvalidParamsError Tasks JSDoc bullet, and the CancelledNotification task-related JSDoc. CallToolRequestParams now extends InputResponseRequestParams instead of TaskAugmentedRequestParams. Most consequentially, export type ServerRequest is deleted with no replacement — the /* Server messages */ block now contains only ServerNotification and ServerResult; the protocol defines no server→client JSON-RPC requests at all, and ClientResult collapses to bare EmptyResult.

Existing comments are now stale

This supersedes or obsoletes four existing PR comments that were written against the prior revision where task types still existed:

• #3214351591 (TaskInputResponseRequestParams lacks taskId) — that type no longer exists.
• #3216586352 (ClientCapabilities.tasks.requests orphaned) — ClientCapabilities.tasks is gone entirely.
• #3246176908 (ServerRequest is exclusively task members → unreachable) — written assuming ServerRequest still exists; it has now been deleted, which is the more aggressive resolution upstream chose.
• #3246176911 (TaskInputResponseResultResponse.result un-narrowed) — that type no longer exists.
• #3206453749's list of "10 Multi Round-Trip types" includes 3 TaskInputResponse* types that never landed in c47bd846.

None of the 20 existing comments say "the entire tasks subsystem is deleted", "ServerRequest itself is removed", "ToolExecution/Tool.execution is removed", or "the experimental/tasks package surface needs deprecation". Comment #3223937258 explicitly describes ServerRequest as "rewritten" to drop PingRequest while keeping the four task members — that description is now wrong.

Immediate CI breakage (beyond what existing comments document)

packages/core/test/spec.types.test.ts hard-references SpecTypes.ServerRequest (~line 499), SpecTypes.ToolExecution (559/899), SpecTypes.TaskStatus (563), SpecTypes.TaskMetadata (567/900), SpecTypes.Task (575/902), SpecTypes.CreateTaskResult (579/903/1008), SpecTypes.GetTaskRequest (607/979), SpecTypes.TaskStatusNotification[Params] (615/619/909/949), SpecTypes.CreateTaskResultResponse (718), and the rest of the GetTask*/ListTasks*/CancelTask*/GetTaskPayload* family — each is an unconditional TS2694: Namespace has no exported member error (~24 additional, on top of those already documented). The hardcoded toHaveLength(176) is now off by an additional ~−24 on the subtractive side. And the ClientRequest/ClientNotification/ServerResult bidirectional checks fail in new ways because the spec dropped GetTaskRequest|GetTaskPayloadRequest|ListTasksRequest|CancelTaskRequest from ClientRequest, TaskStatusNotification from ClientNotification/ServerNotification, and CreateTaskResult|GetTaskResult|GetTaskPayloadResult|ListTasksResult|CancelTaskResult from ServerResult.

Silent SDK divergence (no CI signal — same class as #3216586348/#3239359153/#3246176899)

The SDK ships tasks as public experimental API with no compile-time link to spec.types.ts:

• 9 files under packages/{core,client,server}/src/experimental/tasks/** — TaskManager, InMemoryTaskStore, helpers, server/client task façades.
• schemas.ts: TaskMetadataSchema (45), RelatedTaskMetadataSchema (53), TaskAugmentedRequestParamsSchema (81), TaskStatusSchema (622), TaskSchema (628), CreateTaskResultSchema (654), GetTaskRequestSchema (674) and the rest of the GetTask*/ListTasks*/CancelTask*/GetTaskPayload* schemas, ToolExecutionSchema (1288), ToolSchema.shape.execution (1341), CallToolRequestParamsSchema = TaskAugmentedRequestParamsSchema.extend(...) (1412), ServerRequestSchema (2119), and the method-result map entry 'tools/call' → z.union([CallToolResultSchema, CreateTaskResultSchema]) (2171).
• packages/core/src/shared/taskManager.ts, Protocol task plumbing, {Server,Client}TasksCapabilityWithRuntime, assertClientRequestTaskCapability/assertServerRequestTaskCapability, plus the corresponding types.ts/guards.ts/specTypeSchema.ts entries.

None of these import spec.types.ts, so neither tsc --noEmit on src/ nor the specTypeSchema allowlist guard flags any of it. A reviewer addressing only the existing 20 comments would fix the schemas/unions/test allowlists for the Multi-Round-Trip and stateless changes — and ship a release that still publicly exports InMemoryTaskStore, callTool({ task: { ttl } }), Tool.execution.taskSupport, and a ServerRequestSchema for a request direction the protocol no longer defines.

Step-by-step proof

1. Before (spec.types.ts @ 8e192a22, the revision comments #3223937258/#3246176908 were written against): export type ServerRequest = GetTaskRequest | GetTaskPayloadRequest | ListTasksRequest | CancelTaskRequest; export interface Task { taskId; status; … }; Tool.execution?: ToolExecution; ServerCapabilities.tasks?: { list?, cancel?, requests? }.
2. After (this diff, c47bd846): grep -E '^export (type|interface) (ServerRequest|Task|TaskStatus|TaskMetadata|GetTaskRequest|ListTasksRequest|CancelTaskRequest|CreateTaskResult|ToolExecution|TaskAugmentedRequestParams)' packages/core/src/types/spec.types.ts → zero matches. The /* Server messages */ block contains only ServerNotification and ServerResult; ClientResult = EmptyResult only; ClientRequest ends at ListToolsRequest.
3. spec.types.test.ts:499 does (sdk: SDKTypes.ServerRequest, spec: SpecTypes.ServerRequest) => { sdk = spec; spec = sdk; } → TS2694 "Namespace '…/spec.types' has no exported member 'ServerRequest'". Same for ~24 other deleted task names → tsc --noEmit -p packages/core fails before any test runs.
4. SDK runtime still exposes the task flow end-to-end: new McpServer({ capabilities: { tasks: { requests: { tools: { call: {} } } } } }) advertises a capability the spec no longer defines; server.registerTool('foo', { execution: { taskSupport: 'optional' } }, …) populates ToolSchema.execution for a field the spec deleted; client.callTool({ name: 'foo', task: { ttl: 60_000 } }) builds CallToolRequestParamsSchema from TaskAugmentedRequestParamsSchema.extend(...) and emits params.task on the wire — a field a c47bd846-compliant server has no schema for.
5. Protocol's generic typing is parameterised over <SendRequestT, SendNotificationT, SendResultT> with ServerRequestSchema (schemas.ts:2119) feeding the server-side request union. With the spec defining no server→client requests, that schema and the Protocol.request() server-side outbound path have no spec counterpart — the SDK must decide whether ServerRequest becomes never, is removed from the generic signature, or is kept as a back-compat shim.
6. No CI signal: grep -r 'spec.types' packages/core/src/experimental packages/core/src/shared/taskManager.ts packages/{client,server}/src/experimental → nothing. The 9 experimental/tasks/** files, taskManager.ts, and the ~20 task schemas all typecheck cleanly.

Impact

This is a fourth non-mechanical redesign axis (after #3206453743 InputRequiredResult, #3223937258 stateless handshake, and the subscriptions/listen transport work). It is not "add/remove schemas" — it requires:

• Deprecate/remove the entire packages/{core,client,server}/src/experimental/tasks/** public surface (TaskManager, InMemoryTaskStore, {Server,Client}TasksCapabilityWithRuntime, assert{Client,Server}RequestTaskCapability, the capabilities.tasks constructor handling) — breaking change → migration.md entry + major changeset.
• Strip task: TaskMetadataSchema from CallToolRequestParamsSchema (it must extend the new InputResponseRequestParamsSchema instead of TaskAugmentedRequestParamsSchema); remove ToolExecutionSchema and ToolSchema.shape.execution; remove CreateTaskResultSchema from the 'tools/call' result-map union (2171).
• Delete ServerRequestSchema (2119) and rework Protocol's server→client request typing — the spec now defines no such requests, so the SDK must decide whether the server-side request() outbound path is removed, narrowed to never, or kept as a deprecated shim.
• Remove ~20 task schemas from schemas.ts, their types.ts aliases, guards.ts predicates, and specTypeSchema.ts registrations; drop tasks from {Server,Client}CapabilitiesSchema; delete shared/taskManager.ts.
• In spec.types.test.ts: delete the ~24 sdkTypeChecks entries for task types and ServerRequest, and update the toHaveLength(...) count once all four axes are reconciled.

None of the existing comments' remediation lists mention any task-type deletion, ToolExecution removal, ServerRequestSchema deletion, or experimental/tasks deprecation, so this needs to be tracked as a separate companion-work axis.

What the bug is

The latest force-push (upstream commit c47bd846) adds a new mixin interface to packages/core/src/types/spec.types.ts (lines 949-976):

export interface CacheableResult extends Result {
    /**
     * A hint from the server indicating how long (in milliseconds) the
     * client MAY cache this response before re-fetching. Semantics are
     * analogous to HTTP Cache-Control max-age.
     * ...
     */
    ttlMs: number;
    /**
     * Indicates the intended scope of the cached response, analogous to HTTP
     * `Cache-Control: public` vs `Cache-Control: private`.
     * ...
     */
    cacheScope: 'public' | 'private';
}

Both fields are declared without ?, so they are required. The same diff then changes five result types to extends CacheableResult: ListResourcesResult (line 999), ListResourceTemplatesResult (1035), ReadResourceResult (1096), ListPromptsResult (1392), and ListToolsResult (1593). None of the 20 existing PR comments mention CacheableResult, ttlMs, or cacheScope — comments #3206453749/#3223937253 enumerate the Multi Round-Trip and Discover/Subscription additions, and #3206453753 covers resultType-required on the base Result, but this is a fully disjoint addition from the latest revision.

How it manifests in CI

A grep for CacheableResult|ttlMs|cacheScope across packages/core/src and packages/core/test matches only spec.types.ts — no Zod schema in schemas.ts, no SDK type alias in types.ts, no specTypeSchemas registration, and no sdkTypeChecks entry in spec.types.test.ts. So the drift guard fails in two ways that are independent of the resultType errors already documented:

1. Coverage check — should have comprehensive compatibility tests parses every export (interface|type) <Name> from spec.types.ts, skips MISSING_SDK_TYPES, and asserts sdkTypeChecks[<Name>] is defined. CacheableResult is a new exported interface with no entry → expected undefined to be defined. (And the hardcoded toHaveLength(176) count is off by one more.)
2. Bidirectional / exact-keys checks — spec.types.test.ts does spec = sdk for ListToolsResult/ListResourcesResult (lines ~255/320) and AssertExactKeys for all five affected result types (lines ~850-862). The SDK's ListToolsResultSchema etc. in schemas.ts are still PaginatedResultSchema.extend({ tools: ... }) with no cache fields, so each produces TS2741 "Property 'ttlMs' is missing in type '{ ... }' but required in type 'ListToolsResult'" (and likewise for cacheScope). ServerResult (which unions all five) gets the same error.

These errors occur on top of the resultType ones — even if resultType were made optional upstream, all of the above still fail.

Why existing code doesn't prevent it

By design — the cron job updates only spec.types.ts; the drift guard exists precisely to surface this. schemas.ts's ListToolsResultSchema/ListPromptsResultSchema/ListResourcesResultSchema/ListResourceTemplatesResultSchema/ReadResourceResultSchema have no ttlMs/cacheScope fields, and nothing in mcp.ts or any handler sets them when constructing list/read results.

Step-by-step proof

1. After this diff, spec.types.ts:949-976 defines CacheableResult with ttlMs: number and cacheScope: 'public' | 'private' — neither has a ?.
2. ListToolsResult (line 1593) is changed from extends PaginatedResult to extends PaginatedResult, CacheableResult. So SpecTypes.ListToolsResult now requires { tools: Tool[]; nextCursor?: Cursor; ttlMs: number; cacheScope: 'public'|'private'; resultType: ResultType; _meta?: ... }.
3. schemas.ts's ListToolsResultSchema (line ~1360) is unchanged: PaginatedResultSchema.extend({ tools: z.array(ToolSchema) }). The inferred SDK type has no ttlMs or cacheScope.
4. spec.types.test.ts does (sdk: SDKTypes.ListToolsResult, spec: SpecTypes.ListToolsResult) => { spec = sdk; }. TypeScript rejects: TS2741 "Property 'ttlMs' is missing in type '{ tools: ...; nextCursor?: ...; _meta?: ... }' but required in type 'ListToolsResult'", then the same for cacheScope.
5. The same failure repeats for ListResourcesResult, ListResourceTemplatesResult, ReadResourceResult, ListPromptsResult, and the ServerResult union check; the AssertExactKeys<SpecTypes.ListXxxResult, SDKTypes.ListXxxResult> checks at lines ~850-862 fail for the same reason.
6. Independently, extractExportedTypes picks up 'CacheableResult'; it is not in MISSING_SDK_TYPES and not in sdkTypeChecks → coverage assertion fails.

Impact

CI is red on this PR for an additional, distinct reason. Beyond the test failures, every SDK consumer's server.tool(...) / listTools handler that returns { tools: [...] } would no longer satisfy Spec.ListToolsResult, and once the companion work mirrors this into schemas.ts, every list/read result-construction site in mcp.ts would have to supply ttlMs/cacheScope even when the server has no caching opinion — a substantial, non-mechanical change for fields the JSDoc itself describes as a "hint" the client "MAY" honor.

Upstream-design observation (same class as comment #3206453753)

Declaring ttlMs/cacheScope as required contradicts the JSDoc's own framing: ttlMs is "a hint … the client MAY cache", and the explicit analogy is HTTP Cache-Control, which is opt-in — an HTTP server omits the header when it has no caching policy. Forcing every server to emit caching directives on every list/read result (including ones backed by dynamic per-request data where caching is meaningless) is the same defect class as resultType being required despite @default "complete". Both fields almost certainly should be ttlMs?: number / cacheScope?: 'public' | 'private' in upstream schema.ts.

How to fix

Two parts, mirroring the structure of comments #3206453749/#3206453753:

• Upstream (preferred): change schema.ts to ttlMs?: number and cacheScope?: 'public' | 'private' (matching the "hint"/"MAY cache"/Cache-Control opt-in semantics), then re-run pnpm run fetch:spec-types. Batch with the resultType? (#3206453753) and other upstream feedback already on the table.
• SDK companion work (regardless of optionality): add CacheableResultSchema to schemas.ts and have ListResourcesResultSchema/ListResourceTemplatesResultSchema/ReadResourceResultSchema/ListPromptsResultSchema/ListToolsResultSchema extend it; register CacheableResult in specTypeSchemas; add a sdkTypeChecks.CacheableResult entry in spec.types.test.ts and bump the type count. If upstream keeps the fields required, also thread ttlMs/cacheScope through every list/read result-construction site in mcp.ts — but that should not land in an automated nightly sync.