A YC company launched today with a line I agreed with immediately: give an agent a few tools and it can't do the job, give it too many and it grabs the wrong one.
We learned that the expensive way.
In August, our agent's in-product operator ended a customer task three times in a row, in about three seconds each, saying it had no callable tools. We pulled the context snapshot for the turn. It had 63 tools declared. 56 of them came from one MCP server: our own product's.
The plumbing was fine. The model was drowning.
The problem is real, and it is measured
This is not an Aimdoc quirk. Anthropic's own numbers on the Advanced tool use post say a modest five-server setup of 58 tools consumes about 55K tokens before the conversation starts, and that they have seen tool definitions alone consume 134K tokens. Their tool search documentation states it plainly: Claude's ability to pick the right tool degrades once you exceed 30 to 50 available tools.
The research says the same thing from the other direction. A May 2026 paper, How Many Tools Should an LLM Agent See?, found that presenting an adaptive shortlist instead of a fixed list of five tools raised downstream selection accuracy from 87.1% to 93.1%, with the biggest gains on medium-difficulty queries (60.9% to 76.8%).
Every B2B SaaS company that connects its product to an agent runs into this within a week. A real product MCP server has dozens of tools, because a real product has dozens of things you can do to it. The agent gets all of them on every turn and starts guessing.
Three good answers, all with the same blind spot
The industry has converged on three fixes. All three are good. We use pieces of all three.
Tool search. Load the catalog, but only expand the definitions the model asks for. Anthropic reports that on MCP evaluations this took Opus 4 from 49% to 74% accuracy and Opus 4.5 from 79.5% to 88.1%, with an 85% reduction in tokens. See Advanced tool use.
Code execution over MCP. Present the servers as code APIs and let the model write a program instead of calling tools one at a time through its context. Anthropic's Code execution with MCP post shows one workflow dropping from 150,000 tokens to 2,000.
Handoffs. Split the work across specialist agents, each with a small tool set. The OpenAI Agents SDK frames it as separate agents for order status, refunds, and FAQs rather than one agent holding everything.
Tool search solves count. Code execution solves intermediate results. Handoffs solve specialization.
Here is the blind spot: all three keep the tool as the unit of work. The model is still choosing tools. It is just choosing from a shorter list, or writing the choice as code, or choosing after a transfer.
Your customer never asked for a tool. They asked for the report.
What we do: change the unit
Aimdoc runs a single agent for a company's customers, on the website, inside the product, over email, and through a public gateway for other agents. That agent can be connected to the company's own product MCP server, plus a CRM, plus whatever else the company plugs in. So we had to make tool scale work on a conversational surface where a wrong guess is visible to a customer.
Four decisions, in the order we made them.
1. No tool schemas in the conversation
The conversational turn never sees an MCP schema. It sees a catalog: the name of each connected system and a one-line description of what it can do. That is enough to route. It is not enough to hallucinate a call.
2. A scoped handoff for in-product work
When the agent decides a task needs the product, it hands off to a product-mode executor. That executor gets the full schemas for the connected server, a navigate tool, and a stop tool. Nothing else. No page DOM, no CRM, no scheduling. When it finishes, its transcript is compacted and control returns to the conversation.
This is the handoff pattern with one difference: the executor exists only for the duration of the task. There is no standing "refund agent." There is a mode the agent enters and leaves.
3. Skills decide which tools reach the conversation
A tool only enters a conversational turn because a skill references it. A skill is a customer-authored instruction set for a situation: "when a signed-in user asks about billing, use these two tools." That skill gates the tools. Without a skill, the tool stays behind the handoff.
This turned out to be the single biggest lever. Customers do not scope tools. They describe situations. The situation scopes the tools.
4. Services: the outcome is the unit
Then we went one step further, and this is the part that changed our product.
A service is a named outcome defined on top of the product: a weekly reorder forecast, an account audit, an onboarding-completion check that does everything not gated behind an external login and returns a list of what is left. Each service carries a tool allowlist, a credit budget, a kill switch, and a log of every run.
When a customer asks for the forecast, the agent does not pick from 56 tools. It picks one service. That service runs with the four tools it is allowed to use. Tool selection is no longer a model problem at the moment of the request, because the person who defined the service already made the selection, once, with the run log to prove it worked.
Services also run without a request. On a schedule, or when a product event fires. And they can carry a price, sold by the agent through the company's own Stripe account. A service is a unit of work the customer can understand, the agent can route to, and the company can bill for.
That is the answer we have to "too many tools." Not a shorter list. A different thing to choose from.
Where this differs from a CLI
The company that launched today turns your product into a CLI so an agent can drive it, and argues that a pre-built, verified command beats a raw tool. We agree with the second half. A service is also pre-built and verified.
The difference is who is on the other end.
A CLI presumes the calling agent has a shell. Today that means a coding agent on a developer's machine. That is a real and growing audience, and it is not the audience most B2B SaaS companies sell to. Their customers show up in a chat window, in the product, in an email thread, or through an assistant like Claude. Those surfaces speak tool calls and services, not shells.
We built for the customer who will never open a terminal. Their agent, or our agent on their behalf, asks for the outcome. The service delivers it.
What we are not claiming
- Services do not make the model smarter. They move the selection problem to design time, where a person and a run log can check it.
- The long tail still exists. A request no service covers goes through the handoff to product mode with full schemas, and there we would use tool search if a connected server were large enough to need it.
- Fewer tools per turn is a necessary condition, not a sufficient one. A badly described tool is still a badly described tool.
- We have not solved this for every customer. We have solved it for the ones whose customers keep asking for the same outcomes, which turns out to be most of them.
The short version
Tool search shortens the list. Code execution hides the list. Handoffs split the list.
Services replace the list with the thing the customer actually wanted.
If you are wiring an agent to a product MCP server and watching accuracy fall as the tool count climbs, the fix might not be a better way to choose a tool. It might be to stop making the model choose one at request time at all.
Want to see it working? Read how the agent inside your product does the work, define your first service, or book a demo.