v0.16.7 connection regression: "Error accessing endpoint (HTTP 404)"

[jpmcb]

Inspector Version

v0.16.7

Describe the bug

On the newest inspector, v0.16.7, I get a 404 for some reason:

New StreamableHttp connection request
Query parameters: {"url":"https://test-test-main-f56b2f3.d2.zuplo.dev/mcp","transportType":"streamable-http"}
Created StreamableHttp client transport
Client <-> Proxy  sessionId: b06049e0-4bc2-48c2-a715-1cefff93101a
Received POST message for sessionId b06049e0-4bc2-48c2-a715-1cefff93101a
Received GET message for sessionId b06049e0-4bc2-48c2-a715-1cefff93101a
Error accessing endpoint (HTTP 404)

This is during initialization and any subsequent call, like tools/list:

(note the error message "Error POSTing to endpoint (404)" - it also tells me that I've connected just fine which is weird)

But, on v0.16.6, it works as expected:

New StreamableHttp connection request
Query parameters: {"url":"https://test-test-main-f56b2f3.d2.zuplo.dev/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: cc76cdf5-5e5b-4531-8f8a-2dcc48e99235
Received POST message for sessionId cc76cdf5-5e5b-4531-8f8a-2dcc48e99235
Received GET message for sessionId cc76cdf5-5e5b-4531-8f8a-2dcc48e99235
Received POST message for sessionId cc76cdf5-5e5b-4531-8f8a-2dcc48e99235

My server works just fine via curl:

❯ curl https://test-test-main-f56b2f3.d2.zuplo.dev/mcp \
      -X POST \
      -H 'accept: application/json, text/event-stream' \
      -H 'content-type: application/json' \
      -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {
        "roots": {},
        "sampling": {},
        "elicitation": {}
      },
      "clientInfo": {
        "name": "ExampleClient",
        "title": "Example Client Display Name",
        "version": "1.0.0"
      }
    }
  }' -vvv
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host test-test-main-f56b2f3.d2.zuplo.dev:443 was resolved.
* IPv6: (none)
* IPv4: 104.18.31.5, 104.18.30.5
*   Trying 104.18.31.5:443...
* Connected to test-test-main-f56b2f3.d2.zuplo.dev (104.18.31.5) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=zuplo.dev
*  start date: Aug 19 17:53:53 2025 GMT
*  expire date: Nov 17 17:53:52 2025 GMT
*  subjectAltName: host "test-test-main-f56b2f3.d2.zuplo.dev" matched cert's "*.d2.zuplo.dev"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://test-test-main-f56b2f3.d2.zuplo.dev/mcp
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: test-test-main-f56b2f3.d2.zuplo.dev]
* [HTTP/2] [1] [:path: /mcp]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: application/json, text/event-stream]
* [HTTP/2] [1] [content-type: application/json]
* [HTTP/2] [1] [content-length: 337]
> POST /mcp HTTP/2
> Host: test-test-main-f56b2f3.d2.zuplo.dev
> User-Agent: curl/8.7.1
> accept: application/json, text/event-stream
> content-type: application/json
> Content-Length: 337
>
* upload completely sent off: 337 bytes
< HTTP/2 200
< date: Mon, 15 Sep 2025 13:47:42 GMT
< content-type: application/json
< content-length: 235
< cf-ray: 97f893d83cc2c436-EWR
< zp-rid: 33f1d552-bc2a-4282-8692-d4eff8f19f06
< server: cloudflare
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host test-test-main-f56b2f3.d2.zuplo.dev left intact
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"supported":true,"available":["1e0edd2a-8d53-4355-805f-54b7e5555725"]},"prompts":{}},"serverInfo":{"name":"Zuplo MCP Server","version":"0.0.0"}}}

❯ curl https://test-test-main-f56b2f3.d2.zuplo.dev/mcp \
      -X POST \
      -H 'accept: application/json, text/event-stream' \
      -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "tools/list"
  }' -vvv
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host test-test-main-f56b2f3.d2.zuplo.dev:443 was resolved.
* IPv6: (none)
* IPv4: 104.18.31.5, 104.18.30.5
*   Trying 104.18.31.5:443...
* Connected to test-test-main-f56b2f3.d2.zuplo.dev (104.18.31.5) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=zuplo.dev
*  start date: Aug 19 17:53:53 2025 GMT
*  expire date: Nov 17 17:53:52 2025 GMT
*  subjectAltName: host "test-test-main-f56b2f3.d2.zuplo.dev" matched cert's "*.d2.zuplo.dev"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://test-test-main-f56b2f3.d2.zuplo.dev/mcp
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: test-test-main-f56b2f3.d2.zuplo.dev]
* [HTTP/2] [1] [:path: /mcp]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: application/json, text/event-stream]
* [HTTP/2] [1] [content-length: 61]
* [HTTP/2] [1] [content-type: application/x-www-form-urlencoded]
> POST /mcp HTTP/2
> Host: test-test-main-f56b2f3.d2.zuplo.dev
> User-Agent: curl/8.7.1
> accept: application/json, text/event-stream
> Content-Length: 61
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 61 bytes
< HTTP/2 200
< date: Mon, 15 Sep 2025 13:48:21 GMT
< content-type: application/json
< content-length: 435
< cf-ray: 97f894cbaa8e0f3e-EWR
< zp-rid: 8c4379f8-d7d4-4764-a5a0-bf4d31b27c06
< server: cloudflare
< alt-svc: h3=":443"; ma=86400
<
* Connection #0 to host test-test-main-f56b2f3.d2.zuplo.dev left intact
{"jsonrpc":"2.0","id":"1","result":{"tools":[{"name":"1e0edd2a-8d53-4355-805f-54b7e5555725","description":"**Retrieves a complete list of all todo items** from the system. This endpoint returns all todos regardless of their completion status or owner, making it useful for displaying comprehensive todo lists or performing bulk operations.","inputSchema":{"type":"object","properties":{},"required":[],"additionalProperties":false}}]}}

To Reproduce

I'm really not sure what's going on here or why the inspector is 404-ing. Is there any way I can see the actual calls in the client logs? The current level of logging is not actually that useful.

Running my server / gateway locally, I only see POST messages going through:

[09:50:29.435] DEBUG [POST /mcp] Request received '/mcp'
[09:50:29.435] DEBUG [POST /mcp] {"method":"POST","url":"/mcp","hostname":"localhost","route":"/mcp"}
[09:50:29.458] DEBUG [POST /mcp] Request received '/mcp'
[09:50:29.458] DEBUG [POST /mcp] {"method":"POST","url":"/mcp","hostname":"localhost","route":"/mcp"}
[09:50:39.753] DEBUG [POST /mcp] Request received '/mcp'
[09:50:39.753] DEBUG [POST /mcp] {"method":"POST","url":"/mcp","hostname":"localhost","route":"/mcp"}

so I'm really not sure what it's 404-ing on.

[jpmcb]

One thing to note: this server will 405 on GET to the endpoint:

❯ curl localhost:9000/mcp
{
  "type": "https://httpproblems.com/http-status/405",
  "title": "Method Not Allowed",
  "status": 405,
  "instance": "/mcp",
  "trace": {
    "timestamp": "2025-09-15T13:55:51.661Z",
    "requestId": "3c4afdf6-0c51-45df-8ccd-4f644bf67954",
    "buildId": "2480965b-4f96-445c-8bc9-389e9e4048dc"
  }
}

since it's run in "stateless" mode and doesn't support client disconnects, sessions, etc. Could this be why the MCP inspector isn't handling the connection?

[olaservo]

It looks like this is caused by the stricter session management introduced as part of this PR: https://github.com/modelcontextprotocol/inspector/pull/787/files

@cliffhall should we support some kind of fallback for this stateless server scenario?

[cliffhall]

https://github.com/modelcontextprotocol/inspector/pull/787/files

@olaservo That PR is not really about "strictness", it's about making sure that headers that are introduced after the initial connection (e.g., mcp-protocol-version or last-event-id) are captured and added to ongoing requests, whereas they were being lost before. There's not really a fallback position.

[cliffhall]

@jpmcb a 404 Not Found generally indicates that the endpoint the client is trying to hit is not answering. Looking into what's going on. I can see your server and can duplicate the error and see that it worked in 0.16.6. WIll report back soon.

[cliffhall]

For reference, 0.16.7 works fine with the Everything reference server.

When connecting to the Everything server, I CAN see that a Proxy <-> Server session id is established.

[cliffhall]

I can see that I'm getting a 404 on the GET request that happens after initialization to start a global SSE stream. And another 404 when trying to POST a prompts/list request. Also, notice that, I do NOT see a Proxy <-> Server session Id established as I did above with the Everything server.

[cliffhall]

The Proxy <-> Server session Id message you can see in the exchange with the Everything server indicates the server returned an mcp-session-id header in the initialization handshake. Your server is not doing that. Previously this was not a problem, now it is. Still trying to determine why.

0.16.6 - Not receiving a session id from server, but works

0.16.7 - Not receiving a session id from server, but fails

[jpmcb]

👀 good investigation: this is using the @zuplo/mcp SDK and I can reproduce it with a very small minimal server: https://github.com/zuplo/mcp/blob/main/examples/servers/calculator/src/index.ts

indicates the server returned an mcp-session-id header in the initialization handshake. Your server is not doing that. Previously this was not a problem, now it is. Still trying to determine why.

Interesting: the whole idea with @zuplo/mcp is to support entirely stateless MCP servers. So we don't have sessions. My assumption from reading other SDKs, like the go-sdk, the session ID header isn't required.

	if c.sessionID != "" && stream.isInitialize {
		w.Header().Set(sessionIDHeader, c.sessionID)
	}

https://github.com/modelcontextprotocol/go-sdk/blob/c2c810bf40eb390df87680736fa9efd642b399dc/mcp/streamable.go#L700-L702

Let me see if I can build a small stateless server with one of the main SDKs to re-produce.

[cliffhall]

Let me see if I can build a small stateless server with one of the main SDKs to re-produce.

A better test might be to return an mcp-session-id header and see if your server starts to work. If it does, then we know that's the problem. No need to duplicate another stateless server with another sdk.

[cliffhall]

Ok, I've got a fix. Will prepare a PR momentarily.

[cliffhall]

PR is ready for review: #806

[cliffhall]

@jpmcb The fix will be in the next release of the Inspector. Thanks for bringing this up. Sessionless StreamableHttp is something of an oddity in the wild. Good to catch this behavior.