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

Annotations only say it is a non-read-only, non-destructive, non-idempotent, closed-world write; the description adds the substantive behavior: no charge, calendar invite originates from cal.com, and exactly one upcoming free call per person, after which the call refuses and names the existing booking. It also discloses the answer's return shape (own label and join link) and the follow-up tools for moving or cancelling.

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?

Front-loaded with the action and the constraint on the start value, then the eligibility rules, then the one-call limit. It is dense and slightly repetitive ('free 30-minute intro call with Ben' appears three times), but nearly every clause constrains behavior rather than 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?

With no output schema, the description still tells the agent what comes back (a booking with its own label and join link) and what to do next. Combined with the eligibility rules, the refusal condition, and the exact-time requirement, an agent has everything needed to call it and handle its failure modes.

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. The description nonetheless adds genuine meaning for 'start' – pass it exactly as listed and refer to the time by its label rather than a computed weekday – which prevents a real class of errors. It says nothing extra about topic or timeZone beyond the schema's Berlin default.

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?

States a specific verb and resource ('Book the signed-in person a free 30-minute intro call with Ben') and pins the source of valid times to my_bookings/introCall.openTimes. It separates itself from the paid sibling book_hour_with_ben by declaring 'No diamond, nothing charged', so an agent can pick the right tool without opening either schema.

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?

Gives explicit when-to-use ('interested in the Pirate Forge (the Forge Pass) or in working with Ben one to one – Captain on Deck') and explicit when-not ('Never offer it for the Pirate Pass or for an event ticket'). It also routes around alternatives: use this instead of a booking page unless it refuses or fails, and hand off to move_booking/cancel_booking afterwards.

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