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

Annotations already establish this as a safe, idempotent read, so the bar is lower. The description still adds real behavioral context: billing is per second after a one-minute minimum, scheduled calls are priced as a fixed total, and results differ based on interpreter_id. It does not cover error behavior for unsupported pairs, but the pricing semantics are well disclosed.

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 definition is dense but front-loaded with the core pricing model, followed by the interpreter_id distinction. Every clause carries information, though the long single-sentence construction makes it slightly harder to scan than a split structure would be.

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?

With an output schema present, the description need not explain return formatting. It covers the essential pricing model, the two mode behaviors, defaults, and the interpreter-specific versus aggregate distinction. A note on unsupported pairs or when to call check_language_pair first would make it fully complete.

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%, so the baseline is 3. The description goes beyond the schema by explaining how mode changes the billing model (per-minute with minimum versus fixed total) and how interpreter_id changes the result from a pair-level range to an exact interpreter price, which is genuinely useful semantic framing.

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 states a specific verb and resource ('client price for a language pair') and immediately pins down the unit and scope (per-minute USD, all fees included). It is clear what the tool returns, though it does not explicitly contrast itself with siblings like check_language_pair or find_interpreters.

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?

Usage is implied by the pricing context and by the interpreter_id conditional, which tells the agent when to expect an exact price versus a typical range. However, there is no explicit 'use this when' guidance and no named alternatives, so the agent must infer placement in a booking workflow.

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