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

Annotations declare readOnlyHint/idempotentHint and non-destructive, but the description goes well beyond them: the return is a short-lived URL on the venue's own page, nothing is reserved, contact details are collected by the page rather than the tool, and the slot can still be lost. These are exactly the operational facts an agent cannot get from 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 short paragraphs, front-loaded with the capability and its negation, then the guest-facing instruction, then the caveat. Every sentence carries a distinct operational fact with no restatement of the title or schema.

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 still tells the agent the shape and lifetime of the return value (a short-lived url) and how to hand it off. Combined with a fully described 3-param schema, nothing needed to invoke and relay the result 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 100%, so the schema already documents all three parameters in detail, which sets the baseline at 3. The description adds genuine meaning on top: it explains what the produced link encodes (venue's page pre-opened at that service, that staff member and that exact time) and clarifies that slotToken originates from find_appointment_times or find_table_times.

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 opens with a specific verb and resource (turning a time into a booking link) and immediately negates the likely misread: 'This does NOT book anything.' It explicitly ties itself to the sibling find_appointment_times as its input source, and the schema references find_table_times as well, so an agent can place it precisely among the five siblings.

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 when to use it (after find_appointment_times), what to do with the result (give the guest the url), a hard constraint ('Never ask the guest for their contact details to pass here'), and a caveat to relay ('a popular time can still go before they tap'). The when/when-not boundary is fully spelled out rather than implied.

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