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

Annotations already declare readOnly, idempotent, closed-world; the description adds genuinely new behavior: rate limiting, per-eligible-vehicle fan-out, and that pricing mirrors seatac.co checkout exactly. It doesn't say what happens when no vehicles are eligible or how stale a quote can get, but the value-add over annotations is real.

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?

Three sentences, front-loaded with the verb and resource, then the return shape, then the rate-limit constraint. Nothing is redundant with the title or schema.

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 sketches the response (one entry per eligible vehicle, each with a booking_url for review and payment). Remaining gaps — what fields besides booking_url a quote contains, and fallback behavior when nothing is eligible — are minor for a quote tool.

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 100% and each parameter already carries a description with examples and ranges, so the description does not need to compensate. It adds only indirect hints ('per eligible vehicle', hourly charter implied via the hours param) and no format or constraint detail 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 specific verb and resource ('Get the live fare for a specific Seatac Connection ride') with scope qualifiers: per eligible vehicle, priced as seatac.co checkout. An agent can tell this is the pricing step as opposed to the sibling start_booking, which actually books.

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 explicit operational guidance: reuse a quote instead of re-requesting it because the tool is rate limited. It implies this is the step before booking (each vehicle carries a booking_url), but it never explicitly says 'call this before start_booking' or states exclusions.

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