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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context on top: the tool only returns a URL, nothing is charged, and the actual booking flow (sign up/sign in, six questions, payment) happens on the website. It also sets a hard behavioral rule against requesting card details or personal data in chat, which an agent would otherwise have no way to know.

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?

Four short sentences, front-loaded with what is returned and immediately followed by the key negative clarification. The web-flow sentence and the data-handling rule each carry distinct, non-redundant information.

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?

For a one-parameter, read-only tool with an output schema and full annotations, the description supplies everything an agent needs: what comes back, what it does not do, where the user completes the flow, and a privacy constraint on the conversation.

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% and the single dinner_id parameter is fully documented in the schema, including the accepted date format example. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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: returns the link where a person books a seat at a Siena dinner on sienasociety.com. The clarifying line 'It books nothing and charges nothing' preempts the natural misreading of the 'start_booking' name, distinguishing it from sibling tools like get_dinner or list_upcoming_dinners.

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 establishes the context (person wants to book a seat) and explicitly rules out chat-side handling of card details or personal data, which is real when-not guidance. It does not explicitly name alternatives or the sequencing with list_upcoming_dinners in the description itself, though the schema param description does.

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