zsign

Send Envelope for Signature

send_envelope

Send a PDF for legally binding signature, or leave it as a Draft for a human to approve. Immediate send costs 1 credit. Provide the PDF either as document_base64 OR as a public https document_url (max 10MB). recipients = [{"name": "...", "email": "...", "role": "signer"}]. Each recipient gets a signing email; poll get_envelope_status for progress. Requires Authorization: Bearer zs_....

auto_send defaults true (existing one-tool send). Set auto_send=false or draft=true to create a Draft: status Draft, no credit debit, no invite emails. draft=true always wins if both flags are set. Then a human Approves/Sends in the dashboard, or call send_draft.

Immediate send: the PDF is REJECTED unless it contains signing-field placeholder tags. Draft mode accepts an untagged PDF (human places fields) or optional fields. zSign field placeholder syntax:

Format: {type:party:name} -- add * after the type to mark the field required, e.g. {signature*:signer}
Types: signature, initials, text, date, radio
party must exactly match the recipient's "role" value passed when sending (MCP default role is "signer")
name is optional for signature/initials/date and REQUIRED for text fields; letters, digits, and underscores only
radio fields take FOUR parts: {radio:party:group:option}. Every tag sharing a party and group forms one exclusive set -- the signer picks exactly one, and the chosen option is the value reported back. Mark the set required with {radio*:...} on any of its tags. group is letters/digits/underscores; option may also contain spaces and hyphens
radio tags must be visible text in the PDF body -- they cannot be the name of a PDF form field
Keep each tag on a single line in a standard font -- a tag split across lines is not detected
The tag's position in the document becomes the field's position; the signed value is drawn over it, and the tag itself is deleted when you upload -- signers never see it, and it is not in the completed document
Tags can be visible text in the PDF body, or the name of a PDF form field / annotation (except radio, which must be visible text) Examples: {signature*:signer}, {initials:signer}, {text*:signer:full_name}, {date:signer:signed_on} Radio (visible text only): {radio*:signer:plan:Option 1}, {radio*:signer:plan:Option 2} Sample PDF: https://storage.googleapis.com/zsign-public/simple_contract_1.pdf Docs: https://zsign.io/docs/api

metadata is an optional flat object of string keys/values (max 50 keys) echoed back in every webhook for this envelope -- use it to carry your own record ids.

sequential (default true): recipients sign one at a time in list order. Set false so everyone can sign at once. Same flag as REST POST /api/v1/documents/send and WorkflowSettings.sequential.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	No
`draft`	No
`fields`	No
`filename`	No	document.pdf
`metadata`	No
`auto_send`	No
`recipients`	No
`sequential`	No
`send_invite`	No
`document_url`	No
`document_base64`	No
`send_completion_email`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 5, 2026

addedInput schema / properties / sequential

Added value: +{
+  "default": true,
+  "title": "Sequential",
+  "type": "boolean"
+}

Changed8 schema fields changedSep 5, 2026

addedInput schema / properties / auto_send

Added value: +{
+  "default": true,
+  "title": "Auto Send",
+  "type": "boolean"
+}

addedInput schema / properties / draft

Added value: +{
+  "default": false,
+  "title": "Draft",
+  "type": "boolean"
+}

addedInput schema / properties / fields

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Fields"
+}

addedInput schema / properties / recipients / anyOf

Added value: +[
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / recipients / default
```
Added value: +null
```

removedInput schema / properties / recipients / items

Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}

removedInput schema / properties / recipients / type
```
Removed value: -"array"
```
removedInput schema / required
```
Removed value: -[
-  "recipients"
-]
```

Changed3 schema fields changedSep 2, 2026

addedInput schema / properties / metadata

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Metadata"
+}

addedInput schema / properties / send_completion_email

Added value: +{
+  "default": true,
+  "title": "Send Completion Email",
+  "type": "boolean"
+}

addedInput schema / properties / send_invite

Added value: +{
+  "default": true,
+  "title": "Send Invite",
+  "type": "boolean"
+}

First observedJul 21, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With only sparse annotations (readOnlyHint=false, destructiveHint=false), the description carries the transparency burden and delivers richly: it discloses the 1-credit cost, PDF rejection when tags are missing, that each recipient gets a signing email, that tags are deleted on upload and never appear in the final document, that party must match the recipient role, and that draft mode debits no credit. It also reveals side effects like webhook echo of metadata and the sequential signing default. No contradiction with annotations.

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

Conciseness4/5

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

The description is long, but the tool genuinely warrants it: field-tag syntax, radio group semantics, and draft-vs-send interplay cannot be compressed further without losing operational necessity. It is well-organized (send/draft behavior, input formats, tag syntax with examples, metadata, sequential) and the correct usage is front-loaded. It is slightly redundant in the radio visible-text rule, stated twice, and could trim a few words.

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 high-complexity tool (12 params, dual mode, tag syntax, cost side effects) the description covers the full send workflow, draft workflow, failure conditions (rejection, tag requirements, size cap), post-call behavior (polling), auth, and links to docs and a sample PDF. An output schema exists, so return-value documentation is unnecessary. Remaining gaps are minor: send_invite/send_completion_email semantics and filename behavior are left to inference.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate — and it does for the critical parameters: recipients (exact array shape with name/email/role), document_base64 vs document_url (either-or, 10MB limit), auto_send/draft (full semantics including precedence 'draft=true always wins'), metadata (flat, max 50 keys, webhook echo), and sequential (ordering semantics). However, four secondary parameters (name, filename, send_invite, send_completion_email) receive no semantic explanation beyond their names.

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 opens with a specific verb+resource: 'Send a PDF for legally binding signature, or leave it as a Draft for a human to approve.' It captures the tool's dual-mode behavior and differentiates it from siblings like send_draft (send an existing draft) and get_envelope_status (poll progress). An agent can determine what this tool does and what it is not without inspecting other definitions.

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 gives clear decision criteria for the primary fork: use auto_send=true for an immediate send vs draft=true/auto_send=false to defer to a human, and explicitly routes to siblings for follow-up ('poll get_envelope_status for progress', 'call send_draft'). It also states the auth prerequisite. It does not enumerate when-not-to-use cases for other siblings (e.g., void_envelope, update_draft), but the main alternative paths are clearly signaled.

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

All zsign tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct action or resource: account creation, pricing/credits, sending, draft management, status polling, download, and voiding. Even closely related tools like send_envelope and send_draft are clearly separated by whether they create a new envelope or send an existing draft.

Naming Consistency5/5

All tools follow a consistent lowercase verb_noun pattern: buy_credits, check_balance, create_account, download_signed_document, get_envelope_status, send_draft, update_draft, void_envelope. There are no naming style collisions or vague generic verbs.

Tool Count5/5

11 tools is well-scoped for an e-signature API: account setup, billing, sending, draft handling, status, download, and voiding are each represented. The count feels intentional rather than padded or sparse.

Completeness4/5

The core envelope lifecycle is covered: create/send, draft update, send draft, status, download, and void, plus account and billing support. Minor gaps exist such as no way to list envelopes, retrieve a draft's current fields, or delete a draft, but agents can still complete the primary workflow.

Resources

Need Help?