Search the full OpenRouter documentation to answer "how do I…" questions with correct, current API usage. Each result includes a "View docs" link to the source page; if a result is marked truncated or you need the complete page, fetch that link or share it with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look up in the OpenRouter docs, e.g. "stream responses" | |
| max_results | No | How many doc sections to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond those: each result includes a 'View docs' link, and truncated results should be handled by fetching the link or sharing it with the user. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and then provides result-handling behavior without wasted words. Every detail earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple documentation-search tool, the description fully covers how to use results, including what to do with truncated entries. There is no output schema, but the description compensates by explaining the link-sharing behavior, making the tool effectively complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description does not add much parameter-specific meaning beyond the schema, which is acceptable because the schema carries the load. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: searching the full OpenRouter documentation for how-to questions with correct, current API usage. It also clarifies the intended purpose distinctly from surrounding tools because no sibling tool provides documentation search. The use case is immediately recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool: to answer 'how do I…' questions about OpenRouter API usage. It does not explicitly mention alternatives or exclusions, but no other sibling tool covers documentation search, so the guidance is contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly differentiated by resource and action: the eight list-* tools each target a distinct view (models, endpoints, rankings, apps, providers, presets, tasks, benchmarks), and cross-references between them reduce mis-selection. A few mild boundaries exist—list-models and list-benchmarks both include benchmark data, and install-ori-harness vs spawn-ori-eval are both Ori recipe tools—but their detailed descriptions mostly resolve these.
The naming is overwhelmingly consistent with a verb_noun pattern using the same prefix set: generate-, get-, list-, send-, along with install-, spawn-, search-, and transcribe-. The only deviation is ping, which is a standard bare health-check tool and does not follow the verb_noun convention.
At 22 tools, the set feels heavier than the ideal 3-15 range, though each tool is arguably purposeful given the broad surface: model catalog, rankings, benchmarks, presets, generation, audio, image, docs, uptime, credits, and Ori workflows. The variety justifies the size to some extent, but the sheer number puts it in borderline territory.
Core workflows are well covered: model discovery (get-model, list-models, list-model-endpoints), generation (send-message, generate-image, generate-speech, transcribe-audio), observability (get-credits, get-generation, get-endpoint-uptime-history), and docs. Notable gaps include no create/update/delete for presets and no persistent provider configuration methods, but these are workable since presets are dashboard-managed and providers can be pinned per request.
