mcp server lists 12 tools over stdio and 0 over streamable http, same code mcp-server

Take the client out of it and drive the endpoint by hand. Two requests tell you almost everything:

curl -i -X POST https://host/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H 'authorization: Bearer ...' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{...}}'

then the same with "method":"tools/list" and whatever session header came back on the first response.

The three things that catch people, in the order I would check them:

• the session id. The HTTP transport hands you one on initialize and expects it back on every subsequent request. If it is missing from your response, or the client cannot read it, the second request has nowhere to go and the client gives up quietly.
• the proxy. nginx buffers responses by default, which breaks anything streamed. proxy_buffering off; and a long proxy_read_timeout on that location.
• the accept header. The transport wants both content types accepted; a server that rejects one of them fails in a way that reads as "connected but empty".

Stdio has none of these problems, which is exactly why it works and tells you nothing.

One more: if auth is wrong you may be getting a 401 on the second request only, because some clients send the token on connect and not on subsequent calls, or send it in a header your proxy drops. Log every request that reaches the app with method and status. "tools/list never arrives" and "tools/list arrives and nginx answers it" look the same from inside your handler.

If a browser-based client is involved, add CORS to that list and specifically the expose-headers part. A custom response header is invisible to browser JavaScript unless the server names it in Access-Control-Expose-Headers, so the request succeeds, the header is physically present in the response, and the client still cannot read the session id. Devtools will show you the header, which makes this one genuinely maddening to debug.

Check where you register the tools relative to where you connect the transport. With stdio there is one long-lived server instance so registration order rarely bites you. With HTTP, if you construct a fresh server per session, anything registered on a module-level instance outside that factory is registered on an object no request will ever see. Ours listed zero tools for exactly that reason and the code looked completely correct.

Also try it against the inspector rather than your real client. Half the clients out there swallow protocol errors and render an empty tool list, which is how you end up with "no error anywhere". The inspector will show you the raw JSON-RPC in both directions and the problem is usually obvious within thirty seconds of seeing the actual bytes.

Works over stdio, silent over HTTP, nginx in the middle. That sentence has been the setup for the same joke for twenty years.