Over the Streamable HTTP transport, a client POSTs a JSON-RPC notification and the server accepts it. What does the server return?
Select an answer to reveal the explanation.
Short Explanation
A notification is a one-way note, so you don't get a reply, just a nod. On Streamable HTTP that nod is 202 Accepted with an empty body. Anything with a result or a stream is the trap.
Full Explanation
JSON-RPC notifications have no id and the receiver MUST NOT send a response. The Streamable HTTP transport maps this onto HTTP precisely: if the body of the POST is a notification and the server accepts it, the server MUST return status 202 Accepted with no body; if it cannot accept it, it MUST return an HTTP error status such as 400 Bad Request, optionally with a JSON-RPC error response that has no id. Returning 200 OK with an empty result implies a JSON-RPC response, which would violate the rule that notifications get none. Returning 204 with a session identifier mixes up status codes and resurrects protocol sessions; Mcp-Session-Id belongs to earlier revisions, and a server supporting only 2026-07-28 ignores that header and does not mint session IDs. Opening an SSE stream is the server's option only for requests, where it carries related notifications followed by the final response; a notification needs nothing back. Exam caveat: this revision of the core protocol defines no client-to-server notifications over Streamable HTTP, since cancellation there is signaled by closing the request's response stream, and notifications/cancelled is used only on stdio. The 202 rule describes transport mechanics for any notification POST. Operational check: POST a notification to the MCP endpoint and confirm the server returns 202 with an empty body.