MCP-RES-004
Accepted notification POST returns 202 with no body
“If the server accepts it, the server MUST return HTTP status code 202 Accepted with no body.” — spec anchor
How to fix this
Return HTTP 202 Accepted with an empty body when you accept a notification POST. A body on a 202, or any other status, is a violation.
How the validator checks this
Probe P6.1, against a streamable-http server on the modern protocol. What it reports:
- pass
- Accepted notification returned 202 with no body
- warn
- Returned 202 but with a response body; the spec requires 202 with no body
- fail
- Accepted notification returned HTTP … — it must be 202 with no body
- info
- Rejected the notification (HTTP …). A server may legitimately not accept this notification type, so this is not scored as a failure.
Quoted from the probe that runs this check, so it cannot drift from what the validator actually reports.
This rule is checked deterministically: a fail here is a certain violation, not an inference.
Check your own server against this rule
The validator makes real protocol requests and reports this rule as pass, warn or fail alongside the other 78. Validate a server or read how the check works.
Other Result and message shape rules
- MCP-RES-001Every result includes resultType
- MCP-RES-002resultType is a value defined by core or an advertised extension
- MCP-RES-003Server sends no independent JSON-RPC requests on a response stream
- MCP-RES-005Response is application/json or text/event-stream; SSE terminates with the final response
- MCP-RES-006SSE responses set X-Accel-Buffering: no
- MCP-RES-007tools/list returns a deterministic order