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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the payload is ticket type plus an optional link, and an unconfirmed booking yields no tickets with the call signaling that. It also notes the auth requirement (Cotlet API key with app access).

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 repeats itself: 'The tickets Your Bookings shows for a confirmed booking' is restated as 'Returns the ticket entries Your Bookings shows for a confirmed booking.' The redundancy and odd capitalization ('The tickets', 'Your Bookings') cost clarity, though the core content is front-loaded.

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 carries the burden of explaining returns, and it does so: ticket type plus link where offered, and the empty case for unconfirmed bookings. Combined with the auth note, an agent has enough to call it correctly; only the missing distinction from sibling retrieval tools holds it back.

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 coverage is 100%, and the single parameter booking_id is documented in the schema (with a cross-reference to list_bookings). The description adds no new meaning about the identifier, so the baseline 3 for a fully documented schema 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?

The description states a specific verb and resource: it returns ticket entries for a confirmed booking, including each ticket's type and a link where available. However, it does not distinguish itself from close siblings like omio_get_booking or omio_list_bookings, and the phrasing 'The tickets Your Bookings shows' is grammatically awkward.

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 gives one useful precondition (the booking must be confirmed, otherwise there are no tickets and the call reports so), which implies when the tool is meaningful. But it never says when to prefer this over omio_get_booking or omio_list_bookings, so usage against alternatives is left to inference.

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