create_envelope_from_template

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

No annotations are provided, so the description carries the transparency burden. It discloses the return format (dict with envelopeId and status), explains the 'sent' vs 'created' status behavior, and details role assignment structure including optional clientUserId for embedded signing. This gives an agent a clear picture of the tool's effects and outputs.

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 a well-structured docstring with a one-line summary, an Args list, and a Returns section. Each parameter has a short explanation, and there is no fluff or redundant information.

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?

The description includes a clear purpose, full parameter documentation, and return value shape. It does not cover prerequisites (e.g., template existence or role matching) or error conditions, but for a tool with this complexity and a visible output schema, the essentials are covered. A small gap in usage context prevents a perfect score.

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 property descriptions are 0% in the input schema, but the description fully compensates by documenting all five parameters in an Args block. It explains the purpose of template_id, email_subject, role_assignments (including nested keys), optional email_blurb, and status with allowed values. This exceeds what the bare schema provides.

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 clear action statement: 'Create an envelope from a DocuSign template.' This identifies the resource (DocuSign template) and distinguishes it from sibling create_envelope_from_documents by specifying the template-based workflow. It is a concise, specific verb+resource statement.

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 does not explicitly list when-not-to-use or alternative tools, but the phrase 'from a DocuSign template' establishes when this tool is appropriate—when a template exists. It clearly differentiates from create_envelope_from_documents without naming it, providing sufficient context for an agent to select the right tool.

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