ask_openrouter

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full transparency burden. It discloses that the call bills the operator's OpenRouter credit per token, that the result reports real dollar cost, that the tool is guarded and single-turn, and how effort and default model selection behave.

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 long but densely informative; every sentence contributes purpose, workflow, cost, or redirection. It is front-loaded with the core function before diving into model selection and billing details, and there is no filler.

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?

Despite having no output schema, the description covers return-cost reporting, billing, defaults, model selection prerequisites, and explicit alternatives among siblings. For a pay-per-token tool with many similar ask siblings, this is a complete operational picture.

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?

Schema coverage is 100%, establishing a baseline of 3, but the description adds meaningful parameter context: model selection should come from the live catalog with pricing, effort adapts to the chosen model's supported reasoning levels, and context_ref pulls saved context by key. This goes beyond the schema's own descriptions.

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?

States a specific verb and resource: 'Ask ONE model on OpenRouter', and clarifies it is a gateway to ~400 models from multiple labs. It explicitly differentiates from sibling ask tools by naming use cases: reaching models without a dedicated tool and comparing the same question across labs.

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?

Provides explicit when-to-use and when-not-to-use guidance: prefer dedicated tools like ask or ask_opus5 when one exists for the same model. It also gives a concrete workflow — call list_openrouter_models first, offer the ranked shortlist, then ask — and notes rerouting behavior for Grok and Kimi.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.