All connectors
PandaDoc MCP
22 tools · Documents · Content & Files · Model Context Protocol
Create, inspect, send, and manage documents through PandaDoc's hosted MCP server.
Connect PandaDoc MCP
- Open Slashspace and go to Settings, then Connectors.
- On Discover, search for PandaDoc MCP and click Connect.
- Sign in to PandaDoc MCP in your browser. Slashspace updates when the account is connected.
- Then ask for what you need in any Agent mode chat. PandaDoc MCP is on in every chat unless you switch it off.
What your chats can do
22 tools from PandaDoc MCP.
- Documents archiveArchive a document by ID. Uses PandaDoc delete endpoint with forever=false for reversible deletion.
- Documents audit trail getRetrieve audit trail for a document.
- Documents content getReturns the textual content of a document in plaintext or markdown format.
- Documents create# Create document Create a new PandaDoc document. Pass a single `request` object and set its `source` to choose how the document is created: - `source: "template"` — from an existing template. Required: `template_uuid`. Also accepts `name`, `recipients`, `fields`, `tokens`, `metadata`, `tags`, `images`, `pricing_tables`, `tables`, `texts`, `folder_uuid`, `owner`, `detect_title_variables`, `content_placeholders`. - `source: "markdown"` — from markdown content. Required: `name`, `document_markdown`. Also accepts `recipients` (individual recipients only; groups are not supported), `role_fields`, `folder_uuid`. - `source: "file"` — from a downloadable PDF or DOCX file URL. Required: `name`, `url`. Also accepts `recipients`, `parse_form_fields`, `fields`, `tokens`, `metadata`, `tags`, `folder_uuid`, `owner`. The schema is polymorphic on `source`: each source accepts **only** its own parameters. Passing a parameter that belongs to another source is rejected by validation, so you never need to guess which fields are ignored. Not for editing an existing document — use `documents_update` for that. ## Asynchronous creation Document creation is asynchronous for every `source` (template, markdown, and file). A successful tool response means creation was accepted, not that the document is ready. The document starts in `Uploaded` and becomes `Draft` once it is ready. After calling this tool: 1. Poll `documents_status_get` until it reports `Draft`, or until it returns an error. 2. If `Draft`, the document is ready to edit, send, or fetch details/content. 3. If `documents_status_get` returns an error, creation failed (invalid file, markdown conversion failure, validation errors, etc.). Report `error.detail` and do not call details/content/edit/send on it. This is terminal — `error.retryable` is `false`, so stop polling. 4. While status is still `Uploaded`, do not assume success and do not call tools that require a ready document. A failed creation is reported for roughly 8 hours. After that a status lookup reports the document as not found — treat that as the same terminal failure, not a reason to resume polling. ## Template Create a document populated from an existing PandaDoc template. Requires `template_uuid`. Recipients are optional — omit them to use template defaults or to add them later. If the template isn't known yet, call `templates_list` first, then `templates_details_get` to discover its roles, fields, and variables. Optionally set fields, tokens, pricing tables, recipients, and other template data. ## File Create a document from a PDF or DOCX file referenced by `url`. The URL must be directly downloadable (no auth, no HTML interstitials) — presigned S3/GCS/Azure URLs or direct CDN links work best; Google Drive and Dropbox share links do not (they return HTML, not the file). To parse fillable PDF form fields, set `parse_form_fields: true` and provide `fields` mapping **every** form field name to a recipient role — omitting any causes failure. ## Markdown Create a new document in PandaDoc from markdown when there is only text representing the document content. Document content must be generated according to the guidelines below. The response includes a `document_url` field with a direct URL to open the created document in PandaDoc. ### Markdown guidelines You can use standard CommonMark and GitHub-Flavored Markdown (tables, strikethrough, etc), plus the following custom extensions: #### Custom Syntax Extensions ##### 1. Variables Variables are placeholder values that the document creator fills in PandaDoc before sending to recipients. Prioritize variables over fields for any value that the sender controls or pre-fills, even if it may be visible to recipients. **Syntax:** `[VariableName]` or `[Variable.Name]` or `[Multi.Part.Variable]` - Can include underscores, numbers, and multiple dot-separated parts **Use variables for values controlled by the document creator:** - Document metadata: `[Effective.Date]`, `[Agreement.Number]`, `[Contract.Value]` - Company/sender information: `[Company.Name]`, `[Company.Address]` - Pre-calculated values: `[Invoice.Total]`, `[Discount.Amount]` - Recipient information already known: `[Recipient.CompanyName]`, `[Recipient.FirstName]` **Key principle:** If the sender controls the value, use a variable. ##### 2. Fields Fields are interactive form elements that recipients fill in or interact with during the signing process. Recipients see these as input boxes, checkboxes, or signature areas. **Use fields for values controlled by the recipient:** - Recipient signatures: `[[signature]]` - Recipient personal data they must enter: `[[text]]`, `[[email]]`, `[[phone]]`, `[[date]]` - Recipient choices/consents: `[[checkbox]]` - Information only the recipient knows or decides **Key principle:** If the recipient controls the value, use a field. Fields can be prefilled with default values, but are typically left empty for the recipient to fill. **Syntax:** `[[field_type attributes]]` **Field Types:** - `text` - Text input field - `email` - Email input field - `phone` - Phone number input field (**`format` is required** — see below) - `number` - Number input field - `date` - Date input field - `checkbox` - Checkbox field - `signature` - Digital signature field - `dropdown` - Dropdown selection field (**`option` is required** — see below) **Attributes (HTML-style):** - `required="true"` - Makes field required - `placeholder="text"` - Placeholder text - `checked="true"` - Pre-checked (checkbox only) - `value="timestamp"` - For date fields, use UNIX timestamp with millisecond precision (e.g., value="1718406000000"). For other fields, use plain text (e.g., value="John Doe"). - `format="US"` or `format="international"` - **Required for `phone` fields.** Must be exactly `"US"` or `"international"`. There is no default — omitting it causes a validation error. - `date_format="yyyy/MM/dd"` - Date format in ICU notation (e.g., `"dd/MM/yyyy"`, `"MM-dd-yyyy"`). Defaults to `"yyyy/MM/dd"` if omitted. - `option="Text"` - **Required for `dropdown` fields.** Repeatable — add one per option (e.g., `option="Yes" option="No"`). To assign a stable UUID to an option, use `option="uuid:Text"` format. - `id="Client_Text1"` - Specify an external ID that describes who should fill this field and what it represents (e.g., `id="Client_Signature"`, `id="Landlord_FullName"`, `id="Buyer_Email"`). Use the pattern `<RecipientRole>_<FieldPurpose>` so the field can later be assigned to the correct recipient. Multiple fields MAY share the same ID (they'll be synced — when one is filled, all are filled with the same value), but they MUST have the same type and attributes. **This is also the only value `role_fields[].field_ids` may reference** (see below) — a field with no `id="..."` cannot be pre-assigned to a role. **Assigning fields to roles via `role_fields`:** to pre-assign a field to a recipient's role at creation time, give the field an `id="..."` in `document_markdown`, then reference that exact same string in `role_fields[].field_ids`. A `field_ids` value that does not match any `id="..."` in `document_markdown` is rejected — never invent a `role_fields` value without first setting the matching `id="..."` on the field: ```text document_markdown: "Signed: [[signature id=\"Signer_Sig\"]]" role_fields: [{"role": "Signer", "field_ids": ["Signer_Sig"]}] ``` **Examples:** - `[[text placeholder="Enter name"]]` - `[[email required="true" placeholder="Email address"]]` - `[[phone format="US"]]` - `[[phone format="international"]]` - `[[number]]` - `[[date required="true" value="1718406000000"]]` - `[[date date_format="dd/MM/yyyy"]]` - `[[checkbox checked="true"]]` - `[[dropdown option="Yes" option="No"]]` - `[[dropdown option="Yes" option="No" value="Yes" placeholder="Choose..."]]` **Important:** Fields with the same ID must have the same type and attributes. For example, you cannot have `[[text id="Field1"]]` and `[[email id="Field1"]]` in the same document as well as `[[text id="Field2" placeholder="Full Legal Name" ]]` and `[[text id="Field2"]]` because they have different attributes. **Dropdown constraints:** - At least one `option` attribute is required. - Option texts must be unique within the dropdown. - If `value` is set, it must match one of the defined option texts exactly; otherwise a validation error occurs. ##### 3. Standalone Checkboxes Checkboxes use GFM syntax but can appear anywhere, not just in lists: - `[ ]` - Unchecked - `[x]` - Checked - Can be used inline, standalone, or in task lists ##### 4. Page Breaks **Syntax:** `---` (three hyphens) creates a page break. **IMPORTANT:** Page breaks should be rare and intentional. Most documents don't need page breaks. Only use `---` when content **must** be on separate pages for a specific reason: - Legal/structural requirement - Document structure demands it **Do NOT use `---`:** - Between sections (use headings: `## Section Title`) - As visual decoration (use blank lines) - Simply because there's a section transition ### Limitations (Features NOT Supported) **Do NOT include:** - Raw HTML, including `<br>`, `<u>`, and `<div>` - Blockquotes inside lists - Images inside links inline with text (e.g., `[](link)`) - Merged table cells **Field syntax rules:** - Field types must be lowercase and match the closed set exactly (`text`, `email`, `phone`, `number`, `date`, `checkbox`, `signature`, `dropdown`). Capitalized or otherwise altered forms are not recognized. - The only valid syntax is `[[field_type attributes]]`. Forms like `[[Signature|Signer]]`, `[[signature:sig_a]]`, `[[s:Owner1]]`, and `[[signature_1]]` are not recognized — use `[[signature id="Signer_Signature"]]` instead. - Fields sharing the same `id` must have the same field type — a mismatched type is rejected. `signature` fields cannot share an `id` with any other field, including another `signature` field. - Every value passed in `role_fields.field_ids` must match the `id` attribute of a field present in `document_markdown`.
