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

Annotations already declare the write/open-world/destructive profile, and the description adds useful behavior: the estimate is saved but not sent, client contact fields are copied, tax rates may reuse or create saved rates, and expiry cannot be in the past. It does not discuss duplicate creation or return behavior, but the annotations cover idempotency.

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 front-loaded and reasonably well organized, but it repeats the no-send point twice: once at the start and again later. Some sentences, such as the restatement of creating an estimate, could be trimmed 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?

For a 10-parameter nested create tool with no output schema, the description covers key side effects and parameter behavior but omits what the tool returns, such as the new estimate ID or estimate number. That is a meaningful gap when no output schema exists.

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 real meaning beyond the schema: tax_rate can reuse or add a saved rate, tax_id selects a saved rate, deposit appears as Deposit Due, and expires_on cannot be in the past. These details clarify parameter interactions rather than merely restating field descriptions.

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 names the specific verb and resource: it creates a saved estimate with line items, tax, discount, deposit, and expiry. It also distinguishes itself from send_estimate by stating that nothing is sent to the client.

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 clearly explains that this creates a saved estimate but does not send it, and that the client only sees it after send_estimate. It does not explicitly mention update_estimate as the alternative for editing existing estimates, so the guidance is strong but not exhaustive.

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