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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds important behavioral context beyond annotations: output time-zone formats, the 90-day horizon, the can_book eligibility condition, and the race condition that free times can be taken before request_booking rechecks.

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 most important information comes first: what the tool returns and in which formats. The remaining sentences are compact and each adds useful constraints, defaults, or booking caveats without 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 a full input schema and an output schema, the description supplies the missing operational context an agent needs: date limits, default window, time-zone output forms, can_book eligibility, and volatility of availability. It is complete enough to call correctly without opening additional documentation.

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 slug, lang, date, and days. The description still earns credit by adding the 90-day ahead limit for date and by making clear that date and days are alternatives, not a combined range request.

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: free appointment start times for one professional. It also names request_booking as the follow-up validation step, helping distinguish this read-only availability lookup from the booking action.

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 clearly explains the availability-check context, including the can_book prerequisite and the warning that request_booking rechecks availability. It does not explicitly say when to use get_professional or search_professionals instead, so it stops short of full alternative routing.

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