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

Annotations only declare it is a non-read-only, non-idempotent, non-destructive open-world call; the description adds what actually happens (an e-mail goes to the reservation team, nothing is booked or charged, the team replies by e-mail). It further discloses the guard behavior and named error outcomes, which annotations cannot express.

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 the action, then the safety preconditions and error semantics; nearly every clause carries operational meaning. It is semicolon-dense and reads as one long run-on, which costs a little scannability but not substance.

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?

An output schema exists, so return values need not be spelled out, yet the description still covers the decision-relevant outcomes (CONFIRMATION_REQUIRED, NOT_DELIVERED) and the confirmation gate. For a 12-parameter open-world submission tool, an agent has everything needed to call it safely.

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%, so the baseline is 3, but the description adds consequences the schema does not: confirm=false yields CONFIRMATION_REQUIRED with nothing sent, and privacy_consent ties to a policy URL surfaced in that answer. The company-stay hint (company in name, employees count) also clarifies two optional fields beyond their schema text.

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 ("sends a non-binding offer request to the reservation team") and anchors it to a familiar analogue ("like the form on the website"). It also distinguishes the action from booking by stating "Books and charges nothing", which separates it from the sibling start_booking.

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?

Explicit preconditions are given: call only after the guest saw the exact content and agreed (confirm: true) and agreed to the privacy policy (privacy_consent: true). It also names the when-not path — otherwise CONFIRMATION_REQUIRED and nothing is sent — and gives a fallback for NOT_DELIVERED (hand out phone and e-mail).

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