Skip to main content
Glama
Sign In
PDFGate MCP Server

PDFGate MCP Server

Official
by pdfgate
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_envelope

Create a signing envelope from existing PDFGate documents and assign recipients who sign via emailed link, embedded flow, or automatic stored signature, with optional signing order and expiry.

Instructions

Create a signing envelope from one or more existing PDFGate documents. Each recipient is given either as email and name or as the recipientId of a stored recipient. A recipient signs through the hosted flow (emailed link), embedded signing (embedded: sign inside your application via create_embed_link, no emails) or automatic signing (autoSign: the stored signature of a recipient enrolled with request_recipient_signature is applied on their behalf, no signing session). Use signingOrder to make recipients sign in sequence. Returns an envelope in 'created' status; call send_envelope to dispatch signing emails.

Input Schema

NameRequiredDescriptionDefault
metadataNoCustom metadata to attach
documentsYesDocuments to include in the envelope
expiresInDaysNoDays until the envelope and its signing links expire, counted from creation. Defaults to the account's envelope expiration setting.
requesterNameYesName of the user or system creating the envelope

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.0
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / autoSign
      Added value: +{
+  "description": "Automatic signing. Applies the stored signature of the referenced recipient on their behalf when their turn to sign comes, with no signing session or email. Requires recipientId pointing to a recipient with an active stored signature (request it with the request_recipient_signature tool) and cannot be combined with embedded. Every required field of the recipient must already have a value before the document is sent, except signature and auto-filled date fields",
+  "type": "boolean"
+}
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / sendSignedCopy
      Added value: +{
+  "description": "Whether to email this recipient the signed document when the document completes. Defaults to true for recipients who sign through the emailed signing link and false for embedded and automatic signing recipients",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.4.0
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / signingOrder
      Added value: +{
+  "description": "Signing order of the recipient, starting from 1. Recipients sign one after another in this order and a recipient is activated once everyone with a lower value has signed. Recipients with the same value can sign in parallel. Provide it for every recipient of a document or for none. Omitted, all recipients can sign immediately",
+  "minimum": 1,
+  "type": "integer"
+}
  3. Changed5 schema fields changedv1.3.0
    • changedInput schema / properties / documents / items / properties / recipients / items / properties / email / description
      Previous value: -"Recipient email address"New value: +"Recipient email address. Required when recipientId is not provided"
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / embedded
      Added value: +{
+  "description": "Embedded recipients sign inside your own application through a short-lived embed link and receive no emails from PDFGate",
+  "type": "boolean"
+}
    • changedInput schema / properties / documents / items / properties / recipients / items / properties / name / description
      Previous value: -"Recipient display name"New value: +"Recipient display name. Required when recipientId is not provided"
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / recipientId
      Added value: +{
+  "description": "ID of a stored recipient to reuse. Provide either recipientId or email and name, never both",
+  "type": "string"
+}
    • removedInput schema / properties / documents / items / properties / recipients / items / required
      Removed value: -[
-  "email",
-  "name"
-]
  4. Changed4 schema fields changedv1.2.0
    • changedInput schema / properties / documents / items / properties / recipients / items / properties / reminderAttempts / description
      Previous value: -"Maximum number of reminder emails"New value: +"Maximum number of reminder emails (defaults to 5)"
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / reminderAttempts / maximum
      Added value: +10
    • addedInput schema / properties / documents / items / properties / recipients / items / properties / reminderAttempts / minimum
      Added value: +1
    • addedInput schema / properties / expiresInDays
      Added value: +{
+  "description": "Days until the envelope and its signing links expire, counted from creation. Defaults to the account's envelope expiration setting.",
+  "maximum": 90,
+  "minimum": 1,
+  "type": "integer"
+}
  5. First observedv1.0.1

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses the created-status lifecycle, that emails are not dispatched until send_envelope is called, and the differences between hosted, embedded, and autoSign recipients. It still omits permission requirements and error/idempotency behavior, so it is strong but not exhaustive.

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 front-loaded with the core action and then efficiently explains recipient modes, sequencing, and the next lifecycle step. It is dense but appropriately sized for a complex nested create operation, with no wasted 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?

For a complex nested create tool with no annotations or output schema, the description covers the key lifecycle, recipient modes, sequencing, and next step well. It does not describe auth/error behavior or the returned envelope fields, but the rich input schema covers parameter-level details, making those omissions minor.

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 100%, so the schema already carries most parameter detail. The description adds useful meaning by explaining the three recipient signing modes, cross-referencing create_embed_link and request_recipient_signature, and clarifying the sequencing purpose of signingOrder.

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 states a specific verb and resource: create a signing envelope from existing PDFGate documents. It clearly distinguishes the tool from lifecycle siblings such as send_envelope, void_envelope, and delete_envelope by explaining that it returns an envelope in 'created' status.

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

Usage Guidelines5/5

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

It explicitly tells the agent to call send_envelope afterward to dispatch signing emails, and it names create_embed_link for embedded signing and request_recipient_signature for automatic signing. It also explains when and how to use signingOrder for sequential signing, giving clear usage context and alternatives.

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

Deploy Server

Other Tools