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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It adds meaningful context: the ownerKey must be kept secret, and emails to recipients are only sent via that key, implying this tool does not email directly. It also describes the return values (process ID, ownerKey, signing links). However, it does not explicitly mention side effects like persistence or cost, nor reversibility, but the security disclosure is a strong positive.

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 three sentences long, with no wasted words. Every sentence contributes: the first states the primary function, the second reveals outputs and the security-sensitive ownerKey, and the third clarifies field placement and email handling. It is front-loaded and appropriately sized for the tool's complexity.

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?

Given 8 parameters and no output schema, the description covers essential aspects: the action, return values (process ID, ownerKey, signing links), field semantics, and a note on email delivery. It doesn't explicitly explain edge cases like isPublic or expiresDays, but those are encoded in the schema. The lack of an output schema is partially compensated by mentioning the key return fields, making it reasonably complete.

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 100%, so parameters are already documented. The description adds value by explaining the ratio-based placement ('per Ratio (0..1, y von oben)') in a more readable way and by noting the ownerKey's secrecy, which is not in the schema. It does not individually describe each parameter but reinforces key semantics, slightly exceeding the baseline.

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 clearly states a specific action: 'Sendet ein PDF zur mehrparteiigen elektronischen Signatur (DocuSign-Stil).' It identifies the resource (PDF) and differentiates from sibling tools like envelope_send_invite, envelope_status, and envelope_void by focusing on creating a new envelope. The verb 'Sendet' is a bit broad but the DocuSign-style reference and the mention of returning signing links make it unequivocally about creating a signing envelope.

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?

The description implies that this tool is used to create an envelope and obtain an ownerKey and signing links. It hints that emails are sent 'nur über den zurückgegebenen ownerKey' (only via the returned ownerKey), which suggests a separate step, but it does not explicitly name alternatives like envelope_send_invite or state when not to use this tool. There is clear context but no explicit exclusions or alternative recommendations.

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