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

Annotations already declare readOnlyHint=false and openWorldHint=true, but the description adds the key context that no bookings are returned here, only a code is dispatched to an external channel, and that the downstream artifact (contact_proof) is minted by the follow-up call. It leaves unaddressed the practical consequences of non-idempotency, such as repeated calls sending repeated codes or how long a code stays valid. Strong but not exhaustive on side effects.

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 sentences, both load-bearing, with the primary action front-loaded before the handoff and the account carve-out. The grammar of the opening clause ("the mobile number or email a person's bookings were made with") is clumsy enough to cost a beat of comprehension, but nothing is padding.

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 the return shape need not be spelled out, and the description instead spends its space on the multi-step flow and the GLØDI-account exclusion, which is the right allocation. What is missing is the operational envelope for an out-of-band code send: expiry, rate limits, and what a failed send looks like. For a two-param flow initiator that is a small residual gap.

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%, so both parameters are already documented in the schema, which makes 3 the baseline. The description restates the contact semantics (the number or address the bookings were made with, where the code goes) but adds little beyond the schema text, and it says nothing about the locale enum. Adequate, not additive.

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 a concrete action (send a code to the mobile number or email the bookings were made with) and the resource (a person's bookings), and explicitly frames it as step one of a two-step flow whose second step is confirm_with_code. That separates it from confirm_with_code and cancel_booking without the agent having to open either schema. The only weakness is the name mismatch (find_my_bookings actually initiates verification), which the description does correct.

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 both sides of the routing decision: use this when the bookings were made with a contact and you have no code yet, then hand off to confirm_with_code, which produces the contact_proof cancel_booking needs. It also names an exclusion, since bookings in a GLØDI account are managed on Min side after signing in. Both the when and the when-not are explicit.

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