@modelcontextprotocol/hono 2.0.2: Server Instance Lifecycle Breaking Change
The @modelcontextprotocol/hono library now enforces a one-connection-per-server-object policy, breaking patterns where a single server or stateless transport is reused for multiple HTTP requests.
What changed?
With version 2.0.2, a Server or McpServer in @modelcontextprotocol/hono can now only serve one connection at a time. If you use a server object or stateless transport across HTTP requests, the second request (and any after) will fail. Official guidance now requires building both the server and the transport per request or per session. Pre-existing usage patterns that initialized the server outside of handlers or reused stateless transports are now broken and will throw errors such as ALREADY_CONNECTED or result in 500/JSON-RPC -32603 responses.
Without changes to your implementation, you may encounter unhandled rejections (potentially ending your process with plain node:http listeners) or receive failing responses on second and concurrent requests.
Why does it matter to an everyday developer?
If you build or maintain backend services using @modelcontextprotocol/hono, you must adapt your server creation logic. Any handler or middleware that previously cached or reused a server instance will fail after the first request. This applies to serverless, Express, Fastify, Hono integrations, or node HTTP listeners built on this SDK. Without these changes, your app will not handle more than one request per process or session, which can render your endpoint effectively unusable in production scenarios.
What can the developer do now?
- Refactor your handlers to build a new server and a new transport object per incoming HTTP request or per session.
- For Hono, Express, or Fastify integrations: pass a factory function (not a singleton instance) to createMcpHandler (e.g., createMcpHandler(buildServer)), where buildServer returns a new server each call.
