Scraping MCP tool count after tool search: what still costs

The pillar on scraping MCP token usage scores tool count as one row: more registered tools, more context spent before the first call. That row assumed one client behavior. Clients now differ. One defers definitions, one caps the count per request, one documents neither. The same 29-tool server is cheap in the first, tight in the second and unknown in the third.

This post re-weights the tool-surface row per client. All counts and client rules were checked on 2026-11-09. Client setup and troubleshooting are out of scope here.

The server side: counts as of 2026-11-09

Two notes on the rows.

• Firecrawl's full-profile count is higher than the pillar's 2026-10-27 figure of 25+. A rubric row quotes the count with its check date, or it goes stale within weeks.
• Jina's filters run before registration, so the client never sees the excluded tools. Its README states the cost plainly: each registered tool costs context tokens for its name, description and schema whether or not it is called. The tags are search, read, utility and rerank. The README's example:

https://mcp.jina.ai/v1?exclude_tags=rerank,utility

Claude Code: names load, definitions wait

Tool search is on by default. Only tool names and server instructions load at session start; a definition loads when Claude needs it. The docs state no fixed per-server tool cap. The practical limit is the context window.

What changes for the row:

• Count weighs less. 29 Firecrawl tools cost 29 names at start, not 29 schemas.
• Findability weighs more. Tool search reads descriptions, and only up to the shorter limit. Default cuts: 4,096 characters for server instructions and for tools that load upfront, 16,384 for a tool loaded through tool search. A server whose key words sit late in a long description is harder to find.
• Exceptions put the count back. ENABLE_TOOL_SEARCH=false loads every tool upfront. auto loads deferred tools upfront while their definitions stay under 10% of the context window. A server set to alwaysLoad: true loads all its tools every session. A tool can also ask for upfront loading through anthropic/alwaysLoad in its _meta.
• Model and platform matter. Models earlier than Opus 4 and Sonnet 4, earlier models on Google Cloud's Agent Platform, and Microsoft Foundry deployments hosted on Azure load MCP tools upfront.

Rubric weight in Claude Code with defaults: low for count, high for clear names and server instructions.

VS Code: a hard cap of 128 per request

The VS Code docs state that a chat request can have at most 128 tools enabled at a time. Above that, the request fails with "Cannot have more than 128 tools per request." The documented remedy is the github.copilot.chat.virtualTools.threshold setting. The page does not explain how virtual tools work and says nothing about deferred loading.

What changes for the row:

• Count is a share of a fixed budget. Firecrawl's full profile of 29 is about 23% of 128. Firecrawl plus Jina unfiltered is 41.
• Narrowing options weigh more. Jina's query filters and Firecrawl's smaller endpoints matter here in a way they do not under tool search.

Cursor: no stated rule

As of 2026-11-09, Cursor's MCP docs page states no tool limit and does not say whether tool definitions load upfront or on demand. It says tools listed under Available Tools are used when relevant. It documents disabling whole servers ("Disabled servers won't load or appear in chat") and admin tool allowlists. It does not describe toggling single tools on that page.

Not documented as of 2026-11-09. A rubric does not guess. The row is weighted as in a client that loads every definition, until Cursor's docs say otherwise. Older tool-cap figures for Cursor circulate in forum threads from 2025; they are not used here.

The re-weighted row

For the full scoring frame, see the rubric guide. For client-side limits on tool output rather than tool definitions, fetchmcp.net covers the MCP fetch token budget.

Where the small end of the table fits

Teneo Labs makes Live Web Data API, which appears in this table. The MCP server registers 2 tools. That keeps it near the bottom of the count row in every client above. It also does less: its MCP server reads one public page per call and does not render JavaScript, crawl sites, run searches or extract structured fields. A job that needs crawling, search or interaction needs one of the larger servers, and the per-client weights above then decide how much its count costs. The tool parameters are in the MCP docs.