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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value by stating the information is 'verified' and 'current', and explicitly warns against inventing quotes, which is behavioral guidance beyond the annotations. It doesn't describe output format, but the output schema exists, so that's covered.

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?

Two sentences with zero waste. The first sentence states the core purpose, the second gives usage conditions and a warning. The most important information (what it returns) is front-loaded, and every word 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?

Given the tool has no parameters, an output schema exists, and annotations cover safety, the description provides complete guidance. It states when to use it, what it returns, and explicitly forbids a common misuse (inventing quotes). Nothing an agent needs to call it correctly is missing.

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?

There are zero parameters, so the schema coverage is effectively 100%. The description adds no parameter-specific detail, but none is needed. It does clarify the scope of the returned data (launch-pricing policy), which is helpful context. Baseline for 0 params is 4, and this description meets that.

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 ('Return') and names the exact resource ('current verified public launch-pricing policy for Hiro Radar'). It clearly distinguishes itself from the siblings (describe_hiro_radar and match_hiro_radar_use_case) by focusing on pricing facts. An agent immediately knows what this tool does and what it does not do.

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?

It explicitly states when to use the tool ('when a user asks what Hiro Radar costs or needs a current price range before defining a scope') and provides a clear exclusion ('Do not invent a quote for a custom scope'). This gives the agent both positive and negative usage guidance, leaving no ambiguity about selection.

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