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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description is what explains WHY a tool named cancel_booking is read-only: it only returns screens/buttons/fields and opens nothing by itself. The note that Bokadirekt's official API is read-only further justifies the browser-automation path, which is exactly the context an agent needs before calling it.

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 purpose before the hand-off instructions. The final 'Bokadirekt's official API: Yes, but it only reads' is tersely phrased yet earns its place by explaining the browser workaround; the platform list ('ChatGPT, Claude or any AI agent') is minor filler.

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 tool, the description covers what it returns (step-by-step screens, buttons, fields), what it does not do (open or change anything), and how to complete the task. The only gap is prerequisite state, such as login status or locating the specific booking beforehand.

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 tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. The description does implicitly explain that no booking identifier is supplied, since the interaction happens conversationally and in the browser.

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?

The description names the resource and action (cancel a booking in the user's own Bokadirekt account) and, importantly, clarifies that the tool does not itself cancel — it returns step-by-step instructions. That nuance separates it from the cotlet_browser_* siblings it hands off to, though the tool name alone would misleadingly imply the cancellation is performed here.

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?

It states the workflow (get instructions here, then execute with cotlet_browser_* in the Cloud Browser) and that nothing is opened automatically. It does not tell the agent what prerequisite state is needed — e.g. whether the booking must first be located with bokadirekt_list_bookings, or what to do if the user is not signed in.

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