Sign PDF

Change a request before it is sent

update_signature_request

DestructiveIdempotent

Change a request before anyone gets it: one that waits for review (sent with review: true) before the user clicks Send, or one that waits for the user to sign first. It changes who signs (add, remove or replace people), the signing order, the title, the note to the signer, the markdown text, or where a signature, date or text box sits. Nothing is sent, and the review or signing link stays the same. Give signers as the whole list in the new order, 1 to 5 people; each person keeps their own fields by email, a removed signer's fields go, and a new signer gets a signature block (markdown and Portant's signature page) or the boxes in add_fields (a PDF with placed fields; with none, one signature box on the last page). Portant builds the document again when a printed name, the people or the title changes. Use it only when the user asks for the change, and confirm the new people with the user first. Needs the request_token. fields are usually set from the card in the chat.

Input Schema

Name	Required	Description
`title`	No	The new title.
`fields`	No	Boxes to move or resize. index is the field number in the document before this change; x, y, width and height are fractions of the page from 0 to 1, measured from the top left. page (from 1) moves the box to another page. When no box is left on Portant's added signature page, Portant removes that page.
`message`	No	The new note to the signer, up to 500 characters. An empty string removes it.
`signers`	No	Every signer in the new order, 1 to 5 people. A person with the same email keeps their fields; a new email takes the place of a person left out, in order, and any more are new signers.
`markdown`	No	Only for a request sent as markdown: the whole document text again, written for the new signers ({{signature:signer}}, then signer2 to signer5). A signer with no signature marker gets a signature block at the end. Text still to fill in, such as [Plan name], is refused.
`add_fields`	No	Only for a PDF whose fields were placed when it was sent: new boxes, usually for a new signer. signer is the position in the new order, from 1; page is from 1; x, y, width and height are fractions of the page from the top left.
`request_id`	No
`request_token`	Yes
`allow_placeholders`	No	Pass true only when the user confirms the square brackets in the new markdown are meant to be in the document.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / add_fields / items / properties / kind / enum

Previous value: -[
-  "signature",
-  "date",
-  "text"
-]New value: +[
+  "signature",
+  "date",
+  "text",
+  "name"
+]

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / fields / description

Previous value: -"Boxes to move or resize. index is the field number in the document before this change; x, y, width and height are fractions of the page from 0 to 1, measured from the top left."New value: +"Boxes to move or resize. index is the field number in the document before this change; x, y, width and height are fractions of the page from 0 to 1, measured from the top left. page (from 1) moves the box to another page. When no box is left on Portant's added signature page, Portant removes that page."

addedInput schema / properties / fields / items / properties / page
```
Added value: +{
+  "minimum": 1,
+  "type": "integer"
+}
```

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / allow_placeholders

Added value: +{
+  "description": "Pass true only when the user confirms the square brackets in the new markdown are meant to be in the document.",
+  "type": "boolean"
+}

changedInput schema / properties / markdown / description

Previous value: -"Only for a request sent as markdown: the whole document text again, written for the new signers ({{signature:signer}}, then signer2 to signer5). A signer with no signature marker gets a signature block at the end."New value: +"Only for a request sent as markdown: the whole document text again, written for the new signers ({{signature:signer}}, then signer2 to signer5). A signer with no signature marker gets a signature block at the end. Text still to fill in, such as [Plan name], is refused."

AddedOct 18, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds substantive behavior beyond them: nothing is sent, the review/signing link stays stable, removed signers lose their fields, the added signature page is removed when empty, markdown placeholders are refused, the document is rebuilt on specific changes, and request_token is required. That is exactly the extra context an agent needs before invoking a destructive mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the safety-critical 'nothing is sent, link stays the same' are front-loaded, and nearly every clause carries information. It is, however, a dense multi-clause block covering several concerns in sequence; light structuring into when-to-use / what-changes / signer-rules would improve scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, destructive, no-output-schema mutation, the description covers scope, safety outcomes, signer replacement semantics, per-format branching (markdown vs. placed-field PDF), field-placement rules, and the request_token requirement. An agent can invoke this correctly without further clarification.

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

Parameters5/5

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

Schema coverage is 78%, so the baseline is 3, but the description goes well beyond field definitions: signers is a whole-list replacement (1–5 people) matched by email, add_fields only applies to PDFs with pre-placed fields and defaults to one signature box on the last page, markdown requires the full text rewritten with signature markers, fields' index refers to numbering before this change, and allow_placeholders is only for user-confirmed brackets. These are semantic rules the schema cannot express.

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 opens with a specific verb and resource and immediately enumerates the two request states it applies to (awaiting review vs. awaiting signer) plus the concrete attributes it can change: signers, order, title, note, markdown, and field placement. This is far more specific than the sibling tools (send_for_signature, cancel_signature_request, update_template) and lets an agent tell them apart without opening a schema.

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 gives an explicit gating condition — 'Use it only when the user asks for the change, and confirm the new people with the user first' — which is real when-to-use guidance, and the 'before anyone gets it' framing implicitly excludes already-sent requests. It does not name a sibling alternative explicitly (e.g., use send_for_signature to dispatch), so it stops short of a 5.

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

All Sign PDF tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?