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

Even with idempotentHint already present, the description adds concrete behavioral detail: replaying a valid confirmation is safe and returns the stored result. It also explains the meaning of status:confirmed/booked:true versus status:callback_pending/booked:false, which is crucial beyond the annotations.

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 dense sentences, all front-loaded with the most important trigger condition first. No filler, and every sentence adds distinct value: when to use, how to interpret results, and that replay is safe.

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?

The description covers the essential workflow: sourcing the code, interpreting the two possible status outcomes, and safe retry behavior. With an output schema present, return-value details are already handled, so nothing critical is missing.

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 0%, so the description must compensate. It clearly identifies 'code' as the six-digit SMS code from request_booking, but 'booking_id' is only inferred from the tool name and request_booking context. That partial clarification earns a 4.

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 clearly states the tool confirms a booking using a six-digit SMS code and explicitly ties it to request_booking. It differentiates the action from siblings like request_callback by defining what counts as a scheduled visit versus a follow-up situation.

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?

The description provides a clear trigger condition: use it after the customer supplies the SMS code from request_booking. It does not explicitly name an alternative tool or state 'do not use when...', but it does clarify that callback_pending must not be treated as an appointment, which guides routing.

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