[rymalia]

collectBody() in src/mcp/server.ts buffers the entire request body before JSON.parse and schema validation, with no size limit:

for await (const chunk of req) chunks.push(chunk as Buffer);
return Buffer.concat(chunks).toString();

As a result, one request to qmd mcp --http can make the server hold an arbitrarily large body in memory, on every route that reads a body (/mcp, /query, /search and /metadata). The collections arrays on the MCP query and metadata tools and on the REST endpoints have no length limit either.

This is also where the memory advisories that npm audit reports for the pinned dependencies would be triggered: @modelcontextprotocol/server 2.0.0 (memory exhaustion during request validation) and zod 4.2.1 (memory exhaustion on oversized constrained collections). #1085 bumps the SDK, and zod is pinned on purpose (#382). Bounding the input in qmd itself limits the impact of both, whatever the dependency versions.

As far as I can tell, the SDK's other advisory, one HTTP client's messages delivered to another, doesn't apply: createMcpHandler(() => createMcpServer(store)) builds a fresh server and transport for each request.

Changes

• 1 MiB body limit on every collectBody() call site.
  • Counted per chunk while streaming, so a chunked upload with no Content-Length is bounded too.
  • Content-Length early-out: a declared length over the limit is rejected before anything is read.
  • 413 response: {"error": "Request body too large"} on REST, and a JSON-RPC parse error on /mcp (-32700, id: null), the same code as for unparseable bodies.
• The 413 reaches clients that are still uploading. Throwing out of the default async iterator destroys the request, so collectBody() now reads with req.iterator({ destroyOnReturn: false }) and drains the rest of the body after responding.
  • Old pattern: in a standalone probe, a client still uploading got EPIPE instead of the 413 in roughly 20–40% of 1–8 MB uploads, on Node 24.22.1 and 26.12.1.
  • Connection: close instead of draining: produced EPIPE/ECONNRESET at every size.
  • Drained form: delivered the 413 in every run: 200/200 on each Node version and 100/100 on Bun 1.4.4.
• At most 1000 collections per request (one constant).
  • MCP: .max() on the query and metadata schemas, so over-limit lists get an input validation error.
  • REST: explicit checks on /query, /search and /metadata, which return a 400 {"error": "Invalid field: collections (maximum 1000 items)"}.
• Behavior change: REST /query now returns a 400 for a non-array collections value, where it used to fall back to the default collections silently. This matches what /metadata already does.
• Docs: the README states the 1 MiB limit and the collections limit, and the changelog has an entry under [Unreleased] → Fixed.

REST searches is deliberately left alone, because #1002 already validates it with subSearchSchema (min 1, max 10).

Tests

All in test/mcp.test.ts:

• Fixed-length bodies: a body of exactly 1 MiB − 1 byte is accepted, and an over-limit body gets the 413 on /query, /metadata and /mcp, with the exact response bodies.
• Chunked upload with no Content-Length: gets the 413 on /query and /mcp. This is the only test that reaches the per-chunk counting, since fetch() always sends Content-Length for a string body.
• Over-limit collections: a 400 on REST /query and /metadata, and an input validation error on MCP query and metadata.

I checked that the tests fail without the change: removing the per-chunk check fails the chunked test, and removing the /metadata 413 handling fails the fixed-length test.

Known limits:

• The EPIPE race isn't tested. It doesn't reproduce under vitest (the old code passed 50/50 there), so it rests on the probe results above.
• Draining has no byte or time limit of its own. A client that keeps uploading holds the connection, but not memory, until Node's default request timeout. An explicit drain timeout could follow if you'd like one for servers reachable off-host.

Verification

• npx tsc --noEmit -p tsconfig.json: clean
• npx oxlint: 0 diagnostics
• npx vitest run test/mcp.test.ts (Node 24.22.1): 76 passed
• bun test --timeout 60000 --preload ./src/test-preload.ts test/mcp.test.ts (Bun 1.4.4): 76 passed
• Full suite (npx vitest run test/, Node 24.22.1): 1617 passed, 1 skipped
• Independent of feat(mcp): expose chunkStrategy on the MCP query tool and HTTP /query #1090 (chunkStrategy on MCP and REST). The two merge cleanly in either order, and with both merged test/mcp.test.ts passes 78/78.
• Merges cleanly with the open PRs that also touch src/mcp/server.ts or test/mcp.test.ts (fix(mcp): reject malformed REST /query searches with 400 (#998) #1002, fix(mcp): stream SSE responses from the HTTP adapter #1036, feat(mcp): opt-in compact response mode (QMD_MCP_COMPACT=1 / --compact) #1047, Export QMD MCP server factory #1057, feat(mcp): report document and embedding counts in HTTP health #1059); checked with git merge-tree. I placed the new code and tests in spots none of them change, so either merge order works.
• CI: everything passes except Bun (ubuntu-latest), which fails the same two SQLite heap-limit tests as the unrelated fix(deps): bump @modelcontextprotocol/server to 2.3.1 #1085 (doctor vector sampling … 32 MiB SQLite budget and legacy fingerprint adoption … 16 MiB SQLite budget, both asserting limitBinds under Bun on Linux). main passed that job on Bun 1.4.3; both PRs ran on Bun 1.4.4, because the workflow installs bun-version: latest. Neither PR touches the store or doctor code.