fix: throw error when connecting to already-connected Protocol

[codewithkenzo]

Summary

Fixes #1405

Protocol.connect() now throws a descriptive error if called when already connected to a transport. This prevents silent overwrites that break concurrent HTTP sessions.

Problem

When calling connect() twice on the same Protocol instance, the second call would silently overwrite _transport, causing existing sessions to receive AbortError as responses get routed to the wrong transport.

Solution

Add a guard at the start of connect() that throws an informative error if _transport is already set. The error message suggests both options:

1. Call close() before reconnecting
2. Create a new Protocol instance for concurrent connections

This follows the "fail fast" principle used by similar libraries (gRPC, Socket.io, tRPC).

Changes

• packages/core/src/shared/protocol.ts: Add connected check with descriptive error
• packages/core/test/shared/protocolTransportHandling.test.ts: Update tests

Testing

• Added test: throws error on double connect
• Added test: reconnection works after close()
• Updated existing tests: use separate Protocol instances (the correct pattern)

[codewithkenzo]

This implements the approach I outlined in my comment on the issue.

The fix is minimal - just 8 lines in connect() that check if already connected and throw a descriptive error. Tests updated to verify both the error case and the correct pattern (separate Protocol instances for concurrent connections).

Happy to adjust anything based on feedback!

[changeset-bot]

🦋 Changeset detected

Latest commit: eb6e0e4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1441

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1441

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1441

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1441

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1441

commit: eb6e0e4

[felixweinberger]

Thanks for this. #1405 was fixed differently on main: _onrequest captures const capturedTransport = this._transport per-request (protocol.ts:547), so responses route correctly even if connect() is called again mid-flight. The test at protocolTransportHandling.test.ts:62-67 explicitly exercises connect(A) then connect(B) and asserts correct routing. This PR's guard would break that test.