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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context on top: positioning is included only when the owner bills it, the figure is not a quote and not binding, the result is a sentence to relay verbatim, and the tool returns a reason rather than a figure when no terms or rate are published. That failure-mode disclosure is exactly what an estimating tool needs.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries a distinct instruction (trigger, retry, response handling, disclaimer, failure mode). The phrasing is idiosyncratic in places ('the beacon works out the legs', 'Answer with its sentence') but no sentence is padding.

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?

For a five-parameter, read-only estimation tool with no output schema, the description covers what it returns (a sentence), what it returns on failure (a reason), how to recover, and the non-binding caveat. Nothing needed to invoke 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?

With 100% schema coverage the baseline is 3, and the description earns an extra point by explaining block_hours as a caller-supplied fallback estimate invoked only after the 'no block speed' response, and by noting positioning is folded in when the owner bills it. round_trip is left entirely to the schema, which is a minor remaining gap.

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 and resource — an approximate charter cost for one aircraft at the owner's published hourly rate — and goes further to explain how legs and block hours are derived. An agent can immediately distinguish this from siblings like request_trip or check_availability, which book rather than price.

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 an explicit trigger ('call it whenever the person you are helping asks what a trip would cost'), the required inputs (departure and arrival airports), and a precise retry path when the owner has no block speed: call again with block_hours. It does not name or rule out any sibling tool, so it stops short of full alternative routing.

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