MCP servers over HTTP: the SDK resource limits you now have to set

An MCP server that listens over HTTP is a web service, and until recently the official SDKs gave it few of the limits a web service normally has. Advisories published by the Model Context Protocol SDK maintainers between 30 September and 15 October 2026 add those limits to the TypeScript and Python SDKs. All five covered here are rated high on their SDK repositories, most can be triggered without credentials unless the server authenticates requests first, and two of the fixes need a change to your own code. If your team runs MCP servers over HTTP, this is the checklist.

What the advisories found

All of these affect servers reached over HTTP. Servers that only use stdio, which is how most local MCP servers run, are not affected by any of them.

No limit on body size or batch length. The TypeScript advisory GHSA-f897-62hf-6gxq, published on 15 October and rated high (7.5), says HTTP servers put no limit on the size of a POST body or on the number of messages in a JSON-RPC batch. Large requests could exhaust memory, and "one long batch could block it from serving anyone else." The advisory also notes that a general body parser such as express.json() is not enough, because it does not limit batch length. The fix sets a 4 MiB body limit and a 100-message batch limit by default.

The Python advisory GHSA-fmmv-w9g8-j3gc, published on 30 September and also rated 7.5, is the Python equivalent. The server read each body fully into memory before checking its size, growing memory by two to three times the body. The limit arrived in two steps, and the OAuth authorisation server routes (/token, /register, /revoke, /authorize) were only covered in the second.

One small request could still exhaust memory. A body limit does not bound how much work the server does with what is inside. The TypeScript advisory GHSA-46jr-4wx8-v453, also 15 October and rated 7.5, describes a single request within the 4 MiB default that exhausted the heap during validation, because the server put no limit on how many array elements and object keys it validated. Tools whose input contains an array or a record carry the most risk.

Sessions that never ended. The Python advisory GHSA-84m7-p3x7-pcfv, published on 30 September and rated high (7.5) there, found that a Streamable HTTP server in its default stateful mode never reclaimed sessions. They did not expire, a client DELETE left the entry registered, and the number of sessions was unlimited. Ordinary short requests could grow memory until a restart. Note that the entry for the same advisory in GitHub's global advisory database (CVE-2026-59951), published there on 15 October, rates it moderate, GitHub's label for medium severity, with a CVSS v4 score of 6.9 alongside the same CVSS v3 score of 7.5. Dependency scanners that read that database may show it as medium rather than high.

One client's messages delivered to another. The odd one out is a confidentiality bug, not a resource one. The TypeScript advisory GHSA-jm63-cq47-j5jp, rated high (7.7), affects @modelcontextprotocol/server 2.0.0 to 2.2.0. When several clients shared one stateless transport, or one server instance, responses were matched to connections by JSON-RPC id alone. SDK clients number requests from 0, so ids collide in normal use. The advisory says that until this release, the README examples for the Hono, Express, Fastify and Node packages showed the affected pattern.

Which fixes need more than an upgrade

This is the part that is easy to miss. The advisories are explicit about it.

Advisory	Upgrade to	Upgrade alone enough?
TypeScript body and batch limits	@modelcontextprotocol/sdk 1.30.1; server and node 2.1.0, hono 2.0.1	Yes, defaults apply
TypeScript validation memory	@modelcontextprotocol/sdk 1.32.0 or server 2.3.0	No: set maxToolInputElements
TypeScript shared instances	@modelcontextprotocol/server 2.3.0	No: one server per request or session
Python body size	mcp 1.29.1 or 2.1.0	Yes, unless you drive the transport directly
Python sessions	mcp 1.30.0 or 2.2.0	Yes, defaults apply; tune for small hosts

For the validation bug, the advisory says plainly that "upgrading alone changes nothing." The new maxToolInputElements option is off by default. It asks you to set it just above the largest input your tools need, and to lower maxRequestBodySize to what they need as well, because the element limit covers tool arguments only.

For the shared-instance bug, the upgrade makes the SDK refuse to be shared, so an affected app starts failing after upgrading: a second connect() rejects with ALREADY_CONNECTED. The fix is structural. Build a new server inside each request, use createMcpHandler() with a factory, or keep one server and transport per session.

The Python session fix brings defaults of a 1,800-second idle timeout and 10,000 sessions. The advisory is careful to say this "bounds retention rather than eliminating it", and it suggests lowering both, along with the body limit, on a small host. It also notes that authentication "limits who can open sessions, not how many a token holder can open."

What this says about MCP servers in production

Most of this is ordinary web-service hygiene: cap request sizes, cap batches, expire sessions, never share per-connection state. None of it is specific to AI. A likely reason it is surfacing now is that MCP servers moved quickly from local stdio processes to shared HTTP services, while defaults suited to the first case stayed in place.

Two patterns are worth noting. First, at least one fix adds a setting that is off by default (maxToolInputElements), a pattern we also saw in MCP SDKs' audience checks. A dependency scanner will mark the version as patched while the server stays exposed. Second, example code matters. When a README shows a single shared server instance, that pattern ends up in production. Teams that copied an example in the last few months should re-read their own setup against the advisory, not assume the upgrade caught it.

The advisories also differ in how they are recorded. GHSA-f897-62hf-6gxq lists no CVE, while its sibling advisories from the same day carry CVE numbers. If your process starts from CVE feeds, the advisory pages on each SDK repository are the more complete record. We made a related point about mixed protocol versions in stateless MCP in production.

What it means for engineering and security leaders

• Treat each HTTP MCP server as an internet-facing service, even when it sits on an internal network. It needs the same review as any other API: request limits, timeouts, authentication and capacity planning.
• "Patched" needs a definition. For two of these advisories, patched means upgraded and changed: one needs a new setting, the other a change to how the server is built. Ask owners to confirm both.
• Know which servers speak HTTP. stdio servers are out of scope for all of these. The inventory you need is the list of servers other people or machines can reach.
• A reverse proxy is a reasonable backstop. Two of the advisories name it as the workaround for body size if you cannot upgrade yet. It cannot fix batch length, element counts or shared instances, so it is not a substitute for the upgrade.

Practical takeaways

• List every MCP server your teams run over Streamable HTTP or SSE, with its SDK and version.
• Upgrade TypeScript servers to @modelcontextprotocol/sdk 1.32.0 or @modelcontextprotocol/server 2.3.0 (plus @modelcontextprotocol/node 2.1.0 or @modelcontextprotocol/hono 2.0.1 or later if you use them), and Python servers to mcp 1.30.0 or 2.2.0.
• Set maxToolInputElements on TypeScript McpServer instances, and lower maxRequestBodySize to what your tools actually need.
• Search your code for a server or transport created once at start-up and shared across requests. Replace it with one per request or per session.
• On Python servers, review session_idle_timeout, max_sessions and max_request_body_size against the host's memory, or use stateless_http=True where you need no session state.
• Put a body-size limit in the reverse proxy in front of each server as a second layer.

When MCP servers sit behind SpanDock's MCP gateway as connectors, the gateway checks every call before it calls the connector, including size limits on arguments and results and rate limits per computer and connector. That narrows what reaches a server through the gateway. It does not protect an endpoint that others can reach directly, so the upgrades above still apply. The MCP gateway is on the Premium and Enterprise plans.