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

The description goes well beyond the annotations by warning 'THIS EMAILS REAL PEOPLE and spends 1 credit' and instructing the agent to confirm signer details with the user or use draft=true. It also explains sequential signing behavior and that signers are emailed one at a time, which is critical side-effect context that annotations alone do not provide.

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 compact and front-loaded: the real-world consequence and user-confirmation requirement come first, then prerequisites, then optional behavior. Every sentence contributes meaningful guidance with no repetition of the schema.

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 9-parameter tool with real-world side effects and no output schema, the description covers the essential operational context: prerequisites, side effects, draft staging, and sequential signing. It does not describe return values or tracking, and leaves some minor parameters to the schema, so it is strong but not fully 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that every signer key must be represented, that field keys come from get_document, that draft=true stages without emailing, and that send_order uses lower values first. It doesn't elaborate on every parameter, but the important semantics are enriched.

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 opens with a specific verb and resource: 'Send a document for e-signature using a template.' This clearly distinguishes the tool from siblings like create_document_from_upload and list_templates, and the title reinforces the same intent.

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 gives clear context for correct use: template_uuid is needed, signers must cover every template key via get_document, and draft=true stages without emailing. However, it never explicitly contrasts with alternatives like create_document_from_upload or says when not to use this tool, so it stops short of a full 5.

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