Can Your AI Coding Agent Use a 3,600-Tool MCP Server? We Tested Four

An MCP server's catalog used to be a dozen tools. Crawlora's hosted catalog had 3,642 tools on October 19, 2026: one tool per API endpoint across hundreds of platforms, which is an unusual size and makes a good stress test. A client connecting to it has to decide how to learn what is there. It can read the list and declare every tool to the model, read it and defer the definitions behind a search step, or expose a search or script interface and never declare the tools at all. Which of those a client does decides whether web_search is reachable, how many tokens the first request costs, and whether a plain-language query finds it.

This post measures that on four clients, on one day, with the versions pinned. Where we could not test something, we say so.

How we tested, and what it can and cannot show

We ran four real clients, all installed locally: Claude Code 2.1.303, Codex CLI 0.156.1 and 0.163.0, Grok Build 0.2.111 and Pi 1.2.0. None of them was given a model account. Each was pointed at a scripted mock model that speaks the client's own protocol (Chat Completions, Responses or Anthropic Messages), logs every request body it receives and replays scripted tool calls. A logging proxy sat between each client and the Crawlora server and recorded every tools/list call and cursor.

• Server: https://mcp.crawlora.net/mcp, 3,642 tools at the time of testing on October 19, 2026, paged 1,000 per tools/list response (1,000, 1,000, 1,000, 642). We compared it with https://mcp.crawlora.net/mcp/family/web (9 tools) and https://mcp.crawlora.net/mcp/agent (3 tools).
• Queries, chosen by us: search the web, crawlora web search, web search brave, youtube video search, and the exact name web_search. The target was web_search.
• Token figures are request bytes divided by four, a rough estimate. One run per cell unless stated.

The limits matter, so they come first. A scripted model shows what each client sends and which tools its search step returns. It does not show whether a real model would reword a failed query, try another tool, or give up. We ran Claude Code against a non-Anthropic base URL, where it behaves differently from its first-party default. And this is one server, one catalog, five queries and one machine, not a benchmark of the clients.

Finding 1: do they read the whole tool list?

MCP lists tools in pages. A server returns a first page and a nextCursor; the client asks again with that cursor until there is none. Our server returns four pages.

Codex is the interesting row, and it changed during the day we tested.

Codex 0.156.1 read only the first page. It sent one tools/list with no cursor, got 1,000 tools plus a nextCursor, and never asked again. That is openai/codex#28858, open since June 18, 2026. We reproduced it in five runs with two model slugs. Everything after flashscore_news alphabetically, including web_search and every youtube_* tool, was unreachable.

Codex 0.162.0 fixed the cursor handling. We bisected with a local stub server of several pages: 0.156.1 through 0.161.0 request one page, and 0.162.0, 0.162.1 and 0.163.0 follow nextCursor. The 0.162.0 release notes list "Follow MCP tool pagination in legacy protocol mode" (PR #50035).

But 0.163.0 still stopped early on our server. Against the real endpoint, with the User-Agent masked so that our own Codex-specific workaround did not fire, four of four runs requested exactly three pages and never the fourth, although the third response carried a nextCursor. That is 3,000 of 3,642 tools. The fourth page holds web_search, youtube_search and yahoo_search; reddit_search is on page 3 and bing_search on page 1.

We did not find the rule. On synthetic stub servers the stopping point varied with page size: 8 pages of 3 tools were all read, 8 pages of 500 stopped after 5, 6 pages of 700 after 3, 4 pages of 1,000 after 3, and 4 pages of 1,500 after 2. It did not depend on description size or on timing (all pages arrived within 30 ms of each other). So treat "somewhere between roughly 2,000 and 4,000 tools" as an observation about our test, not as a documented limit. A server with fewer than a couple of thousand tools reads in full: a 5-tool stub was declared to the model whole.

Finding 2: what each client puts in front of the model

Reading the list is one question; what the model sees on turn one is another. We captured the first request body each client sent to the mock model.

From the largest to the smallest that is about 260 times. On the 9-tool family endpoint the same clients send much less: Claude Code's default request falls from 2.70 MB to 94 KB, and with tool search on from 178 KB to 46 KB. Codex 0.156.1 declared the 9 tools directly in 54 KB, against 884 KB for 1,000. Grok and Pi requests do not change, because they never declare MCP tools.

For Codex 0.163.0 we cannot give a comparable number for the big list. In a one-shot codex exec the first model request goes out before the 3,642-tool listing finishes, so it carried no MCP tools; a second request after a 20-second delay did not either. A 5-tool server was declared directly. We measured what 0.163.0 requests from the server, not what its model sees for a very large one.

Finding 3: can the model find the tool?

Clients that defer or search tools give the model a keyword search instead of a list. We ran the same queries through each client's search step and recorded where web_search ranked, on the full endpoint and then on /mcp/family/web.

Two details. Grok's numbers are after we reworded the web_search description on the server that same day to open with "Search the web for any topic or question"; before that, search the web did not return it in Grok's top 10. Pi's ranking did not move with the description, which suggests it scores on tool names; its miss on the exact string web_search may be tokenisation against the prefixed mcp__crawlora__web_search, which we did not confirm. Claude Code's ranking was unchanged by the reword.

Codex has no search step in the mode we observed. The tool is either declared or absent.

The fix that worked on every client: scope the server

Every client did better with fewer tools in front of it. Crawlora serves three views of the same catalog:

• /mcp: all 3,642 tools observed on October 19, 2026. Comfortable only where the client defers definitions behind search (Claude Code with tool search on), and incomplete in Codex.
• /mcp/family/<family>: one platform's tools, such as web (9 tools) or youtube (14). GET /mcp/family/ lists the 474 families. In Grok and Pi, web_search ranked first for plain-language queries here.
• /mcp/agent: three tools (search_tools, get_tool, call_tool) that reach every platform. Its search_tools ranked web_search first for search the web and crawlora web search when we called it directly.

For Codex we also changed the server: when a request carries Codex's User-Agent (codex-mcp-client/<version>), the full endpoint answers with the three-tool agent view. That keeps web_search reachable for every Codex version, including 0.163.0. It is a workaround for client behaviour, and we will remove it when Codex reads every page.

Advice by client, from these runs:

• Claude Code: the full endpoint works if you set ENABLE_TOOL_SEARCH=true; otherwise use a family or agent endpoint.
• Codex: use /mcp/family/<family> or /mcp/agent. On a server this size, do not rely on the full list, on any version we tested.
• Grok Build: use a family endpoint. The full endpoint connects, but a plain-language query can rank the tool you want outside the results it shows.
• Pi: use a family endpoint, or write the exact tool name into the script.

For server authors the pattern is the same: expose a small default surface and let people opt into more, rather than assuming the client will cope with the whole list.

What we could not test

• Real models. A scripted model cannot tell us whether a miss is recoverable in practice.
• Claude Code on Anthropic's own API. We ran it against a non-Anthropic base URL, where it declared every tool unless tool search was forced on; its first-party default may differ.
• Codex 0.163.0 with a very large list on turn one, as described above, and the rule behind its early stop.
• Other clients. Gemini CLI, GitHub Copilot CLI and OpenCode were not installed in this harness.
• Versions change weekly. Treat every figure as true for the version named on October 19, 2026.

Reproduce it

You need a client, a stand-in for the model and a way to see the traffic:

1. Run a local server that speaks your client's model protocol, logs each request body and replies with a short fixed answer.
2. Point the client at it with an isolated home directory, so your own config and credentials are not read.
3. Put a pass-through proxy in front of the MCP server and log each JSON-RPC method and whether params.cursor was set.
4. Connect the client with a bearer token and run a one-line prompt. Count tools/list calls, then read the first model request's size and tool names.
5. For search, script a call to the client's search tool with each query and record the rank of the target.

To check whether a client follows pagination without our server, build a stub that returns a few pages of one tool each and look for the second request.

Give your agent a smaller, faster tool surface

One API key, billed only on success. 2,000 free credits a month, no card.

Set up Crawlora MCPBrowse the API catalog

Sources

Related reading

• Best MCP Servers for OpenAI Codex in 2026 · Best MCP Servers for Grok Build in 2026 · Best MCP Servers for Pi in 2026: the per-client setup guides.
• Best Web Scraping MCP Servers for Claude Code in 2026 — Claude Code setup and server comparison.
• Best Web Search MCP Servers in 2026 — the same question across search servers.
• Give your AI agent live web data with MCP — how MCP works and how to connect in three minutes.