bug(server): connect() silently overwrites transport, breaking concurrent HTTP sessions

[josh-fisher]

Describe the bug
When using StreamableHTTPServerTransport with multiple concurrent sessions, calling Server.connect(transport) for a second transport silently breaks the first transport's ability to receive responses. This is because connect() overwrites this._transport without any warning or error.

Related: #1400 describes a similar issue with reconnection ("Server already initialized"). Both stem from the same root cause: Server only supports one transport at a time. This issue documents a different failure mode—silent corruption of existing connections rather than an explicit error.

To Reproduce

1. Create a single Server instance
2. Create StreamableHTTPServerTransport for Session A and call server.connect(transportA)
3. Session A makes requests successfully
4. Create StreamableHTTPServerTransport for Session B and call server.connect(transportB)
5. Session A now fails with AbortError: This operation was aborted

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';

const server = new Server({ name: 'test', version: '1.0.0' }, { capabilities: { tools: {} } });

// Session A connects
const transportA = new StreamableHTTPServerTransport({ sessionIdGenerator: () => 'session-a' });
await server.connect(transportA);  // Works

// Session B connects
const transportB = new StreamableHTTPServerTransport({ sessionIdGenerator: () => 'session-b' });
await server.connect(transportB);  // Also "works" - but silently breaks transportA

// Now any request through transportA will fail

Expected behavior
Either:

1. Server.connect() should throw an error if already connected to a transport, OR
2. Server should support multiple concurrent transports for HTTP scenarios, OR
3. Documentation should clearly state that each HTTP session requires its own Server instance

Logs

[MCP] POST tools/call for session A...
[MCP] SSE socket.end for session A...
[MCP] SSE req.aborted for session A...
AbortError: This operation was aborted

Additional context

• SDK Version: 1.25.2
• The root cause is in Protocol.connect() which simply overwrites this._transport without checking for an existing connection
• Workaround: Create a new Server instance for each session, as shown in the SDK's sseAndStreamableHttpCompatibleServer.js example
• This is a significant footgun because: no error is thrown at connect() time, the first session works until the second connects, and error messages don't indicate the root cause

Suggested fix (fail fast):

async connect(transport) {
    if (this._transport) {
        throw new Error('Server is already connected to a transport. Create a new Server instance for each connection, or call close() first.');
    }
    this._transport = transport;
    // ...
}

[mozmo15]

This is expected behaviour and there have been discussions about the limitations of an McpServer instance in communicating with multiple different clients at the same time. For example:
modelcontextprotocol/servers#1215

We ran into this issue in the past before we realized we actually need to create an McpServer instance for every incoming call, and register the tools on it everytime, not necessarily intuitive but this is whats currently expected for your server application to be able to handle paralallel communication. You're right in that this is especially problematic because previous connections fail silently and its hard to actually figure out why unless you suspect that one McpServer may be insufficient yourself.

The transports themselves can be reused, but not an McpServer instance, as you mentioned, this is the case with the official provided examples (there is also the whole issue with transports requiring in memory storage and that being fundementally incompatible with horizantal scaling):
https://github.com/modelcontextprotocol/typescript-sdk/blob/main/examples/server/src/simpleStreamableHttp.ts

You could consider this a design flaw, but I wouldnt say its a bug. I also think its not really mentioned or explained well in the documentation, beyond being demonstrated in the example files

[aldipower]

Server.connect() should throw an error if already connected to a transport

Yes, please.

[stomde]

Supported versions

…

On Mon, Jan 26, 2026, 11:16 AM Felix Gertz ***@***.***> wrote: *aldipower* left a comment (modelcontextprotocol/typescript-sdk#1405) <#1405 (comment)> Server.connect() should throw an error if already connected to a transport Yes, please. — Reply to this email directly, view it on GitHub <#1405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATZ5V73SLVSOQXTCHEXE7U34IXEPTAVCNFSM6AAAAACSFPIRY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJYGM2TMNJUGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>