DocsBridge tools
Start here
Build and run
DocsReference
The bridge tools
The first-party catalogue alone is 1,143 individual actions. The gateway advertises five tools instead, plus a sixth where a toolkit has a guide, and lets the agent search for what it needs.
Why a bridge instead of a list
The obvious design is to put every installed action in tools/list. It does not survive contact with a workspace that has actually connected things. The first-party catalogue is 1,143 actions across 102 connectors, and advertising all of them with their input schemas works out at roughly 73,000 tokens of the agent's context window, spent before it has read its first instruction and spent again on every session.
The name-only index of the same catalogue costs about 2,600 tokens. That is cheap enough that an agent can afford to orient itself once and then fetch the schema of the one tool it actually wants, which is what these tools are for. Both token figures are our own estimate from this catalogue rather than a benchmark.
every action, with schemas 1143 tools ~73,000 tokens
names only (list_toolkits) 1143 names ~2,600 tokens
the bridge itself 5 or 6 tools a few hundred tokensThe bridge tools
search_toolsquery, toolkit, project, limit- Find a tool by what you want to do, or by toolkit name. Each result comes back with its exact name, its toolkit, its project, its full input schema, and a kind of read, write or destructive that names which runner to call it with. A search may also name a toolkit nobody has installed yet, with a link the person can open to install it.
list_toolkitsproject- Every toolkit installed, with the project it belongs to and the names of its tools. Names only and no schemas, so it is cheap to call first when the question is what is reachable at all.
use_tooltool, input, project- Run one read-only tool by the exact name a search returned. It fetches, lists, searches or gets, and changes nothing. When the same toolkit is installed in two projects the call says so and lists them, and you pass one back.
run_tooltool, input, project- Run one tool that creates or updates something. Same arguments as use_tool; only the kind of tool it accepts differs. A name sent to the wrong runner comes back naming the right one.
run_destructive_tooltool, input, project- Run one tool that deletes or otherwise irreversibly removes something. Held apart from the other two so a client can always tell, before the call, that this one cannot be undone.
read_guidetoolkit, project- Read how one toolkit's tools are meant to be used together: the order to call them in, what a result means, and what to do first. Costs nothing and changes nothing.
What a call looks like
The agent searches, reads one schema, and runs one tool. Both are ordinary tools/call requests.
{ "method": "tools/call", "params": {
"name": "search_tools",
"arguments": { "query": "create an issue", "toolkit": "github" }
} }
{ "method": "tools/call", "params": {
"name": "run_tool",
"arguments": {
"tool": "github__create_issue",
"input": { "owner": "onvo-ai", "repo": "toolspoke", "title": "Rate limit on the releases API" }
}
} }A client that already knows a tool's real slug__action name can skip the bridge and call it directly through tools/call. The grant is checked either way, and the audit row records the underlying tool rather than the runner.
Why there are three runners
A tool is run through use_tool, run_tool or run_destructive_tool, and which one is decided by the kind on the search result rather than by the agent. They take identical arguments; a name handed to the wrong one is refused and told which to use instead, so the correction costs one round trip and needs no second search.
The split is what lets a client know, before it calls, whether a call can change anything. use_tool is declared read-only, so a host may run it without stopping to ask; run_destructive_tool is declared destructive and always asks. One runner covering all three could only ever have been declared destructive, which would have meant a confirmation prompt in front of every harmless read.
search_tools and list_toolkits are reads of the caller's own catalogue, so they cost no credit and write no audit row. So does read_guide. Only a call that reaches a provider is charged, and Billing and credits covers what each kind costs.
How results are ranked
Ranking is lexical by default. Tool names and descriptions carry the words people search with, so overlap does most of the work, and it is the only ranking that is guaranteed to be available.
A semantic pass is added on top when two conditions are both met: an OpenRouter API key is configured, and the catalogue has been backfilled with embeddings. The pass embeds the query and re-ranks by similarity, which is what lets a search for a phrase nobody wrote find the tool that does it. Neither condition is met on a fresh install until the backfill has run, so a new deployment ranks lexically until it does.
Setting SEMANTIC_SEARCH=off puts every search back on words alone, with no deploy. It is the kill switch for a provider having a bad hour.
Only tools and actions granted to the person behind the credential are searchable, suggestible or callable. A tool somebody else may use does not appear in your agent's search results at all. See Access control.