Summary
MCP tool calls with payloads larger than ~16 KB raw, routed through a Cloudflare One MCP Server Portal, fail with TLS Alert: record_overflow ~700–900 ms into the request, before the upstream Worker handler runs. Direct calls to the same upstream Worker with the same body succeed.
Reproduction
- Configure an MCP Server Portal pointing at any upstream MCP server.
- Call any tool with content/argument >18 KB raw via the Portal endpoint.
- Observe: ~700–900 ms then connection terminated with
TLS Alert: level=2 (Fatal), description=22 (record_overflow).
The upstream Worker handler is never invoked. Confirmed via DEBUG_HEADERS middleware on a receiving Worker — for 18+ KB content, only initialize and a small notification arrive; the tools/call request never reaches the Worker.
Threshold (empirical)
| Raw payload size |
Result |
| 12 KB |
✓ pass |
| 14 KB |
✓ pass |
| 16 KB |
✓ pass |
| 18 KB |
✗ FAIL (record_overflow) |
| 20 KB |
✗ FAIL |
| 24 KB |
✗ FAIL |
Direct curl to the same upstream endpoint with the same 24 KB body + bearer succeeds (200 OK in 384 ms). Difference is the Portal in the path. |
|
Localisation
9-row repro matrix at https://github.com/bkalytta-wq/mcp-1433-repro (EVIDENCE.md) — same upstream Worker, same Access auth, same 'A' × 24576 payload — eight non-Portal setups pass at 24 KB, including a custom bridge built on @cloudflare/[email protected] against the same upstream. Only the Portal-routed row fails, and it fails at 18 KB.
| # |
Setup |
16 KB |
18 KB |
24 KB |
| 1 |
direct SDK on workers.dev (0.11.9, 0.12.3, pkg.pr.new/1434) |
✓ |
✓ |
✓ |
| 4 |
direct SDK on custom zone |
✓ |
✓ |
✓ |
| 5 |
direct SDK on custom zone + Access (service-token) |
✓ |
✓ |
✓ |
| 7 |
direct SDK + Hono + Bearer wrapper (mirrors my upstream) |
✓ |
✓ |
✓ |
| 8 |
own codemode bridge (@cloudflare/[email protected]) → row 7 upstream |
✓ |
✓ |
✓ |
| 9 |
Cloudflare One MCP Server Portal → my upstream |
✓ |
✗ 869 ms |
✗ |
The symptom is localised to the Portal hop. The specific mechanism inside the Portal is not identified — earlier framing of this issue hypothesised an agents-sdk header-encoding interaction (cf-mcp-message header on the Worker → DO hop). That hypothesis has been corrected per maintainer feedback: the Portal is not built on @cloudflare/agents, and there is no cf-mcp-message header in the Portal's gateway codebase.
Filing the symptom + matrix evidence here for visibility; root-cause investigation belongs with the Portal team.
Summary
MCP tool calls with payloads larger than ~16 KB raw, routed through a Cloudflare One MCP Server Portal, fail with
TLS Alert: record_overflow~700–900 ms into the request, before the upstream Worker handler runs. Direct calls to the same upstream Worker with the same body succeed.Reproduction
TLS Alert: level=2 (Fatal), description=22 (record_overflow).The upstream Worker handler is never invoked. Confirmed via
DEBUG_HEADERSmiddleware on a receiving Worker — for 18+ KB content, onlyinitializeand a small notification arrive; thetools/callrequest never reaches the Worker.Threshold (empirical)
record_overflow)curlto the same upstream endpoint with the same 24 KB body + bearer succeeds (200 OK in 384 ms). Difference is the Portal in the path.Localisation
9-row repro matrix at https://github.com/bkalytta-wq/mcp-1433-repro (
EVIDENCE.md) — same upstream Worker, same Access auth, same'A' × 24576payload — eight non-Portal setups pass at 24 KB, including a custom bridge built on@cloudflare/[email protected]against the same upstream. Only the Portal-routed row fails, and it fails at 18 KB.0.11.9,0.12.3,pkg.pr.new/1434)@cloudflare/[email protected]) → row 7 upstreamThe symptom is localised to the Portal hop. The specific mechanism inside the Portal is not identified — earlier framing of this issue hypothesised an
agents-sdkheader-encoding interaction (cf-mcp-messageheader on the Worker → DO hop). That hypothesis has been corrected per maintainer feedback: the Portal is not built on@cloudflare/agents, and there is nocf-mcp-messageheader in the Portal's gateway codebase.Filing the symptom + matrix evidence here for visibility; root-cause investigation belongs with the Portal team.