Agent capability search: find the missing tool without abandoning the task

The problem: the job stalls at the one capability the agent does not have

Most agent failures are not dramatic. The agent is halfway through real work and hits a plain gap. It needs a live price and has no price feed. It needs to read a PDF and has no PDF reader. It needs to check a claim before repeating it and has no way to check one. The context is loaded, the plan is sound, and the job stops anyway, because the one capability this step needs is not in the room.

What happens next is worse than the stall. The agent improvises. It estimates the price from memory, skims the document it could not really open, or restates the claim it never checked, and presents the result in the same confident tone as the parts it actually did. The person reading the output cannot tell which parts were done with a real tool and which parts were filled in. A stalled job costs time. An improvised job costs trust, and it costs it quietly, because nothing in the output marks the difference.

The usual fix does not survive contact with a real task. Nobody can predict, before a job starts, every capability it will need, and loading every tool that exists into every session is not a serious option either. The agent needs a way to find a capability at the moment the gap appears, using the need itself as the query, without leaving the task, opening a new account, or wiring up a new integration mid-run.

How a capability search runs

1. Describe the need. The agent states the missing capability in plain words: what it is trying to do, not a tool name it would have to already know. "Get a live crypto price." "Extract the text from this PDF." "Check whether this claim holds up."
2. Search the full set. capability_search matches that description against the full Zambo tool set behind the endpoint, not just the tools loaded on the default surface.
3. Pick the match. The search returns the tool that fits the description, with what it does, so the agent can confirm the match fits the step it is stuck on.
4. Call it in place. The agent calls the tool through the same MCP connection it already has. No new signup, no second endpoint, no pause for a human to install anything.
5. Keep the receipt. The call returns a verifiable AER-1 receipt at a public zambo.dev/run/ address, filed with the rest of the job's record, so the step the agent nearly improvised is the step with the clearest paper trail.

The numbers behind that flow are worth stating plainly. Zambo serves 153 tools behind https://zambo.dev/mcp, verified by tools/list on 2026-10-22 against the server named "Zambo Stack," version 4.1.0. Only 35 of those tools sit on the default surface an agent sees when it connects. The other 118 are not missing and they are not a paid surprise: they are one capability search away, on the same endpoint. Capability search is what makes a 153 tool set usable instead of theoretical, because the agent does not carry the catalog in its head. It carries the address of the catalog, and asks.

That also changes what a gap means. Without search, a missing capability is a wall: stall, improvise, or hand the job back to a human half done. With search, the same gap is a lookup, handled in seconds inside the run, and the task that survives is the original task, with its context and plan intact.

Proof: real agents already search mid-run

This is not a feature waiting for its first user. The count below comes from Zambo's public receipt stream at zambo.dev/api/receipts/recent, read at 20:49 UTC on 2026-10-22. Take the 100 most recent receipts at that moment and three facts fall out. First, those 100 receipts spanned just 48 minutes of live traffic. Second, they covered 20 distinct tools, so the traffic was varied work, not one tool looping. Third, 7 of the 100 receipts were capability_search itself: real agents, mid-run, stopping to find a tool they did not have and then carrying on. One receipt in fourteen, in an ordinary 48 minute window, was an agent solving the exact problem this page describes.

Read those numbers with the method attached, because the method is the point. Anyone can repeat the count: the receipt stream is public, capability_search calls are labeled by tool like every other call, and each receipt behind the count opens at its own zambo.dev/run/ address. The searches are in the same public record as the work they enabled.

And the record stays narrow on purpose. A receipt proves the saved result has not changed since it was saved. It does not prove the result was right, and this page will not pretend otherwise. What the receipt does is make the work checkable: which tool ran, when, and what it returned, in a form a reader can recompute for free at zambo.dev/verify with no account. For an agent that found a tool mid-task, that is the difference between "trust me, I handled it" and a record someone else can open.

Questions, answered