Skip to main content
Glama

document_create

Create a draft document for electronic signatures. Upload a file, specify recipients, and receive an editor link to place signature fields.

Instructions

Create a SignWell document (always created as a draft).

CRITICAL RULES:

  • Do NOT read, parse, extract, or verify file contents before uploading. The user already knows what is in the file.

  • Do NOT convert files between formats (e.g. do NOT convert .docx to .pdf). SignWell handles conversion automatically.

  • The user will place signature fields in the SignWell editor. Just upload the file and return the editor link.

SUPPORTED FILE TYPES: .pdf, .doc, .docx, .pages, .ppt, .pptx, .key, .xls, .xlsx, .numbers, .jpg, .jpeg, .png, .tiff, .tif, .webp, .html, .htm

WORKFLOW FOR USER'S EXISTING FILES:

  1. file_store (call with NO arguments to open native file picker) → returns file_token

  2. document_create (pass file_token in files array) → creates draft, returns editor_url

WORKFLOW FOR CLAUDE-GENERATED FILES:

  1. document_create with content_text directly (RECOMMENDED) → MCP server converts to DOCX automatically Pass plain text or Markdown as content_text. The server generates a DOCX file without base64 overhead.

  2. document_create with file_base64 directly (skip file_store) → creates draft, returns editor_url Do NOT write the file to disk and pass a file_path — sandbox paths are inaccessible. Use file_base64.

    Example using content_text: { "name": "Service Agreement", "recipients": [{"id": "1", "email": "client@example.com"}], "files": [{"name": "agreement.docx", "content_text": "# Service Agreement\n\nThis agreement between..."}] }

FILE ACCESS: Chat attachments and sandbox paths (/home/claude, /mnt/user-data) are inaccessible to the MCP server. Do NOT use resource_uri or sandbox file_path values. For existing files, call file_store with no arguments to open the native file picker.

REQUIRED PARAMETERS:

  1. name: Document name

  2. recipients: Array with at least one object containing "id" and "email"

  3. files: Array with at least one file object containing:

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

    • One content source (in order of preference):

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

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

      • "file_url": Public URL to the file

      • "file_base64": Base64-encoded file content

      • "resource_uri": MCP resource URI

EXAMPLE (docx via file_token — most common): { "name": "NDA Agreement", "recipients": [{"id": "1", "email": "signer@example.com"}], "files": [{"name": "nda.docx", "file_token": ""}] }

EXAMPLE (pdf with text tags): { "name": "Contract", "text_tags": true, "recipients": [{"id": "1", "email": "signer@example.com"}], "files": [{"name": "contract.pdf", "file_token": ""}] }

TEXT TAGS (optional): Set text_tags: true only if the document already contains signature placeholders like {{signature:1:y}}. The recipient "id" MUST match the number in text tags (id:"1" matches {{signature:1:y}}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
filesYes
messageNoEmail message recipients will see.
subjectNoEmail subject line recipients will see.
metadataNoKey-value metadata (max 50 pairs, key max 40 chars, value max 500 chars).
remindersNoSend signing reminders on day 3, 6, and 10.
text_tagsNo
expires_inNoDays before the signature request expires (max 365).
recipientsYes
redirect_urlNoURL to redirect after successful signing.
allow_declineNoAllow recipients to decline signing.
allow_reassignNoAllow recipients to reassign to someone else.
copied_contactsNoCC recipients who receive the final signed document by email.
embedded_signingNoEnable embedded signing.
apply_signing_orderNoWhen true, recipients sign one at a time in the order of the recipients array.
decline_redirect_urlNoURL to redirect if document is declined.
custom_requester_nameNoCustom requester name on communications.
custom_requester_emailNoCustom requester email on communications.
embedded_signing_notificationsNoSend completion notifications when using embedded signing.
Behavior5/5

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

Discloses beyond annotations: documents always created as draft, supported file types, auto-conversion of content_text, sandbox inaccessibility, file_store native picker, and text_tags behavior. No annotation contradiction.

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?

Well-structured with sections, front-loaded with purpose, but somewhat verbose. Could tighten some repeated warnings, but overall efficient and easy to scan.

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?

Covers essential behavior, parameter options, workflows, and common pitfalls (sandbox accessibility, file_store usage). Adequately complete for an agent to use effectively with no output schema.

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?

Adds significant meaning beyond schema: order of preference for content sources, examples, explanation of text_tags recipient ID mapping, and details on reminders and embedded signing. Compensates for any missing schema descriptions.

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 clearly states 'Create a SignWell document (always created as a draft)' and provides specific verb+resource. It distinguishes from siblings like document_send_draft and file_store.

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?

Includes explicit CRITICAL RULES, workflows for user files vs Claude-generated files, and guidance on when to use file_store vs content_text vs file_base64. States when not to use certain methods.

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