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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it reveals that operation prices differ by a factor of seventeen, and it explains that a quota_exceeded error indicates this number has run out. This goes beyond the annotations by tying the tool to rate-limit semantics and error interpretation, which is exactly the kind of context the dimension seeks.

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: the first states the core purpose, the second provides a concrete usage scenario and an error-interpretation tip. It is front-loaded with the primary function and wastes no words. Every sentence earns its place, and the structure is efficient and scannable.

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?

Given the tool's simplicity (no parameters, an output schema exists), the description covers all essential aspects: what data it returns (plan allowance, remaining quota, operation costs), when to use it (before expensive calls), and how to interpret a specific error (quota_exceeded). It is fully sufficient for an agent to know when and why to invoke it.

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 tool has zero parameters, so the schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate when there are no parameters to explain. The description does not need to elaborate on parameters, and it correctly avoids doing so.

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 clearly states what the tool does: it reports the organization's plan limits, remaining quota for the period, and the cost of each operation. This is specific and distinct from sibling tools like fetch_markdown or summarize_page, which are about fetching or summarizing content. It uses a concrete verb-resource pair ('get usage and prices') and leaves no ambiguity about its function.

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 advises using this tool before a run of expensive calls, gives a concrete example comparing fetch_markdown and summarize_page costs, and explains how to interpret a quota_exceeded refusal. This gives clear guidance on when to call it and how it relates to other operations, effectively routing the agent to the right context.

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