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

Goes well beyond the readOnlyHint annotation: it discloses that graduated ladders are summed band by band, that trial and once-only offers are never used, that providers without a matching tier are dropped (see warnings), that estimate:true signals a lower-bound price, and that prices exclude taxes and promotions. This is exactly the behavioral context an agent needs to interpret results.

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?

Front-loads the core purpose and ordering before diving into parameter detail, and every clause carries information. It is dense and repeats some schema defaults, so it is slightly over-long, but not wasteful.

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 no output schema, the description usefully explains what each quote contains (tier, ip_version, shared, estimate flag). A few return-shape details (e.g., field names, pagination via limit) are left implicit, but overall it is sufficient for correct invocation.

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 already 100%, but the description adds meaning the schema does not: what quantity counts as per pricing model (GB, IPs, ports, thousands of requests), how months interacts with quarterly/yearly billing, and the type-conditional defaults for ip_version and pricing_model. Substantial value beyond the schema.

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 precise verb+resource ('what quantity units cost at each provider selling type'), specifies the ordering ('cheapest first'), and maps to a concrete endpoint (GET /api/v1/quote). An agent can distinguish it from generic listing tools like list_providers or search_providers immediately.

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 implies when to use it through the extensive parameter/default rules, but never explicitly says when to prefer it over a sibling such as compare_providers, nor states any exclusion conditions. Usage is inferable but not spelled out.

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