Repository navigation
Codex refuses ?codemode=false: tools/list has more than its 2,048-tool cap #262
Description
Codex can't load the direct-tool surface (/mcp?codemode=false). It refuses any MCP server whose tools/list returns more than 2,048 tools, and drops the server at startup:
codex_mcp::rmcp_client: MCP server startup failed server_name="cf-stg-direct"
error=tools/list exceeded the catalog limit of 2048 items
The model then reports that none of the server's tools are available.
Repro
Codex CLI 0.157.0, logged in to https://staging.mcp.cloudflare.com/mcp?codemode=false:
codex mcp add cf-stg-direct --url "https://staging.mcp.cloudflare.com/mcp?codemode=false"
codex mcp login cf-stg-direct
RUST_LOG=codex_mcp=debug codex exec "Call the cf-stg-direct MCP tool accounts_list once."The result is the same with and without Codex's code_mode and mcp_2026_07_28 features.
Scope
- With the Forge catalogue (feat: build every API artifact from Forge in a daily container and serve mcp-tools.json directly #247),
?codemode=falselists 2,905 tools (docs, whoami and 2,903 endpoints). - Production's current catalogue is larger: about 3,661 tools.
- The default Code Mode server (
/mcp, four tools) is unaffected. - OpenCode v2 loads the full catalogue and drives it through its own Code Mode, so the problem is the cap, not the catalogue's shape.
Activity
martinmetzmacher commentedon Oct 16, 2026
Reproducing this from a second client with a different failure mechanism — worth separating from the catalogue cap, because it also bites clients that don't cap tool counts.
Client: Hermes Agent (macOS), MCP SDK 2.0.0 over
httpx2, production endpointhttps://mcp.cloudflare.com/mcp?codemode=false, OAuth.Observed:
initializesucceeds.tools/listreturns 3,763 tools as one SSE event of 3,663,834 bytes.httpx2enforces a hardDEFAULT_MAX_EVENT_SIZE_BYTES = 1024 * 1024per SSE event, and the SDK builds its reader without an override (EventSource(response)inmcp/client/streamable_http.py), so parsing raisesSSEError: Server-sent event exceeded the 1048576 byte limit.except Exceptionin the same module, so the caller only seesMCPError: SSE stream ended without a response— which reads like a transport or auth failure rather than a payload-size one.Not the token, not the endpoint: the identical request over raw HTTP returns
200with the complete 3.6 MB body in ~0.4 s, and the same client works against/mcpin Code Mode (4 tools, sub-second).Suggestion: paginating
tools/listwith anextCursorwould fix both failure modes at once — clients with a catalogue cap (#262) and clients with a per-event size cap (this one) — and would let both stream the catalogue in bounded chunks. In the meantime,logging.getLogger("mcp.client.streamable_http").setLevel(logging.DEBUG)surfaces the swallowedSSEErrorand names the real cause.Confirming the diagnosis from my side: raising the client's per-event cap to 64 MiB loads all 3,763 tools, which then call the API correctly.