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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the external-side-effect profile is partly covered; the description adds real value by disclosing the attachment contents, the prerequisite data requirement, and the returned values. What it does not do is explain why the call is destructive — that the email cannot be recalled once sent — which is the main behavioral risk an agent should weigh.

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?

Three sentences, each doing distinct work — action, alternative routing, prerequisite, return value. The primary action and its sibling boundary are front-loaded, and there is no filler.

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?

With no output schema, the description compensates by stating the return (invoice number and destination addresses), and it covers prerequisites, alternatives, and attachment content. The remaining gap is failure/edge behavior — what happens if the invoice is not finalized or the send fails — which an agent would have to discover at call time.

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 50%: message is documented inline but invoice_id carries no schema description. The description partly compensates by saying the invoice must be "finalized," implying a state constraint on invoice_id that the schema omits, but it never mentions the optional custom message body or what happens to the default.

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 ("Email a finalized invoice to the customer") plus the payload (PDF with Veri*factu QR). It also explicitly names the scope as the first send, which separates it from send_reminder and mark_invoice_sent without opening any 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?

Names two sibling alternatives and the exact condition that selects each: send_reminder for chasing an unpaid invoice, mark_invoice_sent if the user already sent it through another channel. It also states the prerequisite (customer must have an email on file) and points to update_customer to fix it.

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