zsign

Send Draft

send_draft

Send a previously created Draft. Costs 1 credit. Recipients default to those stored when the draft was created. After send, status is Sent and invite emails fire (unless send_invite=false). sequential defaults true (one at a time); set false for everyone at once. Requires Authorization: Bearer zs_....

Input Schema

TableJSON Schema

Name	Required	Description	Default
`metadata`	No
`recipients`	No
`sequential`	No
`document_id`	Yes
`send_invite`	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"
+}

AddedSep 5, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The description goes well beyond the sparse annotations by disclosing that sending costs 1 credit, default recipients come from draft creation, status changes to Sent, invite emails fire unless disabled, and sequential behavior controls send timing. It also notes the required Authorization header. This gives the agent a clear picture of side effects and prerequisites.

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 compact and front-loaded: the purpose, cost, defaults, effects, and auth requirement each earn their place. There is no redundant restating of the tool name or obvious filler.

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?

The description covers the main behavioral context: credit cost, recipient defaults, status change, email behavior, sequential flag, and authentication. Since an output schema exists, return-value documentation is not required. The only notable gaps are the semantics of send_completion_email and metadata, which are minor for typical usage.

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

Parameters3/5

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

The input schema has 0% description coverage, so the description must compensate. It does clarify recipients, sequential, and send_invite, but it does not explain send_completion_email or metadata at all, even though both are parameters with defaults. This is adequate for core usage but leaves some parameters under-specified.

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 clearly states the action ('Send') and the resource ('a previously created Draft'), which distinguishes it from sibling tools like send_envelope that target envelopes rather than drafts. It also conveys the operation's place in the draft lifecycle.

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

Usage Guidelines3/5

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

The phrase 'previously created Draft' implies this tool should be used only after a draft exists, and the contrast with send_envelope is implicit through the resource type. However, the description does not explicitly say when not to use this tool or mention alternatives such as send_envelope or update_draft.

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?