How to Set Request & Response Size Limits for MCP Servers

There are two size problems in MCP traffic, and they hurt in opposite directions.

Inbound: a tool call is just JSON, and nothing in the protocol stops that JSON from being a 200 MB body, a string the size of a novel, or an object nested 5,000 levels deep. Payloads like that are how services get crashed or ground to a halt — sometimes maliciously, sometimes by an agent that decided to inline an entire dataset as an argument.

Outbound: a tool result can be enormous — a query that returns 80,000 rows, a file read that returns megabytes. All of it lands in your model’s context window, degrading quality and multiplying token cost, when the model needed twenty rows.

MCP Trail caps both directions per server: request size limits enforced before expensive work happens, and a response size limit with a choice of blocking or truncating.

Step 1: Create your free MCP Trail account and add a server

Sign up at app.mcptrail.com and route a server through the gateway. Sane request limits are already enforced by default — you’re tuning, not building.

Step 2: Review the request size limits

Open the server under Guardian servers → Security tab → Request limits. The Request size limits card covers the inbound direction:

• Max request body (default 4 MB) — checked before JSON parsing, so a giant payload is rejected cheaply
• Max JSON nesting depth (default 64) — stops parser-abuse via deep nesting
• Max string size inside arguments (default 512 KB)
• Max array length (default 50,000 items) and max object keys (default 10,000)

Defaults suit most servers. Tighten them for servers whose tools should only ever receive small arguments — a search tool has no business accepting half a megabyte of “query”.

Step 3: Choose a response size policy

The same card configures the outbound direction, with three modes:

• Off — results pass through whatever their size
• Block — oversized results are rejected with an explicit error; the model is told the result was too large instead of receiving it
• Truncate — the result is cut to the cap with a clear marker, so the model gets the head of the data and knows it’s partial

Truncate is the pragmatic default for read-heavy servers: agents keep working, contexts stay bounded. Block fits when a partial result would be misleading — better to force a narrower query than to let the model reason over a silently incomplete table.

Step 4: Verify both directions

Inbound: send an oversized argument from the playground and confirm the explicit rejection. Outbound: call a tool that returns a large result and check that it comes back truncated (with marker) or blocked, per your mode. Both events are recorded in the Audit log.

FAQ

Why check the body size before parsing?

Because parsing is the expensive part. Rejecting a 200 MB body after parsing it defeats the point — the gateway refuses it on arrival.

Will truncation break my agent’s answers?

It bounds them. The truncation marker tells the model the result is partial, and a competent agent responds by narrowing its query — which is usually the behavior you wanted anyway. Pair with response optimization and token tracking if context cost is the bigger concern.

Do these limits protect against malicious clients or just clumsy agents?

Both — the caps don’t care about intent. Flood-shaped abuse is also bounded by the rate limit, which works alongside these.

Are the limits per server?

Yes — each server has its own caps, so a document-processing server can accept big payloads while your database server stays strict.

Related Articles

• How to Rate-Limit MCP Tool Calls
• MCP Token Optimization
• How to Validate MCP Tool Arguments with JSON Schema
• How MCP Trail Guardian Maps MCP Threats to Real Controls

Unbounded payloads are an outage with a timestamp you haven’t met yet. Create your free MCP Trail account and put numbers on your limits.