@modelcontextprotocol/hono

Patch Changes

• A Server or McpServer now serves one connection at a time, and a Streamable HTTP server transport without sessions (sessionIdGenerator: undefined) serves one request. An app that uses one server object, or one stateless transport, for every HTTP request fails on the second request after this upgrade. Build the server and the transport per request instead.

  What keeps working without a change:

  • createMcpHandler(buildServer) and serveStdio(buildServer), where buildServer returns a new server on every call.

  • A handler that builds a new server and a new stateless transport for each request.

  • One server and one transport per session (a transport with a sessionIdGenerator).

  • Connecting a server again after close().

  • Client.

  What fails now, how it shows, and what to change:

  • One server object with a new stateless transport per request (const server = new McpServer(...) outside the handler, await server.connect(transport) inside it): the second HTTP request the process receives fails, and so does every later one. connect() rejects with an SdkError of code ALREADY_CONNECTED. If the handler closes the transport when the response ends, requests that arrive one after the other still work and a request that overlaps another one fails. Change: move new McpServer(...) and its registrations into the handler.

  • One stateless transport for every request (a transport built once with sessionIdGenerator: undefined): the second HTTP request fails. WebStandardStreamableHTTPServerTransport.handleRequest() rejects with Stateless transport cannot be reused across requests. Create a new transport per request., and NodeStreamableHTTPServerTransport.handleRequest() answers 500. Change: build the server and the transport inside the handler and connect them there.

  • createMcpHandler(() => server) with a server built once: a request that arrives after the previous response has been read to its end still works. A request that arrives while another one is being served is answered 500 with the JSON-RPC error -32603 (Internal server error); the reason is reported only through the onerror option. Change: pass a function that builds the server, as in createMcpHandler(buildServer).

  • One server object for every session: the initialize request of the second session fails with ALREADY_CONNECTED. Change: build a server per session.

  What the caller sees when connect() or handleRequest() rejects depends on the host. Express 5, Fastify and Hono answer 500. A plain node:http listener without its own error handling gets an unhandled rejection, which ends the process.

  The README examples of @modelcontextprotocol/express, @modelcontextprotocol/fastify, @modelcontextprotocol/hono and @modelcontextprotocol/node, and the handler examples in the JSDoc of WebStandardStreamableHTTPServerTransport and NodeStreamableHTTPServerTransport, now build a server and a transport per request.

• The license field of the package manifests is now Apache-2.0; the LICENSE file shipped in each package carries the full terms, including the MIT text for earlier contributions. No code change.

Patch Changes

• Read Streamable HTTP request bodies with a size limit. Every SDK-owned body read
  WebStandardStreamableHTTPServerTransport (and the Node transport built on it),
  createMcpHandler, toNodeHandler, and createMcpHonoApp's JSON pre-parse — now stops at
  4 MiB by default (the limit the legacy SSE transport already uses; the Express adapter and stdio
  bound their reads too) and answers 413 Payload Too Large before anything is parsed.
  toWebRequest (when it reads the Node stream itself) now rejects once the body exceeds the
  limit with an error whose name is 'RequestBodyTooLargeError' and status is 413, and
  toNodeHandler answers that with 413; hand-wired callers of toWebRequest should handle the
  rejection or pass a pre-parsed body, and isLegacyRequest reports such a request as non-legacy
  so the modern handler answers it. JSON-RPC batch arrays are limited to 100 messages; a longer
  batch is answered 400 / -32600 and none of it is dispatched.

  The limit is configurable with a new maxRequestBodySize option (bytes, default
  DEFAULT_MAX_REQUEST_BODY_SIZE = 4 MiB, exported from @modelcontextprotocol/server) on
  WebStandardStreamableHTTPServerTransportOptions, CreateMcpHandlerOptions (forwarded to its
  stateless legacy leg; isLegacyRequest and legacyStatelessFallback take the same option),
  CreateMcpHonoAppOptions, and ToNodeHandlerOptions / ToWebRequestOptions (the adapter's
  bound applies before the handler's, so raise both). The bounded reader is exported as
  readRequestBody for adapter authors. Hosts that pre-parse the body and pass it as
  parsedBody skip the SDK's read and its size limit entirely; the batch bound applies either way.

  createMcpHonoApp and createMcpExpressApp now run their Host/Origin validation before the
  JSON body parser, so a request from a disallowed Host or Origin with an invalid JSON body is
  answered 403 rather than 400, and its body is not read.

Patch Changes

• First beta release of SDK v2 with support for the MCP 2026-07-28 specification
  revision. See the migration guides for upgrading from v1
  (docs/migration/upgrade-to-v2.md) and adopting the 2026-07-28 revision
  (docs/migration/support-2026-07-28.md).

• Ship CommonJS builds alongside ESM. Each package now emits both .mjs/.d.mts
  and .cjs/.d.cts (via tsdown format: ['esm', 'cjs']), and its exports map
  adds a require condition so require('@modelcontextprotocol/…') works from
  CommonJS consumers. Output extensions are normalized across all packages
  (@modelcontextprotocol/core moves from .js/.d.ts to .mjs/.d.mts); the
  public import paths are unchanged.

• POSTs whose Content-Type media type is not application/json are now
  rejected with 415 Unsupported Media Type; the header is parsed instead of
  substring-matched. Previously any value merely containing the substring
  passed the check (for example text/plain; a=application/json), case
  variants were wrongly rejected, and the 2026-07-28 entry did not inspect
  Content-Type at all — requests with a missing or non-JSON header that used
  to be served on that path now also answer 415. Values with parameters
  (application/json; charset=utf-8, including malformed parameter sections
  like application/json;) continue to work. SDK clients always send the
  correct header and are unaffected.

  The new isJsonContentType(header) helper is exported for transport and
  framework-adapter authors — custom entries composing the exported building
  blocks (classifyInboundRequest, PerRequestHTTPServerTransport) must apply
  it themselves. The hono adapter's JSON body pre-parse and the client's
  response dispatch now use the same parsed-media-type comparison.