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

With no annotations, the description fully discloses that nothing is booked until payment, the booking stays off the calendar, and the contact email is not verified. This provides complete transparency about the tool's 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 concise (6 sentences) with all information front-loaded. Every sentence adds unique value, from the main action to prerequisites, return value, and caveats. No fluff 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?

Despite no output schema, the description fully explains the return (checkout URL) and the workflow prerequisites and post-conditions. For a tool with nested parameters and a payment flow, all necessary context is provided.

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%, but the description adds crucial operational context: place_slug comes from search_places, serviceId from list_booking_services, dates must exactly match get_availability, and contact object with required fields. This goes beyond the schema definitions.

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 'Book an appointment slot at a venue (Wix Bookings)' with a specific verb and resource. It distinguishes itself from sibling names like create_checkout by explaining that it returns a checkout URL and the booking is pending payment.

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 instructs to call get_availability immediately before, warns that the slot is re-validated server-side, and explains that payment is required via the returned URL. It also tells the agent to inform the user they must open the link.

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