MCP Tool-Count Convergence: Why Everyone Ships Around 8
Firecrawl ships 8 MCP tools, Bright Data ships 8 (with dataset add-ons), Apify exposes thousands via discovery. The 8-tool surface is converging because LLM agents struggle with longer tool lists at selection time. Specialization happens inside the 8, not by adding more tools.
Across the three major commercial MCP servers in 2026 — Firecrawl, Bright Data, Apify — there is a striking architectural convergence at the tool-surface layer. Firecrawl exposes 8 tools. Bright Data’s core MCP exposes 8 tools (with optional dataset-specific tools added). Apify’s MCP exposes thousands of actors but via a discovery-based interface that surfaces a small handful at any given selection step. The 8-tool surface is not a coincidence. It reflects what LLM agents can actually use at selection time without degrading performance.
The convergence has implications for how scraping infrastructure will compete at the MCP layer. Vendors that ship more than ~10 first-class tools force the agent to spend more reasoning tokens on tool selection, which reduces the agent’s effective budget for the actual work. Vendors that ship fewer tools force buyers to compose multi-step workflows that should have been a single call. The 8-tool number is approximately optimal for current-generation agent architectures.
The three approaches
Firecrawl: 8 fixed tools. scrape, batch, crawl, search, extract, map, plus async variants of scrape and crawl. Each tool has a clean, focused responsibility. The surface is small enough that an agent can hold all eight in working memory while deciding which to call, and the tool names are descriptive enough that selection is usually unambiguous.
Bright Data: 8 core tools + dataset add-ons. search, scrape_as_html, scrape_as_markdown, plus a handful of dataset-specific tools (LinkedIn, Amazon, others) that the buyer can selectively expose. The same convergence on a small core surface, with extensibility hidden behind buyer-configured add-ons that don’t pollute the default tool list.
Apify: discovery-based exposure. The Apify MCP server exposes a discover_actors tool that returns a structured list of actors matching the query, then individual run_actor calls for the selected actor. The functional surface is a small number of meta-tools rather than thousands of first-class tools. The agent’s selection step still operates on a small set; the discovery happens through a query.
All three approaches converge on the same outcome from the agent’s perspective: at any selection moment, the agent is choosing among ~8 alternatives. The architectural choices differ; the agent-experience constraint is the same.
Why 8
Three forces drive the convergence.
LLM tool-selection accuracy degrades with list length. Benchmarks consistently show that LLM agents pick the correct tool with high accuracy when given 5-10 alternatives, and accuracy degrades meaningfully past 15-20. The degradation is not linear — it’s roughly stable at small list sizes, then accelerates downward as the list grows. The 8-tool number sits in the comfortable middle of this range.
Token cost compounds with list length. Each tool in the exposed list consumes input tokens at every agent call. A vendor that exposes 50 tools instead of 8 forces the buyer to pay for 50 tool definitions every time the agent reasons about which tool to use. At scale (thousands of calls per workflow), the token cost adds up.
Cognitive load on the agent matters. Even at small list sizes, the agent’s reasoning about which tool to use is non-trivial. Smaller lists produce faster, more confident selections. The buyer-side experience (latency, cost) is better with smaller surfaces. Vendors optimize for this even when the underlying capability would allow a larger surface.
The 8-tool convergence is therefore a discovery the vendors have made independently about what works in production. It is not coordinated standardization. It is independently-arrived-at architectural choice driven by the same constraints.
What the convergence means for differentiation
If three competing vendors all ship 8-tool surfaces with overlapping tool names (scrape, search, extract), how do they differentiate?
Inside the 8. The competition moves from “what tools exist” to “how well does scrape actually scrape.” Success rate, latency, geographic coverage, anti-bot bypass effectiveness — all measurable inside a small fixed tool surface, all visible to agents at run time. The AIMultiple benchmark scored Bright Data first at 76.8% task success because its scrape tool actually works better against anti-bot defenses than the alternatives, not because it has more tools.
At the extension layer. Bright Data’s dataset-specific tools, Apify’s actor discovery, Firecrawl’s batch variants — all extensions to the 8-tool core that activate when the buyer’s use case requires them. The extension layer is where vendor-specific differentiation lives.
At the pricing layer. Per-call, per-credit, per-token, flat-rate — the 47-model pricing fragmentation shows up here too. Vendors compete on pricing model not just price level, and agents at sufficient cost-routing maturity will pick the pricing model that matches their workload best.
At the orchestration layer. Multi-step workflows that compose 3-5 tool calls into a coherent task. Vendors with composable tool surfaces (each tool returns structured data that flows naturally into the next tool) outperform vendors whose tools require translation layers between calls.
What this means for Apify publishers
For Apify Store publishers, the 8-tool convergence is a constraint on how actors get discovered through the MCP layer.
An Apify MCP buyer does not get exposed to all 20,000+ actors as top-level tools. The discovery flow surfaces 5-10 actors per query. The actors that surface are the ones with input schemas, descriptions, and output schemas that match the agent’s query best. Publishers whose metadata is clean and machine-readable surface; publishers whose metadata is poor stay invisible.
The implication is the same as the tag-discipline finding: the discovery surface punishes deviation from the convention and rewards clarity. The 8-tool convergence at the MCP-server level produces a similar dynamic at the actor-discovery level. The buyer-facing surface area is small at any selection moment, and the actors that occupy that surface are the ones whose machine-readable signal is best.
The longer-term shape of the MCP-driven scraping market will continue to favor:
- Small, well-defined tool surfaces. Vendors that resist the temptation to add more first-class tools.
- Strong differentiation inside the tool. Success rate, latency, coverage — the parts agents actually evaluate.
- Clean discovery for marketplace-pattern vendors. Apify-class platforms whose discovery surfaces stay tight at any selection step.
By 2027, expect MCP-tool-surface conventions to stabilize further around the 8-tool size with vendor-specific extensions. The vendors who attempt to differentiate by adding more first-class tools will discover what the converging trio already learned: more tools degrades buyer experience, not improves it.
Sources