Why 8 tools beat 80.
An MCP server should expose as few tools as fully cover the job it exists to do — because tool-selection accuracy degrades as the candidate pool grows. Every tool definition you add spends context before the user's question is even read, and hands the model one more near-miss to choose between. Tool count is a cost that vendors have learned to market as a feature.
The number you're being sold
Browse the wearable MCP servers and you'll see tool counts used as the headline spec. One connector in this space advertises around 135 tools. Others land in the teens. ghurt has 8.
Read that list top to bottom and the ranking looks obvious. It's exactly backwards, and it's worth understanding why — not because of who ships what, but because "number of tools" is now the standard way MCP servers are compared, and it is measuring the wrong thing.
Tool count is a supply-side number. It tells you how much API surface the vendor mapped into tools. It tells you nothing about whether the model can pick the right one — which is the only thing standing between your question and an answer.
What the research actually found
The clearest published result is the RAG-MCP paper (Gan & Sun, arXiv:2505.03275). They ran what they called an MCP stress test: vary the number of candidate MCP servers from 1 to 100, drawing distractors from a registry of over 4,400 real public servers, then ask the model to pick the right one for a task and execute it.
Three conditions, and the spread is not subtle:
| Condition | What it does | Selection accuracy |
|---|---|---|
| Blank Conditioning | Show the model every candidate at once — the default when a server dumps its whole tool list into context | 13.62% |
| Actual Match | Keyword-filter the candidates first | 18.20% |
| RAG-MCP | Semantically retrieve only the relevant candidates, then show those | 43.13% |
Showing the model everything scored 13.62%. Not "degraded" — closer to guessing. Narrowing the candidates first more than tripled accuracy and cut prompt tokens by over half. A second paper, Help or Hurdle? (arXiv:2508.12566), reaches a compatible conclusion: more tools and larger schemas consume context that the model needs for the actual task.
What it does establish is the mechanism: when a model must choose from many similar-sounding options presented at once, selection accuracy falls hard, and the fix is showing it fewer, better-matched options. That mechanism doesn't care whether the crowding comes from 100 servers or one server with 100 tools. The context is the same context.
Why it breaks
Three things compound, and none of them are model deficiencies you can wait out:
1. Every tool spends context before the question arrives
Tool definitions — names, descriptions, full JSON Schema for every parameter — are prepended to the conversation. A large server's definitions can run to tens of thousands of tokens. That budget is spent before your system prompt, before the conversation, before the user says a word. You are paying, in the currency the model reasons with, for tools this question will never call.
2. Similar tools poison each other
This is the one people miss. The problem isn't 80 tools — it's that at 80 tools, many of them resemble each other. get_sleep, get_sleep_detail, get_sleep_stages, get_sleep_summary, get_sleep_v2. The model's attention smears across the near-neighbours and it starts conflating them: right tool, wrong arguments; arguments borrowed from a sibling's schema; occasionally a tool name that never existed. Each additional tool doesn't just add an option — it adds a way for the other tools to be chosen wrongly.
3. The failure is silent and confident
A wrong tool call rarely errors. It returns *something*, the model narrates it fluently, and you get a confident answer built on the wrong data. For health data this is the whole ballgame: "your HRV is fine" sourced from the wrong date range reads exactly like "your HRV is fine" sourced correctly. You cannot see the difference from the outside. That's why this is a safety property, not a performance one.
How we picked 8
Not by minimalism as an aesthetic. The rule we used: one tool per question shape, not one tool per API endpoint.
Garmin, Oura, and Whoop expose wildly different APIs — different auth, different response shapes, different date semantics, different names for the same physiological idea. A one-to-one mapping of those endpoints into tools would produce something like 60–90 tools, three near-identical variants of every concept, one per vendor. That's the 80-tool server, and it's what you get by default when you let the upstream APIs dictate your interface.
Instead the provider differences are normalised underneath, and the tools are named after what someone actually wants to know:
get_sleep_data— how did I sleep, with stagesget_recovery_data— how recovered am I, with HRV and resting HRget_workout_data— what did I do, and how hardget_activity_details— go deeper on one session, lap by lapget_daily_summary— the day at a glanceget_heart_rate— heart rate over timeget_profile— who this account iscompare_devices— the same metric across every connected device
Eight tools, eight distinct jobs, minimal overlap for the model to trip over. A device is a parameter, not a family of tools. Adding a fourth provider tomorrow adds zero tools.
The corollary matters as much: because the surface is small, we can afford to spend real context on describing it. The server tells the model that Whoop strain is 0–21 rather than a percentage, that Oura's temperature reading is a deviation from your own baseline and not an absolute, that Garmin has no HRV-based recovery score so Body Battery is the analogous signal. That context is what separates a real answer from a plausible one — and a server carrying 135 tool definitions has no room left to say any of it.
How to evaluate a connector instead
If tool count is the wrong metric, here's what we'd actually check — including on us:
- Does each tool map to a question, or to an endpoint? Read the tool names. If you can see the upstream API's shape through them, the vendor pushed their integration problem down onto your model.
- Could you pick between two neighbouring tools from the descriptions alone? If you can't, the model can't either. It just won't tell you.
- Does it ship meaning with the numbers? Units, scales, personal baselines. A server that hands over
strain: 16with no scale is inviting a confident misreading. - Are there annotations?
readOnlyHint,destructiveHint. They tell the client what's safe to call. Their absence on a health server is a real signal — for the record, all 8 of ours are annotated read-only, because none of them can write anything. - Would the whole tool list fit comfortably beside your actual conversation? If the definitions alone are tens of thousands of tokens, that's your context, gone, before you've asked anything.
The short version
More tools is not more capability. It's more surface for the model to be wrong across, paid for in the context your question needed. The right number is the smallest set that covers the job — with descriptions good enough that picking between them is unambiguous.
If a connector's headline feature is how many tools it has, that's a claim about how much was built, not about what works. Ask what each tool is for. The good ones can answer that in a sentence each.
Common questions
How many tools should an MCP server have?
As few as fully cover the job it exists to do. There's no universal number, but the direction is well supported: selection accuracy degrades as the candidate pool grows, because every tool definition consumes context and adds another near-miss to choose between.
A server whose tools map cleanly onto distinct questions will outperform one that exposes every endpoint it can reach. Tool count is a cost, not a feature.
Does adding more tools make an AI agent worse?
Beyond the point where tools stop being distinct, yes. In the RAG-MCP stress test the candidate pool was varied from 1 to 100 servers drawn from a registry of 4,400+. Showing the model everything at once ("blank conditioning") gave 13.62% selection accuracy; retrieving only relevant candidates first gave 43.13%, with over 50% fewer prompt tokens.
The failure isn't that models can't use tools — it's that they can't reliably pick the right one from a crowded list of similar-sounding options.
Why do MCP servers advertise large tool counts?
Because it's easy to measure and looks like capability on a comparison table. It usually reflects an API surface mapped one-to-one into tools rather than a set of jobs anyone actually asks about. It describes what the vendor built, not what you get.
Isn't 8 tools just a limitation you're rationalising?
Fair question, and partly yes — it is a real constraint. Fewer tools means less granularity, and if you want a specific vendor endpoint we don't expose, a bigger server genuinely serves you better. We're not neutral here.
What makes it a choice rather than a shortfall is where the work went: the provider differences are normalised underneath, so a device is a parameter rather than a family of tools. That's why adding a fourth provider would add zero tools. The sources are linked above — the argument should stand on those, not on us.
Doesn't tool retrieval (RAG-MCP) solve this anyway?
Partly, and it's the right direction — that's the paper's whole point. But note that even with retrieval, accuracy in that benchmark was 43.13%, not 95%. Retrieval mitigates crowding; it doesn't make it free. The paper also notes retrieval precision itself degrades on very large registries.
It's also not something you as a user control today — it depends on the client. A server that's well-scoped in the first place doesn't need rescuing.
What about MCP prompts — do those count?
They're a different mechanism and they don't crowd tool selection. Prompts are surfaced in the client UI for a person to pick, not chosen by the model mid-reasoning, so they don't add near-misses to the model's decision. They're a good way to ship "here's a question worth asking" without spending your tool budget.