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

readOnlyHint already signals a safe read, and the description adds substantial context on top: the exact returned fields, the privacy guarantee ('only times and counts... never anyone's calendar'), the token-dependent behavior of othersFree/othersTotal, and the default window. That is well beyond what the annotation conveys.

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?

Purpose is front-loaded in the first clause and every sentence carries information. Some fragments are dense and slightly telegraphic ('team mode', 'No auth needed'), but there is no padding or repetition.

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 carries the return-shape burden and does so — it enumerates title, durationMin, required questions, team mode, timezone, and the slot fields. Combined with the privacy note and defaults, an agent has everything needed to call and interpret this tool.

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 baseline is 3, but the description goes further — it decodes the handle format (whenmeet.me/@nickname[/slug]), explains how guests are folded into othersFree, and gives the interpretation rule othersFree === othersTotal = good for everyone. It does not restate the numeric bounds already in the schema, so it is additive rather than redundant.

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 — 'Bookable times on someone's WhenMeet.me booking link' — and scopes it by link form (personal or team, nickname[/slug]). An agent can immediately separate this from siblings like find_common_slots or get_meeting_availability, which concern other resources.

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?

Explains the calling context (token vs. no token, no auth needed, default 14-day window) and what the token buys you, which is genuine usage guidance. It never names an alternative sibling or states a when-not-to-use condition, so it stops short of a 5.

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