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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: each result carries a booking_url that hands off to bestbus.me for seat selection and payment, plus a boarding-point map link — clarifying that this tool is search-only and purchase happens elsewhere. It still says nothing about result volume, one-way vs round-trip scope, or failure modes.

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, front-loaded with what the tool returns, followed by the downstream booking flow. Every clause carries information, though the booking-flow sentence is slightly long for what it conveys.

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 correctly spends its space enumerating return fields and the booking/map links, which is what an agent needs. Gaps remain around how many departures come back, whether passengers affects the returned fare, and one-way-only scope.

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 description coverage is 80%, so the schema already explains date range, English town names, language codes, and passenger bounds. The description only reinforces the route/date framing and the Thai-baht fare, adding no detail on the passengers parameter or how language affects results. Baseline 3 is appropriate.

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 — live intercity bus departures for one route and date — and enumerates the returned fields (departure time, company, boarding point, lowest fare). It does not, however, distinguish itself from the sibling buses_from or route_info, so an agent cannot tell from the description alone which one to pick.

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?

There is no explicit when-to-use guidance and no mention of the alternatives (buses_from, route_info) or how they differ from this route+date search. The usage is only inferable from the required from_town/to_town/date shape, which the schema already conveys.

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