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

Even though annotations already mark this as read-only, idempotent, and non-destructive, the description adds substantial behavioral context: empty list means fully booked (not an error), prices are in EUR with optional secondary currency with fallback behavior, and the structured response always contains full multi-currency breakdown. This goes beyond the annotations and informs the agent about expected edge-case behavior.

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 two sentences, front-loaded with the core purpose, and every sentence offers unique value—real-time checking, return content, empty-list semantics, and currency behavior. No filler or repetition of schema content.

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 burden of explaining what the tool returns. It covers available start times, session duration, pre-filled booking URL, pricing, and the meaning of an empty list, all critical to using the tool correctly. It also addresses currency handling. For a read-only tool with detailed input schema, this is comprehensive.

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 baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides; for instance, the schema already documents currency fallback and participants range. The tool description mentions pricing and secondary currency but mirrors schema details without adding new parameter semantics.

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 the tool checks real-time availability for a specific date, with a specific verb and resource. It distinguishes itself from siblings that find next available or fetch booking URLs by emphasizing date-specific lookup and immediate return of available times, duration, booking URL, and pricing.

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 clearly implies when to use this tool (for a specific date availability check) and even notes that an empty slot list means fully booked, which helps set expectations. However, it does not explicitly name alternatives like find_next_available or get_booking_url or state when not to use it, so it misses the explicit exclusion guidance that would earn a 5.

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