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

Beyond the annotations, the description reveals an important behavioral trait: the response is identical whether or not the number is known, preventing user enumeration. It also makes the SMS side effect explicit. It could add more about response shape or session handling, but it provides meaningful behavioral context beyond the structured fields.

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 efficient sentences with no filler. The main action is front-loaded, the anti-enumeration behavior is stated compactly, and the exception for prepare_booking is included without redundancy.

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?

There is no output schema, so the description should explain what the caller receives; it only says the response is the same but not what it contains. It also does not cover session_id or the obvious follow-up step verify_phone_code. The description is adequate for high-level selection but not complete for invocation.

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?

With 0% schema description coverage, the description needed to explain both parameters. It adds some context for phone ('Polish mobile number') but entirely omits session_id, its role, or whether it is needed to link the verification to a booking. This leaves a required-by-workflow parameter undocumented.

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 'sends an SMS code to a Polish mobile number' to prove customer control. It also clearly distinguishes itself from prepare_booking and implicitly from verify_phone_code by describing the start-of-verification responsibility.

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 clearly frames when to use the tool: for accessing, rescheduling, or cancelling existing bookings, and explicitly says it is not needed for new bookings because prepare_booking sends its own code. It does not explicitly route the agent to verify_phone_code as the follow-up, which would have made the guidance complete.

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