Skip to main content
Glama

sign

Destructive

E-signature (sign envelopes) + reusable sign TEMPLATES, scoped to a workspace. Create/update DRAFT envelopes, send (reserves credits) / void (terminal), re-drive a wedged envelope (sign-retry), download source/preview/signed documents + the audit certificate and its Certificate-of-Completion PDF (all returned as pre-authenticated STREAM-ROUTE URLs), mint your own signing link for a signature card (dashboard-sign-link), and design/instantiate templates (sign-template-*). Envelopes and templates are WORKSPACE-PARENTED. Write/lifecycle actions are FIRE-AND-FORGET (return ids + state + a _next poll hint); destructive actions (sign-send/sign-void/sign-template-delete) need confirm='true'. Call action='describe' for the full per-action reference (callable without auth).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNosign-create/-update: envelope name (max 255). sign-template-create/-update: template name (REQUIRED on create). sign-template-instantiate: name for the draft envelope (defaults to the template name).
limitNoPagination limit (max 500).
actionYesOperation. Use 'describe' for full action reference.
fieldsNosign-create/-update: JSON array of field placements (coords 0..1; see note).
offsetNoPagination offset (default 0).
reasonNosign-void: void reason (max 1024).
confirmNoConfirmation gate ('true'). REQUIRED for sign-send/sign-void; refused without it.
snapshotNosign-template-create/-update: JSON snapshot object {recipient_slots, document_slots, fields, policy}. On update it is a FULL replacement (see note).
documentsNosign-create/-update: JSON documents array 1-20 (see note). sign-template-instantiate: JSON array of slot overrides [{document_slot_index, source_node_id, source_version_id?}].
expires_atNosign-create/-update: envelope expiry as a UTC timestamp 'Y-m-d H:i:s UTC' (NOT a day count; omit/null = policy default).
recipientsNosign-create/-update: JSON recipients array (see note).
descriptionNosign-template-create/-update: template description (max 1024).
document_idNosign-document-*: document OpaqueId.
envelope_idNosign-*: numeric envelope ID.
policy_jsonNosign-create/-update: optional JSON policy {auth_method,...}.
template_idNosign-template-get/-update/-delete/-instantiate: template id (30-char base32, `sa` family).
workspace_idNoWorkspace ID. Envelopes are workspace-parented; use the 19-digit NUMERIC workspace ID (the document/audit download stream route rejects custom workspace names).
display_limitNoMax list rows rendered inline (default 10; the full page is still fetched).
describe_actionNoWhen action='describe', narrow the output to ONE action's full params/notes (e.g. 'sign-create'). Omit to get the compact action index.
envelope_statusNosign-list: status filter.
expected_versionNosign-template-update: the `version` you read from sign-template-get (optimistic CAS). A concurrent write returns 409 — re-read and retry.
recipient_bindingsNosign-template-instantiate: JSON OBJECT keyed by slot_key -> {email, display_name?, auth_method?}. An ARRAY is rejected by the platform.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses fire-and-forget lifecycle semantics, `_next` poll hints, terminal void behavior, credit reservation on send, pre-authenticated stream-route URLs, and confirm gating for destructive actions. These are substantial behavioral details not present in the annotations.

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 dense but well-ordered: scope first, then the operation catalog, then key behavioral caveats, then the describe escape hatch. Every sentence carries information; there is no filler or repetition.

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 with 22 parameters, 20 actions, and no output schema, it covers critical return behaviors (ids + state + `_next`, stream-route URLs) and directs agents to action='describe' for exhaustive per-action details. It does not spell out list/download return shapes, but the describe reference materially compensates.

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?

Schema description coverage is 100%, so the schema already documents all 22 parameters. The description adds useful global context such as confirm gating and fire-and-forget behavior, but it does not add significant per-parameter meaning beyond what the schema already provides.

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 names the domain (E-signature) and explicitly enumerates the operation classes: envelope drafts, send/void/retry, document/audit downloads, signing links, and templates. It clearly scopes everything to workspace-parented envelopes and templates, which distinguishes it from sibling tools like download or fileshare.

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?

It states the tool is workspace-scoped, tells agents to call action='describe' for the full per-action reference, and flags that destructive actions require confirm='true'. It does not explicitly name sibling alternatives or when-not-to-use conditions, but no sibling covers e-signature, so the guidance is strong.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources