Skip to main content
Glama

Send a document for signature

send_for_signature

Create a document from a template and send it to signers via email for electronic signature. Supports parallel or sequential signing order, idempotent retries, and dry-run validation.

Instructions

Create a document from a template and email it to signers for signature. IMPORTANT: sending exposes the document contents to every listed email — NEVER guess or infer a signer email address. Use exactly the emails the human gave you; if any is missing or ambiguous, ask the human before calling this tool, and restate the recipient list in your confirmation. ARRAY POSITION assigns template roles: the first signer gets the first role, and so on. The document sends as-is — its fields are filled by the signers at signing, not by you. Returns the document id — poll check_status with it. Pass a stable request_id when you might retry: a replayed request returns the original document instead of double-sending. A mis-sent envelope can be voided by the human from the AddSign dashboard (Cancel).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title; defaults to the template name
dry_runNotrue = validate everything (recipients, template roles, plan limits) and report exactly what WOULD be sent — without creating or emailing anything. Use it to show the human the outcome before the real send.
messageNoPersonal note included in the signature-request email
signersYesOne signer per template role — array position IS the role assignment
request_idNoIdempotency key — reuse the same value when retrying after a timeout
template_idYesTemplate id from list_templates
signing_order_typeNoparallel (default): everyone signs at once; sequential: one at a time in order
Behavior5/5

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

Annotations only provide openWorldHint=false and destructiveHint=false, but the description goes far beyond: warns about email exposure, requires exact email use, explains idempotency with request_id, role assignment via array position, and mentions cancellation via dashboard. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but concise, with no filler. It front-loads the core action, then adds warnings, parameter behavior, and return value in a logical flow. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters and no output schema, the description covers the action, parameter usage, return value (document id for polling), and error handling (dry_run, idempotency). It could mention error conditions more explicitly, but overall it is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds crucial context: signers array position assigns template roles, dry_run validates without sending, request_id prevents double-sending, and signing_order_type options are explained. This exceeds the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb+resource: 'Create a document from a template and email it to signers for signature.' It distinguishes from sibling tools like check_status and download_signed by focusing on the sending action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use (sending for signature) and provides critical usage rules: never guess emails, ask if ambiguous, use dry_run for validation, and handle retries with request_id. It could explicitly contrast with siblings, but the context signals list them, and the description implies when not to use (e.g., for status or download).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rmindgh/addsign-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server