Skip to main content
Reticle advertises 18 tools and ships 48. These two meta-tools are how your agent reaches the other 30 without paying for their schemas on every turn. reticle_tools discovers. reticle_run invokes. Together they cost two tool definitions instead of thirty.

Discovering what exists

Returns every tool with a one-line summary. A sample of what lives in the cold tail: The response also tells you which surface is active:
“Read once at daemon startup” is doing real work in that sentence. Setting the environment variable in a shell where a daemon is already running changes nothing, and the resulting “I set it and nothing happened” is very hard to debug from the outside.

Loading argument grammar

Summaries are enough to choose a tool, not to call one. Load the full parameters for the ones you want:
This is the point of the design. Schemas arrive when they are needed, rather than on every turn forever.

Invoking

Real response from an instrumented app, trimmed:

Start here, not with a snapshot

That reticle_capabilities output is the single best first call on an unfamiliar app. It is the app telling you what it considers testable: the elements worth driving, the signals that mean success, and the flows somebody already thought were important. Compared with snapshotting the page and guessing from element names, it is both cheaper and more truthful. auth:granted is what the app means by “logged in”, and no amount of looking at the DOM will tell you that.
Then drive the flow and see whether your error state actually works. Most do not, which is the point.
reticle_run returns whatever the invoked tool returns, unchanged. It is a transport, not a wrapper. So a tool that produces a verdict still produces one through run.
Last modified on August 14, 2026