Repository navigation
Notification POSTs: the Note and the POST header rules still disagree after PR #2891 #3487
Description
What's broken?
The spec is ambiguous or self-contradictory
Where in the spec or docs?
https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http#sending-messages (also "Protocol Version Header", "Standard Request Headers", "Server Validation")
What should happen?
Limit item 3, the "Protocol Version Header" sentence and Server Validation to POSTs that carry a JSON-RPC request, and say in the Note that it concerns the request metadata headers (Accept is required separately).
What actually happens?
basic/transports/streamable-http, "Sending Messages", item 3:
The client MUST include the request metadata headers on each POST request.
"Protocol Version Header":
Every POST request to the MCP endpoint MUST include an
MCP-Protocol-Versionheader.
The Note at the end of "Sending Messages":
The notification rules above describe the transport mechanics for a notification POST; header requirements for notification POSTs are not defined by this revision.
The Note excludes notification POSTs from the request metadata rules, but the surrounding requirements still say "each POST request" and "Every POST request", and Server Validation follows them. The same Note says this revision defines no client notifications over Streamable HTTP, so today this affects extensions and later revisions. PR #2891 added the Note and described the earlier rule as unsatisfiable, but left the two sentences as they were. The table under "Standard Request Headers" already scopes Mcp-Method to "All requests".
Anything else?
These points concern MCP specification version 2026-07-28 and are also present in the draft pages.
An AI system helped find and cross-check these points.
Rifat Jumagulov
Arxo Law · hi@arxo.io
Activity
media-ctrl commentedon Nov 5, 2026
The two sentences are the whole defect, and the edit is mechanical:
Both then agree with the Note instead of contradicting it. Two supporting points:
Server Validation sits downstream of item 3 and rejects with 400 when the headers are absent, so leaving the sentences alone means an extension that defines a notification POST inherits a MUST that this same revision calls undefined for that POST. Scoping the two sentences fixes the validation behaviour without editing the table.
The "Standard Request Headers" table already scopes Mcp-Method to "All requests", which supports scoping rather than broadening: a notification POST is not a request, so the row does not reach it. That mismatch is what makes the current text read as an oversight rather than a deliberate rule, and it is the argument a reviewer will want in the PR description.
One line worth adding to the Note while it is being touched: notification POSTs still need Accept, since a 202 carries no body but the transport still negotiates content type. The Note excludes only the request metadata headers, and "header requirements for notification POSTs are not defined" reads as covering Accept too, which would be a wider claim than intended.