Why your agent only needs two tools

Connect twenty MCP servers to Claude or Cursor and something quietly goes wrong. Before you type a word, the client has already loaded every tool definition into the context window. For a typical setup that is tens of thousands of tokens of schemas your agent will mostly never use.

That cost shows up in three places. Every request is more expensive. Every response is slower, because the model reads all of it. And the agent picks the wrong tool more often, because it is choosing from hundreds of near-duplicates like list_issues, search_issues and get_issues across five apps.

Search first, then run

Toolrails gives your agent exactly two tools. search_tools takes plain words and returns the few actions that match, each with a short schema. execute_tool runs the one the agent picked. Nothing else is loaded until it is needed.

// 1. find it
{ "query": "file a bug in linear" }
→ linear.create_issue (needs linear.list_teams)

// 2. run it
{ "name": "linear.create_issue",
  "args": { "team": "WEB", "title": "Checkout fails on Safari" },
  "fields": ["id", "url"] }

Two calls instead of one sounds slower. In practice it is faster, because both calls are tiny. The search takes around 40ms, and the agent reads a few hundred tokens instead of ninety thousand.

The hard part is search

This only works if search finds the right tool. Keyword search fails constantly: an agent asks for "tickets" and the action is called list_issues. So we run keyword and meaning-based search side by side, merge the results, and return the steps an action depends on, so the agent does not have to discover them by failing.

An agent that sees five good options picks better than one that sees four hundred.

On our public test set of 1,840 queries, the right tool is in the top five 95.4% of the time. The set, the harness and the search library are all open source, so you can check our numbers against your own tools.

What changed for us

Our own agents got cheaper and more accurate on the same tasks. They also became safer to run, because every call now passes through one place where rules and injection checks apply. That turned out to matter as much as the tokens, and it is the subject of the next post.