Bus price calendar

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior beyond that: days with no buses or not yet on sale are omitted rather than returned as errors, which prevents the agent from misreading a sparse calendar. It does not mention rate limits or pagination, keeping it short of a 5.

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 short sentences, front-loaded with what the tool returns, followed by the routing advice. No filler; every clause carries information.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. The description supplies the one thing neither structured field carries: the omission semantics of missing days and the sales-window caveat.

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 100% and all five parameters carry inline descriptions (origin/destination ids from mb_find_place, days default 30, seats, start_date default today). The description adds no parameter-level detail, so the baseline 3 applies.

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: 'Cheapest bus seat per day for a route.' An agent can immediately distinguish this calendar-style price lookup from mb_search_buses (actual itineraries) and from the flight/train calendar siblings.

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?

Explicitly gives the workflow ('Use to find the cheapest day, then mb_search_buses for that day') and names the alternative tool with the condition that selects it. It also warns that sales typically open about a month ahead, which tells the agent when this tool will return thin results.

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