Feature Request: Add Streamable HTTP Server Transport

[CaliLuke]

Currently, the MCP Hub server endpoint at /mcp only supports Server-Sent Events (SSE) for client connections, as implemented in src/mcp/server.js using SSEServerTransport.

However, the client-side MCPConnection in src/MCPConnection.js is already designed to prefer a generic StreamableHTTPClientTransport and only falls back to SSE. This creates a mismatch where the hub's client capabilities are more advanced than its server's.

Additionally, the project's README.md states that streamable-http is the primary transport protocol, which can be misleading for users trying to connect clients that might not support SSE or would prefer a different streaming mechanism.

This feature request is to implement a StreamableHTTPServerTransport for the /mcp endpoint to align with the client's capabilities and the project's documentation. This would make the hub more flexible and compliant with its own stated standards.

[stephenprater]

CodexCLI only supports the StreamableHTTPServerTransport - so if you want to use MCPHub with Codex, you have to proxy it through mcp-remote or something similar.

[ReeSilva]

@stephenprater thanks for the tip, using mcp-proxy indeed helped and now I can use mcp-hub in codex :D

[pxkdxo]

Heads-up for whoever picks this up: the existing SSE handler in handleSSEConnection wires teardown to both res.on("close") and transport.onclose, and without a re-entrancy guard server.close() → transport.close() → res.end() re-fires "close" and recurses until V8 throws RangeError: Maximum call stack size exceeded. Fixed in #140.

A StreamableHTTPServerTransport handler will almost certainly want the same dual-trigger teardown shape, so it'll need the same guard (or a shared makeOnceCleanup(...) helper factored out). Worth keeping in mind to avoid reintroducing the bug on the new transport.