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

With no annotations supplied, the description carries the full load and does so: seat is held during payment, payment is a single-use Stripe Checkout URL opened in a browser, the hold is released if unpaid, and confirmation plus a change/cancel link goes to guestEmail. The fallback response for unsupported booking types and the hourly booking cap are behaviors nothing else declares.

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 and every sentence adds a fact about payment, fallback or parameter sourcing, but it is delivered as one dense block with several clauses stacked into the long negative-case sentence, which slightly blunts scanability.

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?

There is no output schema, so the description must describe returns — and it does: a single-use Stripe Checkout URL on success, or a class page URL for unsupported booking types. For a seven-parameter mutation with no annotations, an agent has everything needed to call it and to predict both outcomes.

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 86%, yet the description still adds meaning: pwycAmountCents applies only to pay-what-you-can classes and must be at least minPriceCents from search_classes, locale drives both emails and the booking page, and scheduleId comes from search_classes. It stops short of explaining notes or the interaction between partySize and pwycAmountCents.

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 ('Book a class, event or retreat for a person with no MoveMentors account') and immediately narrows the case to guest, card-paid bookings. The reader can distinguish this from search_classes and the listing siblings without opening the schema.

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?

Explicitly enumerates the cases this tool handles and the cases it does not — free classes, cash/bank-transfer hosts, text-verification hosts, promo codes and retreat payment plans — and tells the agent what happens instead (a class page for self-booking). It also names search_classes as the source of scheduleId and states a per-person rate limit.

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