Skip to main content
Glama

template_create

Create reusable signature document templates by uploading files and defining placeholders for signing roles.

Instructions

Create a SignWell template for reusable signature documents.

RECOMMENDED WORKFLOW:

  1. file_store (provide file_path, file_url, or resource_uri) → returns file_token

  2. file_validate_text_tags (pass file_token) → validates tags are extractable

  3. template_create (pass file_token in files array) → creates the template

REQUIRED PARAMETERS (both are mandatory):

  • files: Array with at least one file object containing:

    • "name": Filename (e.g., "template.docx")

    • One content source (in order of preference):

      • "content_text": Plain text/Markdown to auto-convert to DOCX (RECOMMENDED for generated content)

      • "file_token": Token from file_store (recommended for uploaded files)

      • "file_base64": Base64-encoded file content

      • "file_url": Public URL to the file

      • "resource_uri": MCP resource URI

  • placeholders: Array with at least one placeholder object containing "id" and "name"

STEP-BY-STEP EXAMPLE (using file_token):

  1. Call file_store with {"file_path": "/path/to/doc.pdf"} → get file_token

  2. Call file_validate_text_tags with {"file_token": "..."} → confirm tags are valid

  3. Call this tool with: { "name": "My Template", "files": [{"name": "doc.pdf", "file_token": ""}], "placeholders": [{"id": "1", "name": "Signer"}], "text_tags": true }

ALTERNATIVE (inline base64): { "name": "My Template", "files": [{"name": "doc.pdf", "file_base64": "JVBERi0xLjQK..."}], "placeholders": [{"id": "1", "name": "Signer"}], "text_tags": true }

TEXT TAGS (when text_tags: true): Your PDF must contain these literal text strings as SELECTABLE TEXT (not images):

  • {{signature:1:y}} - Signature field for placeholder id "1"

  • {{date:1:y}} - Date field for placeholder id "1"

  • {{text:1:y:Label}} - Text field with label

  • {{initial:1:y}} - Initials field

The number in the tag (1, 2, etc.) MUST match a placeholder "id" in your request.

CRITICAL: Text tags must be SELECTABLE/SEARCHABLE text in the PDF, not rendered as images or graphics. When generating PDFs programmatically, use text drawing methods (e.g., drawString) with standard fonts. To verify: open the PDF and try to select/copy the tag text with your mouse. If you can't select it, SignWell can't parse it.

MULTI-SIGNER EXAMPLE: { "name": "Contract", "files": [{"name": "contract.pdf", "file_base64": "JVBERi0xLjQK...actual base64 here..."}], "placeholders": [ {"id": "1", "name": "Client"}, {"id": "2", "name": "Vendor"} ], "text_tags": true }

For this example, the PDF should contain: {{signature:1:y}} for Client and {{signature:2:y}} for Vendor.

COMMON ERRORS:

  • Empty arguments {} = You forgot to include files and placeholders arrays

  • "fields": [] in response = PDF doesn't contain valid text tags, or text_tags wasn't set to true

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoTemplate name (e.g., 'Permission Slip').
draftNoIf true, template stays editable. If false, marked Available. Default: false per API.
filesNoREQUIRED. Files to upload. Each needs 'name' plus one of: 'file_url', 'file_base64', or 'resource_uri'.
fieldsNo2D array of fields: one array per file. Required if draft is false.
labelsNoLabels for organizing templates.
messageNoEmail message for signature requests (max 4000 chars).
subjectNoEmail subject for signature requests.
languageNoLanguage for template (ISO 639-1).
metadataNoKey-value metadata (max 50 pairs, key max 40 chars, value max 500 chars).
remindersNoSend signing reminders on day 3, 6, and 10.
text_tagsNoSet TRUE if PDF contains text tags like {{signature:1:y}}. Placeholder 'id' values must match the signer numbers in tags (e.g., id='1' for {{signature:1:y}}).
expires_inNoDays before signature request expires (max 365).
placeholdersNoREQUIRED. Signing roles. Each needs 'id' and 'name'. For text tags, the 'id' must match tag IDs (e.g., id='signer1' matches [sig|req|signer1]).
redirect_urlNoURL to redirect after successful signing.
allow_declineNoAllow recipients to decline signing.
allow_reassignNoAllow recipients to reassign to someone else.
checkbox_groupsNoGrouped checkbox fields with validation.
api_application_idNoAPI Application ID for settings isolation.
apply_signing_orderNoRecipients sign in order.
attachment_requestsNoAttachments recipients must upload.
copied_placeholdersNoRecipients who receive the final document after completion.
decline_redirect_urlNoURL to redirect if document is declined.
Behavior5/5

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

Annotations indicate a non-destructive write operation. The description adds substantial behavioral context: text tag requirements, multi-signer examples, common errors, and critical notes about selectable text. This goes well beyond the annotation hints.

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

Conciseness3/5

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

The description is very long and includes multiple examples that could be condensed. While the structure (sections like RECOMMENDED WORKFLOW) is good, the verbosity exceeds what is necessary for a concise tool description.

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?

Given the complex tool with 22 parameters and no output schema, the description covers workflow, parameter usage, error handling, and edge cases (e.g., text tags vs manual fields). It is highly complete for the agent to use effectively.

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?

With 100% schema description coverage, baseline is 3. The description adds meaning beyond the schema by explaining parameter relationships (e.g., text_tags and placeholder id mapping), providing example calls, and clarifying content source preferences.

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 starts with 'Create a SignWell template for reusable signature documents,' a clear verb+resource statement. It distinguishes from sibling tools like template_create_document by focusing on template creation.

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?

The description provides a detailed recommended workflow (file_store → file_validate_text_tags → template_create) and step-by-step examples. However, it does not explicitly state when not to use this tool or list alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bidsketch/signwell-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server