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

Annotations already establish readOnly, non-destructive, closed-world, so the description correctly avoids restating safety and instead adds real behavior: the return is itemized lines plus an estimate, delivery estimates include a fee, and fulfillment defaults to the mode all items share. The closing instruction to review with the customer before booking further clarifies this is a non-committal preview.

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?

Front-loaded with purpose and usage, then the id provenance, the nested shape, the fulfillment options, and the return. Every sentence carries information, though the parameter-detail sentences are dense and read as a run-on rather than being visually separated.

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 3-parameter pricing tool with no output schema, the description covers invocation inputs, the nested options format, fulfillment defaulting, and return contents. The omissions (quantity semantics, the "elsewhere" fulfillment mode, item limits) are minor but prevent a top score.

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?

With 0% schema description coverage the description carries the full burden and mostly succeeds: it explains the business id is the owner's own, that ids come from the catalog, the exact options shape {group_id: [choice_id, …]}, and what fields means. Gaps remain — quantity is never mentioned, and the fulfillment list omits the schema's "elsewhere" enum value, so the description is not fully aligned with the schema.

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 opens with a precise verb+object ("price a choice") and immediately frames the phase in which it applies ("before booking or ordering"), which separates it from the booking/ordering siblings without naming them. It also states what comes back ("itemized lines and the estimate"), so an agent knows exactly what the call produces.

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?

Two concrete triggers are given: pricing a choice prior to booking/ordering, and answering an owner's "what would you charge" question, including the instruction to pass the owner's own business id. There is no explicit when-not or named alternative tool, so it stops short of a 5.

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