# Already connected to a transport. Call close() before connecting to a new transport, or use a separate Protocol instance per connection.

**TL;DR:** Upgrade to v1.5.0 or later; each HTTP session now gets its own MCP server instance. Before the fix, one module-level server instance accepted exactly one transport, so the second initialize threw. The Discord gateway client stays shared, so one token still means one gateway connection.

## The error

```
Error handling MCP request: Error: Already connected to a transport. Call close() before connecting to a new transport, or use a separate Protocol instance per connection.
```

## Fix it

1. Check your mcp-discord version.
   Expected: It is older than v1.5.0.
2. Upgrade to v1.5.0 or later.
   Expected: The new version installs.
3. Restart the HTTP server and connect two clients.
   Expected: Both initialize with 200.

## When this applies

In HTTP transport mode the first client connects fine and every later initialize returns a 500 with the transport error.

## When this does NOT apply

Stdio mode has one connection by design and is unaffected. Login failures are the -32603 issue.

## Tool compatibility

barryyip0625/mcp-discord before v1.5.0, --transport http

## Also seen as

- Discord MCP second client initialize fails
- mcp-discord HTTP multi-session
- Already connected to a transport discord

## Why it happens

The MCP SDK Protocol object accepts exactly one transport per server instance. The old code shared one module-level server across sessions, so the second session's connect threw and the handler returned 500.

## Edge cases

- Docker users must pull the new image tag, not just restart.
- Closing the first session never freed the server, so the failure was permanent per process.
- The fix keeps one Discord gateway connection per token, respecting Discord's limit.