Your agent has 142 tools. It picks by reading their descriptions.

01 / What breaks

Tool selection does not degrade gently as the tool count goes up.

Three things go wrong at once, and they compound: the schemas crowd out the context, the descriptions stop being distinguishable, and the most expensive model you have is the one doing the sorting.

The schemas alone fill the window

150 tools across five MCP servers is 30–60K tokens of pure schema overhead, loaded before the request has even been read. It is paid on every single call, whether one tool is relevant or none are.

Two tools look identical on paper

Faced with fifty near-identical descriptions, the model picks the one whose wording is closest to the request — or calls the right tool with the wrong arguments. A description is roughly half a bit of distinguishing signal per word, against the two or three needed. Baseline: 13.6% accuracy.

A frontier model is doing clerical work

You are paying frontier token prices, and waiting multiple seconds (~1.8 s to route), for a decision that is a lookup. The expensive part of the call is not the answer — it is choosing who should answer.

02 / The evidence · measured elsewhere

None of this is our number. All three are somebody else's.

Published benchmarks and production MCP deployments, each one linked. We would rather you checked them than took ours.

• 30–60K tokens of pure tool-schema overhead at 150 tools across 5 MCP servers — before the request is even read. MCP Context Bloat Crisis, 2026
• 13.6% → 43.1% baseline tool-selection accuracy, and where the best published retrieval method gets it to — still a coin flip on the hard cases. RAG-MCP, arXiv 2505.03275
• 0.3–0.5 bits of distinguishing signal per word in a typical tool description, against the ~2–3 bits needed to tell two tools apart. The 99% Success Paradox, arXiv

03 / The decision · one routed call

The closest match to the question is not the tool you want.

This is a single routed request, with the candidates and the numbers behind the choice. Incoming: "Where is my refund?" — 142 tools in scope, decided in 14 ms.

Semantic similarity on its own routes this to crm_search — the closest match to the words in the query, and the tool that fails 29% of the time. The routing score is built from what happened the last thousand times each of these was called for this org, which is information that exists in no tool description anywhere.

04 / The ladder · escalation

The fastest model call is the one you never make.

Five tiers, and the argument is not how quick each one is — it is how little traffic ever reaches the expensive end. The bottom rung is today's behaviour unchanged, which is what makes it safe to fall back to.

Roughly four of every five requests never reach a model. That is where the latency goes, and it is also why the cost figure moves — not because the model is cheaper, but because it is asked far less often.

Every other way of choosing a tool

Tool-RAG / RAG-MCP, semantic routers, MemTool, MCP Tool Search, fine-tuned tool-callers and MCP gateways each solve something real. The column that matters is where each one stops: the tool choice still comes from description text. Nucleus ToolCall routes on what actually happened the last thousand times this tool was called for this org — information that exists in no description, and that only the party holding the trace history can see.

06 / The targets · benchmark

What we are building to, stated as what it is.

ToolCall is in private alpha. The figures below are the architecture's design targets — they are not a published gold-set result, and we will replace them with real numbers as the alpha pilots complete.

These are design targets, not results. ToolCall is in private alpha; the figures above describe the architecture we are building to, measured against our own harness. We will publish gold-set numbers as pilots complete.

07 / Integration · architecture

Built for one job, and it slots in front of the one you have.

It never learns your tool names

The model is fine-tuned on the skill of picking from an outcome-annotated shortlist, not on any particular tool set. That is what makes it deployable on day one against private internal tools it has never seen.

It is one endpoint, not a framework

Point an OpenAI-compatible client at the Nucleus endpoint, or drop the SDK into an existing LangChain or LlamaIndex stack. Your agent code does not change shape.

from openai import OpenAI

# the only line that changes
client = OpenAI(base_url="https://nucleus.syntrox.io/v1", api_key=KEY)

resp = client.chat.completions.create(
    model="gpt-4o",
    tools=ALL_142_TOOLS,     # hand it everything; it forwards three
    messages=messages,
)

Private alpha

Put Nucleus ToolCall in front of your own traffic.

Alpha is a small number of teams with real multi-tool traffic and real failures to point at. If that is you, the first call is thirty minutes and mostly us asking what your agents are getting wrong. Book a call.

• Routing against your own trace history, not a generic benchmark
• An OpenAI-compatible endpoint — your agent code keeps its shape
• Runs inside your network, alongside the rest of Syntrox
• Bypass tier is today's behaviour, so the floor is never worse than now