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

The annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the risky external-send profile is covered structurally. The description adds genuine context beyond that: the mail carries a PDF, and with_signed attaches the signed version only when one is stored. It does not say what happens to the contract record after sending or whether a resend is possible.

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?

Two compact sentences with the action first and the conditional attachment behavior second; there is no filler and nothing is buried.

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 seven-parameter, non-idempotent, externally visible send operation with no output schema, the description is thin: it never states what success returns, how mail_account_id selects the sender, or what side effects sending has on the contract. The parameter documentation gap is not compensated anywhere else.

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 only 14% (just id = 'Vertrags-ID'), so the description must carry the load. It explains with_signed reasonably well, but leaves to, cc, subject, body and especially mail_account_id (which mailbox sends it) completely undefined, leaving six of seven parameters with no semantics anywhere.

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 a concrete verb (per E-Mail senden), the exact resource (ausgestellter Vertrag als PDF) and an important precondition (the contract must be 'ausgestellt'). It also differentiates itself from the sibling send_document by referencing it, so an agent can tell which tool to pick for contracts versus generic documents.

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?

'Ausgestellten' implies the contract must already be issued before this tool applies, and the send_document reference gives some routing context. However, there is no explicit guidance on when not to use it, and it never mentions how it relates to mark_sent or whether sending changes the contract's state.

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