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

Beyond the readOnly/idempotent annotations, the description discloses the critical behavioral caveat that this legacy tool never searches live inventory and always returns not_available status, plus the practical limits of the returned data (a Stymie course-page link and optional alerts page). This proactively prevents an agent from misinterpreting a nominally 'tee times' tool as a booking/availability check.

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?

Three sentences, front-loaded with the core purpose and followed by the key caveats; no wasted prose. Slight overlap between 'does not search live inventory' and 'cannot confirm availability' keeps it from being maximally tight.

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 fills the gap by explaining what the caller receives (the Stymie course-page link and an optional early-access alerts page) and reiterates the never-available status, so an agent has everything needed to call and interpret it 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?

Schema description coverage is 100%, with date, slug, and players each fully documented in the schema, so the schema carries parameter semantics. The description adds nothing parameter-specific, which matches the baseline 3 when structured fields do the heavy lifting.

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 names a specific verb and resource ('Get booking information for a course') and pins the input provenance to courses returned by search_courses or find_nearby_courses, distinguishing it from the other course-related siblings. It also explicitly states the legacy semantics ('status is always not_available'), so an agent knows what this tool actually yields versus its name.

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 states the precondition for use (a course already returned by search_courses or find_nearby_courses) and enumerates what the tool cannot do — 'cannot book, pay, enroll in alerts, or confirm availability' — which is exactly the when-not guidance an agent needs for a live tee-time sounding name.

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