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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Nothing is taken or stored; the order counts the same way again,' which usefully discloses idempotent, non-mutating behavior. It also names the returned artifacts (count, price_cents, the promise, quote_jws), adding context beyond the annotation.

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 cost/what-you-get is front-loaded in the first clause, then sendable-parameter options, then the non-storage promise. Dense with parenthetical asides but every clause carries information; only the count example borders on decorative.

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 8 params and no output schema, the description does the work of naming the return shape (count, price_cents, promise, quote_jws) and the non-persistence guarantee. It is reasonably complete for a free, read-only quoting tool, with the language params the main remaining gap.

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 63%, and the description compensates by clarifying the situational role of three params: brief (the whole order brief), text (per-word services), and item_count (labels), plus a concrete count example. It leaves language/source_language/target_language/passport_token unexplained, but those are partly covered by 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 specific verb+resource: what a human service order would cost, and flags it as free. Distinguishes itself from buy by positioning the quote as the pre-purchase step, though it never names a sibling tool explicitly to route the agent.

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?

Gives parameter-selection guidance ('Send the whole brief, or text (per-word services) or item_count (labels)') and hints at the downstream action ('pass max_price_cents to buy'), so usage context is implied. It never states an explicit when-to-use vs when-not condition or names an alternative tool for the quoting decision itself.

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