Skip to content

Close transport-layer specification gaps in the draft#2891

Open
pja-ant wants to merge 4 commits into
mainfrom
fix/draft-transport-rules
Open

Close transport-layer specification gaps in the draft#2891
pja-ant wants to merge 4 commits into
mainfrom
fix/draft-transport-rules

Conversation

@pja-ant
Copy link
Copy Markdown
Contributor

@pja-ant pja-ant commented Jun 7, 2026

What this does

Three normative fixes plus one clarification to draft transport/pattern rules where the current text is unimplementable or leaves conforming implementations free to diverge.

Changes

  • Give notifications/elicitation/complete a delivery channel. The draft removed the GET stream, response-stream notifications must relate to the in-flight request, and SubscriptionFilter had no field for elicitation completion — so the 'wait for the completion notification, then retry' flow the spec endorses could never receive the notification. Adds an elicitationComplete opt-in to SubscriptionFilter; elicitation.mdx's URL-mode flow now subscribes via subscriptions/listen.
  • Restrict x-mcp-header to statically reachable properties. The extraction rule was undefined for properties under array items, composition keywords, or $ref — two conforming clients could disagree on whether a tool is valid. Annotations are now valid only on properties reachable via a chain of properties keys, with extraction and absent-value behavior defined.
  • Extend the Base64 sentinel encoding to Mcp-Name. Tool/prompt names are only SHOULD-constrained, so a non-header-safe name made the tool permanently uncallable over Streamable HTTP with no defined encoding.
  • Clarify that core client notifications do not occur over Streamable HTTP. The transport text implied clients POST notifications and required the MCP-Protocol-Version header on those POSTs to match a body _meta field that notifications do not carry — an unsatisfiable rule. In this revision the only client-sent notification, notifications/cancelled, is stdio-only (on Streamable HTTP, closing the SSE response stream is the cancellation signal), so the header–body match requirements are now stated for requests, and header requirements for notification POSTs are explicitly left undefined. Mcp-Method's Required For scope is corrected to "All requests".

Verification

npm run generate:schema artifacts committed; npm run prep and npm run check pass clean.

pja-ant added 2 commits June 7, 2026 13:54
Tool and prompt names are only SHOULD-constrained to header-safe
characters, so a name outside the safe set previously made the tool
uncallable over Streamable HTTP: Mcp-Name is required, but no encoding
was defined for it.

- Allow the =?base64?...?= sentinel encoding (already defined for
  Mcp-Param-{Name} headers) for the Mcp-Name header value.
- Require servers to decode encoded Mcp-Name and Mcp-Param-{Name}
  values before comparing them to the request body during server
  validation.
The x-mcp-header extraction rule was undefined for properties nested
under array 'items', inside composition or conditional keywords
(oneOf/anyOf/allOf/not, if/then/else), or behind $ref: such properties
have no single static location in the call arguments.

- x-mcp-header annotations are now only valid on properties reachable
  from the schema root via a chain consisting solely of 'properties'
  keys. Annotations anywhere else make the tool definition invalid,
  triggering the existing client rejection rules.
- Define extraction as reading the instance value at the annotated
  property's exact path; if the value is absent, the header is omitted.
- Mirror the rule in the Tool.inputSchema schema documentation.
@mintlify
Copy link
Copy Markdown

mintlify Bot commented Jun 7, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
mcp-staging 🟢 Ready View Preview Jun 7, 2026, 1:07 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

@mintlify
Copy link
Copy Markdown

mintlify Bot commented Jun 7, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
mcp 🟢 Ready View Preview Jun 7, 2026, 1:06 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

pja-ant added 2 commits June 7, 2026 14:22
notifications/elicitation/complete had no legal delivery channel: the
HTTP GET stream is gone, response-stream notifications must relate to
the in-flight request, and the subscriptions/listen filter had no field
covering elicitation completion — while servers must not send
notification types the client has not requested.

- Add an opt-in elicitationComplete boolean to SubscriptionFilter;
  when true, the server may deliver notifications/elicitation/complete
  on that subscription's stream.
- Document on ElicitationCompleteNotification that it is only sent to
  clients that opted in via elicitationComplete and is delivered on
  that subscription's stream (with the subscription ID in _meta).
- Document the URL-mode elicitation flow: the client subscribes via
  subscriptions/listen with elicitationComplete: true, waits for the
  completion notification, then retries the original request.
- Regenerate schema.json and the schema reference.
In this revision, the only client-sent notification in the core
protocol is notifications/cancelled, and it is used only on the stdio
transport: on Streamable HTTP, closing the SSE response stream is
itself the cancellation signal and no notifications/cancelled message
is expected.

- Note this in the Sending Messages section, cross-linking the
  cancellation pattern; the notification POST rules remain as transport
  mechanics, with header requirements for notification POSTs left
  undefined by this revision.
- Scope the protocol-version header-body match requirement and the
  Mcp-Method header requirement to requests. Request-side rules are
  unchanged.
@pja-ant pja-ant force-pushed the fix/draft-transport-rules branch from d612b11 to 22d61dc Compare June 7, 2026 13:24
@pja-ant pja-ant marked this pull request as ready for review June 7, 2026 13:31
@pja-ant pja-ant requested a review from a team as a code owner June 7, 2026 13:31
@localden localden added rc-high-priority Related to an upcoming specification release and needs to be addressed with a high priority. spec labels Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rc-high-priority Related to an upcoming specification release and needs to be addressed with a high priority. spec

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants