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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds non-obvious behavior beyond them: the call performs no UI action ('opens nothing by itself'), returns procedural steps rather than data, and exists because 'BookingKoala has no public, documented REST API'. That justifies the browser-tool handoff and is consistent with openWorldHint=false.

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 operative behavior is front-loaded in the first two sentences, but filler like 'from ChatGPT, Claude or any AI agent' and the fragment-style API note ('BookingKoala's official API: BookingKoala has no public...') add noise. The phrase 'Returns how to do it in BookingKoala' requires re-reading to parse.

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 zero-parameter, no-output-schema guide tool with full annotation coverage, the description supplies the essential facts: what it returns, that it is inert, and which tools execute the action. A note on the shape or length of the returned steps would make it fully complete.

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?

The schema declares zero parameters with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no scoping inputs are needed, though it never states that explicitly.

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?

Despite the name suggesting a data read, the description explicitly states the tool 'Returns how to do it in BookingKoala step by step (screens, buttons, fields) and opens nothing by itself', which tells an agent what actually comes back. It also redirects execution to the cotlet_browser_* siblings. It does not differentiate against same-domain siblings such as bookingkoala_cancel_booking or get_booking, keeping it short of a 5.

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?

Usage is implied ('in the user's own BookingKoala account') and a follow-up path is prescribed: 'then do it with the cotlet_browser_* tools in the user's BookingKoala Cloud Browser'. There is no explicit when-not guidance or mention of alternatives such as list_bookings, so an agent must infer routing.

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