Stateless mode: per-request McpServer+Protocol allocation causes memory leak at scale

[RomKadria]

Problem

In stateless mode (sessionIdGenerator: undefined), the recommended pattern — including the SDK's own simpleStatelessStreamableHttp.ts example — creates a full McpServer + Protocol + StreamableHTTPServerTransport on every HTTP request:

app.post('/mcp', async (req, res) => {
    const server = getServer();  // new McpServer per request
    const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
    await server.connect(transport);
    await transport.handleRequest(req, res, req.body);
    res.on('close', () => { transport.close(); server.close(); });
});

Each request allocates:

• McpServer → Server → Protocol: 9 Maps/Sets (_requestHandlers, _responseHandlers, _progressHandlers, _notificationHandlers, _requestHandlerAbortControllers, _timeoutInfo, _pendingDebouncedNotifications, _taskProgressTokens, _requestResolvers), plus _loggingLevels Map
• Server: new AjvJsonSchemaValidator (compiles JSON schemas)
• StreamableHTTPServerTransport → WebStandardStreamableHTTPServerTransport: 3 Maps (_streamMapping, _requestToStreamMapping, _requestResponseMap), plus getRequestListener from @hono/node-server

This works fine for low-traffic dev/demo scenarios. But for production HTTP servers handling sustained concurrent traffic, V8's GC can't reclaim these objects fast enough, causing steady memory growth until OOMKill.

Real-world impact

We run an MCP server (platform-mcp-gateway) in production on Kubernetes with 1200Mi memory limit. Using this pattern, memory grew ~1-2% per hour until hitting the limit, triggering repeated OOMKill alerts. The service has been running for months — this is a slow leak, not a burst.

Benchmark

We benchmarked the per-request McpServer approach vs. a lightweight JSON-RPC dispatcher that reuses the same handler functions (2,000 requests, --expose-gc):

Metric	McpServer per request	Lightweight dispatcher	Delta
Throughput	2,797 req/s	6,536 req/s	2.3x faster
Heap growth	+3.78 MB	+1.41 MB	2.7x less
Per-request retained	~1,984 bytes	~738 bytes	-63%

Why you can't just reuse a McpServer

The obvious fix — share one McpServer across concurrent requests — doesn't work because Protocol.connect(transport) replaces this._transport. If request A and B overlap:

1. connect(transportA) → sets this._transport = transportA
2. connect(transportB) → sets this._transport = transportB
3. Request A's onmessage fires → _onrequest captures this._transport (now transportB) → response goes to wrong client

Suggestions

1. Lightweight stateless mode: for stateless servers, the full Protocol/Transport stack is overkill — there's no session state, no SSE streaming needed, no server-initiated notifications. A StatelessMcpServer (or a flag on McpServer) could skip all the per-request infrastructure and just dispatch JSON-RPC directly.

2. Fix the connect() transport race: if _onrequest captured the transport from the onmessage callback's closure (the transport that received the message) instead of from this._transport, a single McpServer could safely handle concurrent stateless requests.

3. At minimum, document the trade-off: the stateless example should note that creating a server per request has significant overhead at scale and suggest alternatives for production deployments.

Environment

• @modelcontextprotocol/sdk: 1.29.0
• Node.js: 24.x
• Runtime: Kubernetes pods (1200Mi limit, --max-old-space-size=900)

[RomKadria]

Deep dive: why sharing an McpServer across concurrent requests isn't a simple fix

I investigated fixing Protocol to allow a single McpServer to handle concurrent stateless requests. The transport capture in _onrequest is only one of several issues.

Issue 1: _onrequest captures the wrong transport (fixable)

In connect(), the transport is available in the onmessage closure but _onrequest reads this._transport instead:

async connect(transport: Transport): Promise<void> {
    this._transport = transport;  // replaced by next connect()
    this._transport.onmessage = (message, extra) => {
        // 'transport' is in scope here but not passed through
        this._onrequest(message, extra);
    };
}

private _onrequest(request, extra) {
    const capturedTransport = this._transport;  // may be wrong transport
    // ...
    await capturedTransport?.send(response);  // response goes to wrong client
}

Fix: pass transport from the closure to _onrequest. This part is straightforward.

Issue 2: _onclose wipes shared state (the hard part)

When any transport closes (e.g., after request A completes), it triggers:

private _onclose(): void {
    const responseHandlers = this._responseHandlers;
    this._responseHandlers = new Map();    // wipes ALL pending handlers
    this._progressHandlers.clear();        // wipes ALL progress handlers
    this._transport = undefined;           // nulls the shared reference
    // ...rejects all pending response handlers with ConnectionClosed
}

If request A finishes and transport A closes while request B is still in-flight on transport B, _onclose destroys B's state too. All of Protocol's internal maps are shared across all transports with no per-transport scoping:

• _responseHandlers
• _requestHandlerAbortControllers
• _progressHandlers
• _timeoutInfo
• _taskProgressTokens
• _requestResolvers

Issue 3: connect() replaces callbacks on every call

Each connect() call replaces this._transport.onclose and this._transport.onerror. If transport A's onclose still references this._onclose, and transport B's connect() also sets up this._onclose, both transports' close events trigger the same shared cleanup.

What a proper fix would require

To safely share one McpServer across concurrent stateless requests:

1. Pass transport through closure — _onrequest gets its transport from the onmessage callback, not from this._transport
2. Scope cleanup per transport — _onclose should only clean up state belonging to the closing transport, not all state. This means response handlers, abort controllers, etc. need to be keyed or grouped by transport/session
3. Reference-count transports — only set this._transport = undefined when the last active transport disconnects
4. Guard connect() callbacks — prevent one transport's close from interfering with another's state

This is a meaningful refactor of Protocol's internal state management. I think it's worth doing — it would make stateless mode first-class without the per-request allocation overhead — but it needs careful design to avoid breaking stateful mode.

Happy to contribute a PR if the team has a preferred direction for this.