abhigyanpatwari/GitNexus · error · Error

Content-Length ${contentLength} exceeds maximum allowed size

Error message

Content-Length ${contentLength} exceeds maximum allowed size (${MAX_BUFFER_SIZE} bytes)

What it means

The stdio transport caps any single framed message at MAX_BUFFER_SIZE (10 MB, set in compatible-stdio-transport.ts) to prevent unbounded memory growth. When a declared Content-Length exceeds the cap it discards the buffered input and throws, so one oversized or corrupted length header cannot exhaust the server's memory.

Source

Thrown at gitnexus/src/mcp/compatible-stdio-transport.ts:156

    const headerText = this._readBuffer
      .toString('utf8', 0, header.index)
      .replace(/\r\n/g, '\n')
      .replace(/\r/g, '\n');
    const match = headerText.match(/(?:^|\n)content-length\s*:\s*(\d+)/i);
    if (!match) {
      this.discardBufferedInput();
      throw new Error('Missing Content-Length header from MCP client');
    }

    const contentLength = Number.parseInt(match[1], 10);
    if (!Number.isFinite(contentLength) || contentLength < 0) {
      this.discardBufferedInput();
      throw new Error('Invalid Content-Length header from MCP client');
    }
    if (contentLength > MAX_BUFFER_SIZE) {
      this.discardBufferedInput();
      throw new Error(
        `Content-Length ${contentLength} exceeds maximum allowed size (${MAX_BUFFER_SIZE} bytes)`,
      );
    }
    const bodyStart = header.index + header.separatorLength;
    const bodyEnd = bodyStart + contentLength;
    if (this._readBuffer.length < bodyEnd) {
      return null;
    }

    const body = this._readBuffer.toString('utf8', bodyStart, bodyEnd);
    this._readBuffer = this._readBuffer.subarray(bodyEnd);
    return deserializeMessage(body);
  }

  private readNewlineMessage(): JSONRPCMessage | null {
    if (!this._readBuffer) {
      return null;
    }

View on GitHub (pinned to aac7515d2a)

Solutions

  1. Shrink the request: send file contents in chunks, batch tool params into smaller calls, or pass file paths instead of inline contents.
  2. Strip accidentally embedded payloads (base64 images, minified bundles, lockfiles) from the request body.
  3. If large messages are genuinely required in a private deployment, raise MAX_BUFFER_SIZE in a fork of compatible-stdio-transport.ts — upstream it stays 10 MB.
  4. Restart the session afterward: buffered input was discarded, so the stream cannot resume mid-frame.

Example fix

// before: one 40 MB request
await client.callTool({ name: 'context', arguments: { files: allFilesWithContents } });

// after: chunked / path-based requests under the 10 MB frame cap
for (const batch of chunk(allFiles, 50)) {
  await client.callTool({ name: 'context', arguments: { paths: batch.map(f => f.path) } });
}
Defensive patterns

Strategy: validation

Validate before calling

// Respect the transport's 10 MB frame cap before sending
const MCP_MAX_FRAME = 10 * 1024 * 1024;

function assertSendable(msg: unknown): void {
  const size = Buffer.byteLength(JSON.stringify(msg), 'utf8');
  if (size > MCP_MAX_FRAME) {
    throw new Error(`request body ${size} bytes exceeds MCP frame cap ${MCP_MAX_FRAME}`);
  }
}

Try / catch

try {
  await client.callTool(params);
} catch (err) {
  if (err instanceof Error && err.message.includes('exceeds maximum allowed size')) {
    // split the work instead of retrying the same giant payload
    for (const chunk of splitParams(params)) await client.callTool(chunk);
    return;
  }
  throw err;
}

Prevention

When it happens

Trigger: An MCP client sends a JSON-RPC request or tool-call whose framed body exceeds 10 MB — e.g. embedding a huge file's contents or a giant base64 blob in tool params — or a corrupted/garbage length header declares an enormous value; fuzzed stdin streams also trip it.

Common situations: Pasting an entire large file or dataset into a tool parameter; automated clients batching thousands of items into one request; proxies corrupting headers; hostile clients probing the transport's limits.

Related errors


AI-assisted analysis of abhigyanpatwari/GitNexus@aac7515d2a (2026-08-20). Data as JSON: /api/errors/66df9c68fb302a5a. Report an issue: GitHub.