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

While annotations already indicate this is read-only and non-destructive, the description adds important behavioral context: availability already accounts for host calendars, buffers, and limits, date ranges are capped at 62 days, and timezone handling defaults to UTC. This goes well beyond the structured 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?

The description is dense but well-structured, leading with the core behavior and then progressing through parameter modes and next steps. Every sentence adds useful guidance, and the length is appropriate for the tool's complexity.

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 main input modes, defaults, timezone behavior, and how to use the returned slot values in subsequent booking calls. It is slightly incomplete on the exact meaning of handle and slug and does not fully define the output shape for slots beyond the mention of days grouping, but overall it provides enough context to invoke the tool correctly.

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?

The description adds real meaning to temporal parameters by specifying formats, allowed ranges, defaults, and timezone behavior, and it clarifies the special use of bookingId and token. However, the required handle and slug parameters are only syntactically described in the schema, so their semantic roles are left uncertain.

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 that the tool returns bookable start times with host calendars, buffers, and limits already applied. It also sets expectations for filtering and next steps, which distinguishes it from booking tools like create_booking and reschedule_booking_as_invitee.

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 explicitly explains how to use date vs from/to ranges, the default 7-day window, and the need to pass bookingId and token for existing bookings. It also directs the agent to the next appropriate tool, create_booking or reschedule_booking_as_invitee, after obtaining slots.

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