Skip to main content
Glama
Sign In

Sign PDF

by co.portant
OverviewDiscussionsAdmin

Save a template

save_template

Save a document as a template without sending it to anyone. Use it when the user asks to save, upload or add a template, for example "make a sales contract and save it as a template". Give the document as markdown you wrote (with the same field tokens as send_for_signature, such as {{signature:signer}}, {{text:signer:Company name}} or {{signature:sender}}; for what changes on each send, such as the customer, price or start date, write a named field such as {{var:Customer company}} or [Customer company], so each send fills it from document.values), a PDF (upload_id, pdf_url or pdf_base64), or a Google Doc link shared with "anyone with the link" (saved as the link, so each send uses the Doc as it is then). Portant checks the document the way a send would, then saves it. Returns template_id; send it later with send_for_signature and document.template_id. Plus and Scale plans; needs Portant connected with sign-in.

Input Schema

NameRequiredDescriptionDefault
nameYesA short name for the template, with no signer name in it, for example "Sales agreement". A send from the template uses it as the title.
fieldsNoOnly for a PDF or Google Doc, when you know where the fields go. The same as fields in send_for_signature. Without fields, each send looks for the signature lines in the document, and adds a signature page when it cannot place them.
documentYesExactly one of these, except that template_id can come with values and markdown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / document / properties / markdown / description
      Previous value: -"The document as markdown. Put {{signature:signer}}, {{date:signer}}, {{text:signer:Label}}, {{signature:sender}} or {{date:sender}} where each field goes, or leave them out and Portant adds a signature block at the end. With several signers, signer is the first and signer2 to signer5 the next ones, for example {{signature:signer2}}. With template_id: the template text after you changed it for this send (get it with get_template, put the values in, change only what the user asked for); the request then waits for the user to review the changes. Text still to fill in, such as [Plan name] or {{var:Plan}}, is refused."New value: +"The document as markdown. Put {{signature:signer}}, {{name:signer}}, {{date:signer}}, {{text:signer:Label}}, {{signature:sender}}, {{name:sender}} or {{date:sender}} where each field goes, or leave them out and Portant adds a signature block at the end. When you place the fields yourself, give each person a {{name:...}} beside their signature: Portant fills it with the full name the person types when they sign, as it fills the date, so do not add a text field for the name. With several signers, signer is the first and signer2 to signer5 the next ones, for example {{signature:signer2}}. With template_id: the template text after you changed it for this send (get it with get_template, put the values in, change only what the user asked for); the request then waits for the user to review the changes. Text still to fill in, such as [Plan name] or {{var:Plan}}, is refused."
    • changedInput schema / properties / fields / items / properties / kind / enum
      Previous value: -[
-  "signature",
-  "date",
-  "text"
-]New value: +[
+  "signature",
+  "date",
+  "text",
+  "name"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / fields / description
      Previous value: -"Only for a PDF or Google Doc, when you know where the fields go. The same as fields in send_for_signature. Without fields, each send adds a signature page."New value: +"Only for a PDF or Google Doc, when you know where the fields go. The same as fields in send_for_signature. Without fields, each send looks for the signature lines in the document, and adds a signature page when it cannot place them."
  3. Changed1 schema field changed
    • changedInput schema / properties / document / properties / pdf_base64 / description
      Previous value: -"A PDF as base64. Prefer upload_id or pdf_url for files over 1 MB."New value: +"A small PDF as base64. For a PDF file, including one you made with a file skill, or any PDF over 1 MB, use upload_id (get_upload_url) or pdf_url."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations mark this as a non-readonly, non-idempotent, open-world write. The description adds context beyond those: it validates the document 'the way a send would', states plan gating (Plus and Scale), requires Portant connected with sign-in, rejects unfilled placeholders, and describes what gets saved (link vs. PDF vs. markdown) and what is returned (template_id). This is substantive behavioral disclosure.

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 is front-loaded and every sentence carries operational detail (token syntax, plan gating, return value). It is dense and the long parenthetical about markdown/template_id runs on, but little is filler.

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?

Despite no output schema and a nested document object, the description covers inputs, validation behavior, auth and plan prerequisites, and the return (template_id plus how to use it with send_for_signature). An agent has everything needed to invoke it correctly.

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 coverage is 100%, so the baseline is 3. The description earns more by explaining token syntax ({{signature:signer}}, {{var:Customer company}}), how named fields map to document.values on each send, and how the same field tokens mirror send_for_signature. It adds real semantics beyond the schema, though the fields/positions object is left mostly to the schema.

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?

States a specific verb and resource ('Save a document as a template') and immediately distinguishes from send_for_signature by adding 'without sending it to anyone'. An agent can tell this apart from siblings like get_template, update_template, and send_for_signature without opening any schema.

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?

Gives an explicit trigger ('when the user asks to save, upload or add a template') with a worked example, and routes the agent to related tools — get_upload_url for PDFs, get_template for template editing, send_for_signature for later sending. When-to-use and alternatives are both covered.

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

All Sign PDF toolsInspect
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