Invalid MCP server response code for notificcations

[hdu-sdlzx]

Describe the bug
MCP protocol does not require the server to response to notifications/initialized.
So MCP server may return HTTP 204 "No Content".
This caused a TypeError exception in udici (see logs below)

To Reproduce
Steps to reproduce the behavior:

1. Receive an HTTP 204 status code

Expected behavior
No error message

Logs
Received POST message for sessionId de957f71-c7c3-4add-8f74-77017f866ffc
Error from MCP server: TypeError: Response constructor: Invalid response status code 204
at webidl.errors.exception (node:internal/deps/undici/undici:4282:14)
at initializeResponse (node:internal/deps/undici/undici:10234:31)
at new Response (node:internal/deps/undici/undici:9974:9)
at file:///C:/Users/zyliu/AppData/Local/npm-cache/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/inspector/server/build/index.js:255:20
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async StreamableHTTPClientTransport.send (file:///C:/Users/zyliu/AppData/Local/npm-cache/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:315:30)

Additional context
It seems typescript-client expects an HTTP 202 response

            // If the response is 202 Accepted, there's no body to process
            if (response.status === 202) {
                await response.body?.cancel();
                // if the accepted notification is initialized, we start the SSE stream
                // if it's supported by the server
                if (isInitializedNotification(message)) {
                    // Start without a lastEventId since this is a fresh connection
                    this._startOrAuthSse({ resumptionToken: undefined }).catch(err => this.onerror?.(err));
                }
                return;
            }

[felixweinberger]

Thanks for the report! Looking at the stack trace, this appears to be an issue with the Inspector returning 204 instead of 202. The SDK is correctly expecting 202 per the MCP spec, which explicitly states:

If the server accepts the input, the server MUST return HTTP status code 202 Accepted with no body.

See: https://modelcontextprotocol.io/specification/draft/basic/transports#sending-messages-to-the-server

Could you open this issue on the inspector repo instead? https://github.com/modelcontextprotocol/inspector

cc: @cliffhall @olaservo

[cliffhall]

Thanks for the report! Looking at the stack trace, this appears to be an issue with the Inspector returning 204 instead of 202.

@felixweinberger I don't see how this is an Inspector bug. I searched the Inspector codebase for 204 and found no matches, so I know it's not throwing it explicitly. The error in the stack trace says:

Error from MCP server: TypeError: Response constructor: Invalid response status code 204

That message is reported by mcpProxy.ts when the server throws it. The Inspector didn't generate it.

In the bug description @hdu-sdlzx says they are throwing the 204 intentionally. However, as you point out:

The SDK is correctly expecting 202 per the MCP spec, which explicitly states:

If the server accepts the input, the server MUST return HTTP status code 202 Accepted with no body.

See: https://modelcontextprotocol.io/specification/draft/basic/transports#sending-messages-to-the-server

So, the premise of this bug was:

MCP protocol does not require the server to response to notifications/initialized.
So MCP server may return HTTP 204 "No Content".

But that is simply incorrect. 204 is not a valid response to the notifications/initialized message. @hdu-sdlzx please emit a 202 in response to notifications/initialized and this should take care of it.