How to connect PandaDoc MCP with Claude Desktop

Retrieve audit trail for a document.

Resolve an email address to the contact it belongs to. Use it to get the `contact_id` that `recipients_add_cc` needs, or the `new_contact_id` that `recipients_reassign` needs. For someone already on the document, skip this lookup: `documents_details_get` returns `contact_id` on each recipient alongside the recipient's own `id`. The match is on the full email address and nothing else: there is no search by name, by company, or by part of an address. When the user names a person without an email, ask for the email rather than guessing one. Returns no contact when the workspace address book holds none for that address.

Paginated document listing with structured filters: status, folder, tag, free-text search, sorting, and created/completed date ranges. Examples: 'list 50 Draft docs' · 'documents in folder <folder_uuid> tagged onboarding' · 'page 3 sorted by date_modified' For natural-language queries, prefer ``ai_search`` if available.

Full-text search with status/date filters. Examples: 'NDA in completed docs' · 'modified 2026-01-01–2026-03-31' · 'sent docs Q1 2026' For natural-language queries, prefer ``ai_search`` if available. If the user refers to a document by name and an ID is needed for a downstream operation, use this tool to resolve the name to an ID first. Do not ask the user for a document ID before attempting this lookup.

# 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. Required: `name` and exactly one of `url` or `file_uuid`. 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 using exactly one file reference: - `url` — a directly downloadable URL with no authentication or HTML interstitial. - `file_uuid` — the reference returned by the file-upload tool, when available. First upload the file bytes to its `presigned_url` with an HTTP PUT, then call this tool with the returned `file_uuid`. The uploaded file is checked for ownership, allowed type, size, and malware before document creation. If `files_request_upload_url` is unavailable, do not invent a `file_uuid`. Use a direct downloadable URL when provided; otherwise recreate the content with `markdown`. Presigned S3/GCS/Azure URLs or direct CDN links work best for `url`. Google Drive and Dropbox share links do not work because they return HTML instead of 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. > **Making a recipient a Signer — three things must line up.** A recipient becomes a Signer only when a field is assigned to their role. To assign one, all three of these must agree: > > 1. Give the field an `id` in `document_markdown` — e.g. `[[signature id="Signer_Sig"]]`. > 2. Add a recipient whose `role` matches — e.g. `{ "email": "signer@example.com", "role": "Signer" }`. > 3. Map the role to that id in `role_fields` — e.g. `[{ "role": "Signer", "field_ids": ["Signer_Sig"] }]`. > > A bare `[[signature]]` with no `id`, or a recipient that no `role_fields` entry references, is added as **CC** and cannot sign. Always set an `id` on signature/date fields the recipient must complete and reference it from `role_fields`. **Use fields for values controlled by the recipient:** - Recipient signatures: `[[signature id="Signer_Sig"]]` (see the Signer callout above — a signature with no `id` and no `role_fields` mapping leaves the recipient as CC) - 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 ##### 5. Pricing Tables A pricing table is a table of line items followed by a list of totals, wrapped in HTML comment markers that the reader never sees. Use one whenever the document quotes prices: quotes, proposals, order forms, invoices. **Without the markers it is an ordinary table** — the numbers come back as plain text, with no currency, no quantities and no recalculation. **Syntax:** ```markdown <!-- pandadoc:pricing-table name="Services" --> | Name | Description | Price | QTY | Tax | Subtotal | |------------|-------------|-------------|-----|------|-------------| | Consulting | Senior rate | 2000.24 USD | 3 | 23 % | 6000.72 USD | * Subtotal: 6000.72 USD * Discount: -10 % * Total: 5400.65 USD <!-- pandadoc:end-pricing-table --> ``` **Columns** are matched by name: - `Name` — **required**, on every row. Text, may be formatted. - `Price` — **required**, on every row. An amount, e.g. `2000.24 USD`. - `Description` — text, may be formatted - `SKU` — text - `Cost` — an amount - `QTY` — a number. Added for you (as 1) if the column is left out. - `Tax` — a percentage (`23 %`) or an amount (`50.00 USD`) - `Discount` — a percentage (`-10 %`) or an amount (`-50.00 USD`), written negative - `Subtotal` — an amount. Added for you if the column is left out. An empty `Name` or `Price` cell is an error, and a column not in this list is kept as text under the name you wrote. `Tax` and `Discount` may each be a percentage or money, but a single column has to agree with itself: one mixing `-10 %` and `-5.00 USD` is an error. **Footer totals** go in a list directly under the table as `Name: value`. Only `Subtotal`, `Discount`, `Tax`, `Total` and `Total QTY` are accepted; any other total is an error. **The name** builds the document's tokens: a table named `Services` with a `Total` gives you `[Services.Total]` to use in any paragraph. Two tables may not share a name; an unnamed table takes the next free `Pricing Table N`. **The end marker** may be left out for a single table, which then reads as the table after the marker plus the totals after that. It is **required** for a table in sections, and it stops an unrelated table further down being swallowed into the prices. **Sections and optional items** — a heading above a table titles that group of line items, and every section must describe the same columns. A checkbox before the name offers the item rather than including it; no box means it is simply part of the quote. `[optional]` on a section heading lets the reader drop the whole section, `[choose one]` limits it to a single ticked row: ```markdown <!-- pandadoc:pricing-table --> ### Setup | Name | Price | |---------|------------| | Install | 500.00 USD | ### Add-ons [optional] | Name | Price | |-----------------------|------------| | [ ] Extended warranty | 200.00 USD | | [x] Support plan | 100.00 USD | * Total: 600.00 USD <!-- pandadoc:end-pricing-table --> ``` **Currency** comes from the amounts themselves, which must all agree on one. A currency code (`2000.24 USD`) always names it; a symbol only when it belongs to a single currency — `zł` is Poland's alone, but `$` is shared by many and names none. **Not supported in a Markdown pricing table:** photos, tiered ("buy 10+") prices, per-item editable quantities, column width, lock and colour, and the CRM datasource. Those are set in the PandaDoc editor. ##### 6. Money Formatting By default amounts are read the Anglo way — `.` splits decimals, `,` groups thousands, and the currency code follows the number (`1,234.56 USD`). If the document writes money any other way, say so in YAML front matter at the very top of the file: ```markdown --- pandadoc: money: display_as: symbol position: before separate_with_space: true precision: 2 decimal_delimiter: comma thousand_delimiter: space --- ``` With that block, `zł 2 000,24` reads as two thousand. All six settings are required when the block is present: - `display_as` — `no_code`, `symbol`, `code`, `code_and_symbol` - `position` — `before`, `after` - `separate_with_space` — `true`, `false` - `precision` — a number of decimal places, e.g. `2` - `decimal_delimiter` — `dot`, `comma`, `space`, `quote`, `no_delimiter` - `thousand_delimiter` — same values as `decimal_delimiter` These say **how** money is written, not which currency it is. Quantities and percentages carry no currency but are written the same way, so a document splitting decimals with a comma writes `1,5` and `7,25 %`. Digits that are not grouped in threes are an error rather than a guess, so write amounts consistently with the settings you declared. **Note:** front matter opens with `---`, which is also the page break. The block is only read as front matter at the very top of the file naming `pandadoc`; a `---` anywhere else stays a page break. ### 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`.

Update a document. Document must be in Draft status. You can update text blocks, fields, and other document properties. After creating a new document, wait for it to reach Draft status before updating. To modify individual recipients, use `recipients_*` tools — the `recipients` param here replaces the entire list.

Manually change a document's status. Only these transitions are allowed: Completed, Paid, Expired, or Declined. Status changes are restricted based on the current document status. Other statuses (such as Sent, Viewed, Approved) are set automatically by the system and cannot be set with this tool.

Send a document to its recipients. The document must be in Draft status. After sending, the status changes to Sent and recipients receive a notification. Use skip_unfilled_variables to send even when some variables are empty. Pass selected_approvers only if documents_details_get shows an `approval_execution`; if absent, send without it. Always confirm with the user before sending.

Retrieve the overall document status (e.g. Draft, Sent, Completed, Expired). Some statuses are set automatically by the system: Sent (when the document is sent), Viewed (when a recipient opens it), Approved/Rejected (via approval workflows). For per-recipient signing progress use documents_details_get. Right after creating a document it may still be processing — if so, wait briefly and check again before acting.

Retrieve a document's full structure by document_id: name, status, dates, version, reference number, creator, template, recipients, fields, variables, tokens, tags, pricing/grand total, and linked objects. Use to inspect a document before acting on it. Does not return extracted metadata — use `documents_metadata_batch_get` for that; for the overall status only, use `documents_status_get`.

Returns a summary for the specified document. Supports three granularity levels: detailed, short, or headline. If not ready, returns `{retry_after: N}` where N is seconds to wait before retrying.

Returns the textual content of a document in plaintext or markdown format.

Use to read the business terms extracted from documents — counterparty, contract value, dates, renewal terms — without fetching and re-reading their full text. Handles 1-40 documents per call, so pass a one-element `document_ids` for a single one. Narrow the response with `field_keys` when only certain terms matter. Extraction generally runs once a document is completed, so a document still being worked on may have nothing to return yet. Each document reports its own outcome, so one failure does not lose the rest: `ok` carries that document's fields, `extraction_pending` should be retried after `retry_after` seconds, `extraction_not_started` means the document is not completed yet, `extraction_failed` is terminal (contact support), `not_found` and `access_denied` mean the document cannot be read, and `internal_error` is safe to retry for that document alone.

Assign, reassign, or unassign document fields to recipients. The document must be in draft status. Provide a list of field-to-recipient mappings. Set recipient_id to null to unassign a field. Use get document details to obtain field UUIDs (fields[].uuid) and recipient IDs (recipients[].id). Once a field is assigned, that recipient becomes a signer for it. If it's unclear which recipient a field belongs to, ask the user before assigning.

Archive a document by ID. Uses PandaDoc delete endpoint with forever=false for reversible deletion.

Update one recipient's details (email, name, phone, company, address, redirect) in place. Signers can be edited in Draft, Waiting Approval, Approved, Rejected, Sent, or Viewed status. A signer's email cannot be changed after they have signed. CC recipients can be edited in any status except Expired or Declined. Get recipient_id from document details first. Cannot use emails of existing contacts — use `recipients_reassign` for that.

Add a CC (non-signing) recipient to a document. Requires an existing contact ID, which is not the same as a recipient id. For someone already on the document, take `contact_id` from that recipient in `documents_details_get`. Otherwise resolve their email with `contacts_list`. Cannot add to Expired or Declined documents. Adding a contact that is already a CC recipient is silently ignored. This tool only adds CC recipients; signers must be set via `documents_create` or `documents_update`.

Replace a signer with another contact. `recipient_id` is the signer being replaced, from the recipient's `id` in document details. `new_contact_id` is the replacement's contact ID, never a recipient id: take it from that recipient's `contact_id` in document details when they are already on the document, and otherwise resolve their email with `contacts_list`. Transfers all assigned fields to the new signer. The original signer is removed. Cannot reassign already-signed recipients. To just fix a signer's email/name, use `recipients_edit`.

Remove a recipient from a document. Signers can only be removed in Draft status. CC recipients can be removed in any status except Expired/Declined.

Discover, browse, or pick a template by name, tag, or folder (e.g. 'what templates do we have?', 'find the NDA template'). If the user refers to a template by name and an ID is needed for a downstream operation, use this tool to resolve the name to an ID first. Do not ask the user for a template ID before attempting this lookup. Returns a paginated list of templates. Pass a returned `id` as `templates_details_get`'s `template_id` to inspect roles/fields/variables, or as `documents_create`'s `template_uuid` to generate a document. Not for searching documents (use `documents_list`) or creating one.

Create a new template from a PDF URL. Provide a secure (HTTPS) publicly accessible URL to the PDF document.

Inspect a template's schema — roles, fields, variables, pricing tables, content placeholders, tags, metadata — usually to prepare a `documents_create` call (e.g. 'what roles does the Sales Contract template expect?'). Typical flow: `templates_list` -> this tool -> `documents_create`. Not for listing templates or fetching a regular document.

Update an existing template's CUSTOM variables (tokens) and/or its signer roles. Provide `tokens` to upsert variables by name, and/or `roles` to replace the full list of roles. Inspect current roles and variables with `templates_details_get` first. At least one of `tokens` or `roles` must be provided. This tool does not rename a template or edit its content/pages. A newly created template needs a few seconds to finish processing before it can be updated; if an update fails immediately after creation, wait briefly and retry. This returns only a confirmation, not the updated template — to read the UUIDs of any newly created roles, call `templates_details_get` afterwards.

Create a copy of an existing template within the same workspace. Optionally provide a `name` for the copy; when omitted or empty, a name is auto-generated from the source template. Returns the new template's id and name, plus the source template id.

Delete a template by ID. The template is moved to the deleted state and no longer appears in normal listings (it can still be found by listing with the deleted filter). Confirm with the user before deleting.

Send a reminder to recipients of a document that is out for signature, so the ones who have not completed their part are prompted again. The document must be in Sent or Viewed status. Reminders reach real people by email and/or SMS, so confirm with the user which recipients to remind before calling. Take recipient ids from the document's details; recipients left out of the call are not reminded. To word the email yourself, pass subject and message at the top level of the call — they apply to every recipient in it. This call can succeed as a call and still deliver nothing: it always answers with one entry per requested recipient, carrying a status for both email and SMS. Report a reminder as sent only where that status is `sent`. Where a method you requested has any other status, name the recipient, the method and the reason from `detail`, and do not call the request successful. A method you did not request always reports `error` with "delivery method is not selected" — that is expected, not a failure, and must not be mentioned to the user.

Search the current workspace's contacts by first name, last name, or company. This tool does not search by email address; use contacts_list for an email address instead. Results can contain several contacts with the same name, so confirm which contact the user means before making a change. To add a returned contact as a CC, pass its id to recipients_add_cc as contact_id. To replace a signer with a returned contact, pass its id to recipients_reassign as new_contact_id.

Search the workspace's product catalog by free text across item name, SKU, description and category name, with optional filters. Use this to identify an existing catalog item before quoting its price or adding it as a line item. A query with no matches returns an empty list — treat that as "nothing found," not an invitation to guess a price or an item yourself. `pricing_model` and `billing_type` are independent — read both. `pricing_model` says whether `price` is a flat unit amount ("fixed") or depends on quantity tiers ("volume_based" — get tier detail from `catalog_item_get`, and never present its `price` as a flat unit price). `billing_type` says whether that amount is charged once ("one_time"), per `billing_period` ("recurring"), or has no defined billing cadence ("unspecified"). A "volume_based" item can also be "recurring". Call `catalog_item_get` once a specific item has been identified — for example by an exact SKU, an unambiguous search result, or the user picking one of the candidates — when full tier or bundle detail is needed. If no single result is clearly the one the user meant, list the candidates rather than choosing silently. Include `sku` and, when available, `price` with `billing_period` when applicable. For a "volume_based" candidate, say it's volume-priced instead of quoting `price` as a flat amount.

Get full detail for a specific catalog item by UUID — use once an item has been identified (for example via `catalog_items_search`) and its complete pricing, custom fields, or bundle composition are needed. Each pricing block (`default_pricing`, and each variant's `pricing` entries) reports `tiers` when the item is priced by quantity — in that case `price` alone is not the amount to quote, use the tiers instead. `billing_period` is set only when `billing_type` is "recurring"; otherwise ignore it. `variants` lists the item's purchasable configurations (usually one), each with its own SKU, status, and custom fields (up to 200). `bundle_items`, when present, lists what the bundle contains — each entry is either a reference to another catalog item (with its own `pricing`) or a one-off custom line (flat `price`/`currency`, no catalog reference). Customer-facing bundle customization rules are not included here.

Permanently delete a single catalog item by UUID. This cannot be undone — there is no soft delete and no restore, and this includes its pricing, custom fields, and bundle composition. Documents already sent that reference this item are unaffected (their line values were copied at send time). Before calling this, use `catalog_items_search` or `catalog_item_get` to resolve the UUID to the item's name and SKU, if present, and explicitly ask the user to confirm deleting that specific item by name. Do not call this from an earlier request to find, view, or modify the item alone — only after the user has explicitly agreed to the deletion in this exchange. Call this once per item; there is no bulk delete.

Create a new item in the workspace's product catalog. This is a write operation — always call `catalog_items_search` first to check for an existing item with a similar name or SKU, and warn about close matches instead of silently creating what may be a duplicate. Before calling this, show the user exactly what will be created (title, price, SKU, and bundle contents if any) and explicitly ask them to confirm. Do not call this from an earlier request to search, price, or discuss an item alone — only after the user has explicitly agreed to create it in this exchange. For flat pricing, set `price_configuration.price` and leave `pricing_model` as "fixed". For quantity-tiered pricing, set `pricing_model` to "volume_based" and provide `tiers` instead — never invent a flat price for a volume-priced item. Set `billing_type` to "recurring" only when the item is charged on a repeating cycle, and always pair it with `billing_cycle`. Set `type` to "bundle" to create a bundle instead of a regular item. `bundle_items` is required when `type` is "bundle" (up to 300 lines) and must be omitted otherwise. Each line is either a reference to an existing regular catalog item (`kind: "catalog_item"`, with its `uuid` — resolve this via `catalog_items_search`/`catalog_item_get` first; this fails with a clear error if the uuid doesn't resolve to an existing regular item) or a one-off custom line not backed by any catalog item (`kind: "custom"`, with its own `title`/`price`/`currency`). The bundle's own `price_configuration` is always a flat price or tiers you set directly, exactly like a regular item — it is never derived automatically from the bundle's contents, regardless of what those contents cost or how they're billed. This tool's response never includes bundle composition, even for a bundle — call `catalog_item_get` on the returned `uuid` afterward if you need to confirm what was actually created. If the workspace's plan doesn't include Product Catalog, or the caller's role can't edit the catalog, this fails with a human-readable error rather than creating anything — never invent a price or silently retry as a different user.

Update fields on an existing catalog item by UUID. This is a write operation — call `catalog_item_get` first, show the user a before → after comparison of what will change (price especially), and explicitly ask them to confirm this specific change. Do not call this from an earlier request that only found or viewed the item — only after the user has explicitly agreed to this exact change in this exchange. Every field is optional — set only the ones that should change. A field that is left out, or explicitly set to `null`, is left untouched — `null` is not a way to clear a field's current value except where a field's own description says otherwise. `custom_fields`, when set to an array, replaces the item's entire custom fields list (not a merge) — send an empty array to clear it. Only `type=regular` and `type=bundle` items can be updated through this tool; calling it on a "custom" item fails with a clear error rather than changing anything. Bundles cannot be created here — use `catalog_item_create` with `type: "bundle"` for that. `bundle_items`, when set, replaces the bundle's entire composition (not a merge) and can only be set on an item that is already a bundle — setting it on a regular item fails with a clear error rather than converting it, and it cannot be an empty list (there is no way to clear a bundle's composition through this tool). Each line is either a reference to an existing regular catalog item (`kind: "catalog_item"`, with its `uuid` — this fails with a clear error if the uuid doesn't resolve to an existing regular item, rather than silently dropping the line) or a one-off custom line (`kind: "custom"`, with its own `title`/`price`/`currency`) — see `catalog_item_create`'s `bundle_items` for the full shape. Leave `bundle_items` out entirely to leave a bundle's composition unchanged; this tool never changes an item's `type`. This fails if the bundle has customer-facing configuration (selection groups and/or rules) that reference its current lines by id, since replacing the composition risks breaking those references. For flat pricing, set `price_configuration.price`. For quantity-tiered pricing, set `price_configuration.tiers` instead — never invent a flat price for a volume-priced item. Set `billing_type` to "recurring" only when the item is charged on a repeating cycle, and always pair it with `billing_cycle`. `price_configuration`'s sub-fields follow the same "leave it out to leave it unchanged" rule as the top-level fields — changing only `price` means sending `price_configuration: {"price": ...}` with nothing else in it. Never include `pricing_model`, `billing_type`, `billing_cycle`, or `currency` unless you intend to change that specific thing, and never guess a value for one of them from context — check `catalog_item_get`'s response for the current value first if you're unsure. Including one of these with the wrong value silently changes it alongside the field you meant to update. For multiple items ("raise these 5 prices"), summarize the full change set for every item and get one explicit confirmation covering all of them before calling this tool repeatedly — cap this at roughly 20 items per run. For larger bulk repricing, point the user at catalog CSV export/import instead. If the workspace's plan doesn't include Product Catalog, or the caller's role can't edit the catalog, this fails with a human-readable error rather than changing anything — never invent a result or silently retry as a different user.

Update one or more existing quotes on a document — sections, line items, prices, quantities, discounts, fees, and taxes. Up to 25 quotes per call; each quote is applied independently, so one quote's failure never affects the others. This tool cannot create a new quote, and a quote cannot be created at document-creation time either — only existing quotes (already present on the document) can be updated. Destructive replace, not a diff: including `sections` replaces the quote's ENTIRE section list — any current section whose id is left out is REMOVED. The same applies one level down: including `items` on a section replaces that section's ENTIRE item list — any current item whose id is left out is REMOVED (pass an empty list to clear all items from a section). To change only part of a quote/section, first fetch its current state and include every section/item you want to keep, changing only the fields that need to change. Fields left out of an included section/item are left untouched; a field explicitly set to `null` where the schema allows it (`name`, `billing_frequency`, `contract_term`) clears that field instead. `options` (on a line item) and `settings` (on a section or quote) are all-or-nothing: when included, every property in them must be given a value — there is no partial update of a single property inside these objects. Returns one result per requested quote, in the same order as the request, keyed by `id` and discriminated by `status`: `ok` carries the quote's full state after the update; `not_in_document` (the quote id is not linked to this document, or the caller lacks edit access to it), `not_found` (no such quote), and `conflict` (the quote was updated concurrently — refetch and retry) are per-quote outcomes that leave the other quotes in the batch unaffected; `internal_error` is an isolated per-quote failure safe to retry on its own.