ClickBus price/tax preview

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that data is live, which is useful, and the 'Dedicated preview URL 404/405' suggests potential failure conditions, but this is vague. It does not contradict annotations and provides marginal behavioral context.

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 description is very short and front-loaded with the core purpose ('Prices and installments'). However, the second sentence about the 'Dedicated preview URL 404/405' is cryptic and unexplained, making it feel under-specified rather than cleanly concise. It earns a middle score for brevity but lacks clarity.

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 tool with 5 parameters (including two enums) and no output schema, this description is insufficient. It does not explain the meaning or options for privacy_mode or response_format, nor what the return format looks like. The 'preview' nature is ambiguous, and the 404/405 note is unexplained. An agent would not know how to interpret results or handle edge cases.

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 60% (3 of 5 params have descriptions), so the bar for compensation is moderate. The description adds no parameter-level information at all; it does not clarify privacy_mode, response_format, or even reinforce the meanings of from/to/departure_date. It leaves the two enum parameters undocumented in both schema and description, offering no value 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 clear purpose: provides prices and installments from a live GET /api/v4/trips endpoint. This distinguishes it from sibling search tools that likely return full trip details, and the mention of 'preview' suggests a focused scope. However, the phrase 'Dedicated preview URL 404/405' is ambiguous and detracts from clarity.

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?

Provides no explicit guidance on when to use this tool versus alternatives like clickbus_search_trips or clickbus_search_trips_v5. The intended context (price preview) is implied but not stated, and there is no mention of exclusions or prerequisites. The cryptic '404/405' note seems to hint at failure behavior but is unclear.

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