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

With no annotations provided, the description carries the full burden. It discloses that the tool is paid ($0.05 via x402) — critical for cost-aware agents — and that it returns both ranked candidates and price change/deprecation data. It explains the ranking order and the window parameter. It lacks details like pagination or limits, but the paid nature and output composition are clearly disclosed, exceeding baseline.

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 dense but each sentence adds value: purpose, usage, exclusions, and parameter examples. It is slightly long but front-loaded with the most important cost warning. No wasted words, but slightly involved with multiple clauses; still efficient.

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 tool with 6 params, no annotations, and no output schema, the description covers the core purpose, constraints, ranking, and additional output (price changes). It does not detail all parameters (limit, window_s default, payment_header) but those have schema defaults. It gives enough context for correct invocation, though a bit more on output structure would be ideal, but not critical.

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 description coverage is 0%, so the description must compensate. The description clearly explains the semantics of key parameters: max_prompt_price in USD per token, min_context in tokens, modality as substring. It also mentions window_s implicitly via 'in the window' and provides examples. This is strong compensational value for all critical parameters.

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 uses a specific verb ('answers') with a clear resource ('which model should I route to') and explicitly distinguishes itself from siblings by naming an alternative (anansi_price_current). It states the core function: returns cheapest models satisfying hard constraints ranked by prompt price, plus price changes/deprecations. This is highly specific and differentiated.

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 explicitly states when to use: 'when choosing or re-validating a routing target' and provides a clear exclusion: 'Do NOT use it merely to look up one model's price' with a named alternative (anansi_price_current, free). It also explains the inputs' semantics, giving concrete usage guidance.

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