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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is partially covered. The description adds real context beyond that: it does not deliver anything to the client, it runs without a confirmation prompt, it returns the total, and it needs a Cotlet API key with app access. It omits what happens on duplicate or invalid input, but coverage is solid.

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 non-send behavior is stated twice ('Nothing is sent until you call send_estimate' and 'It sends nothing to the client... send_estimate delivers it'), and the leading fragment duplicates the verb phrase that follows. The critical constraint is front-loaded, but the text is longer than it needs to be.

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 create tool with full schema coverage, annotations and no output schema, the description supplies the key missing pieces: the return value (total), the non-dispatch behavior, and the auth requirement. An agent can call it correctly and knows it must follow up with send_estimate to deliver.

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 all three parameters are documented in the schema, so the baseline is 3. The description only adds that line items sum to the total, which is marginal semantic value beyond what the schema already conveys.

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 states a specific verb and resource ('Creates an estimate for a client from line items and returns its total') and explicitly contrasts with the sibling send_estimate. The opening fragment ('Service Autopilot: Estimate for a client from line items') is a verbless restatement that adds noise, but the core purpose is unambiguous.

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 names the alternative (send_estimate) and the exact condition that selects it: 'Nothing is sent until you call send_estimate' / 'send_estimate delivers it.' The agent knows when to use create vs. send without inference.

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