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

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, and the description adds meaningful behavioral context beyond those: it is a stateless preview, it does not save the selection, Sedna is the only pricing source of truth, and the server recalculates totals. It also specifies how to present returned financial fields (customer_cost_summary.full_customer_cost, payable_now, payable_at_base, refundable deposit) which goes beyond what the annotations provide.

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 longer than a typical tool definition, but it is front-loaded with the core purpose and then flows into operational guidance without filler. Each sentence contributes either a routing instruction or a behavioral rule. It loses a point because some instructions (e.g., repeating "never add them in the LLM" and separately warning about totals) could be tightened without losing meaning.

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 carries the burden of explaining return handling, and it does so: it tells the agent to present the complete updated summary, quote customer_cost_summary.full_customer_cost, explain payable_now and payable_at_base separately, and keep the refundable deposit separate. Combined with the stateless preview warning and the booking_create handoff, it is complete enough for correct invocation in this workflow.

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%, so the schema already documents all 11 parameters, including required IDs, dates, pax, selected_extras, currency, ports, and payment options. The description reinforces a few mappings (e.g., "Copy id_boat and id_tbf1 from search_boats" and "Send selected extras, passenger count, currency, ports and payment options here") but adds no new syntax or constraints beyond the schema. Baseline 3 is appropriate when the schema does 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 opens with a specific verb and resource: "Apply customer selections and return server-recalculated booking details." It further scopes the tool as a "stateless price preview" and distinguishes it from booking_create by noting that booking_create is used when the customer proceeds. This is enough for an agent to identify the tool 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?

The description gives clear context: copy id_boat and id_tbf1 from search_boats, send selections here, then repeat selected_extras in booking_create if the customer proceeds. It also clarifies that this tool does not save the selection, implicitly telling the agent to use booking_create for persistence. It does not explicitly address when to use this modified tool versus the sibling booking_detail, which prevents a 5.

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