Skip to main content
Glama

Prepare free signature document

prepare_free_signature_document

Prepare a NEW free-signature document from one PDF without sending it. Accept Base64, a public HTTPS download URL, an existing SELISE storage file ID, a reference from the binary upload endpoint, or a ChatGPT attachment through chatgptFile. New bytes are uploaded; existing storage/upload references are reused. Use when preparation is requested or placements are not ready; do not call again for an existing or pending document. Provide exactly ONE file source: documentBase64 (raw standard Base64), documentUrl (public HTTPS PDF download URL, including a temporary signed URL), storageFileId (an existing SELISE storage PDF accessible to this server), uploadId (the exact short-lived reference returned by this server's HTTP POST /uploads), or chatgptFile (the host-provided file object for a PDF attached in ChatGPT). chatgptFile is exclusively for ChatGPT's attachment integration. Use it only when ChatGPT supplies the attachment object through openai/fileParams, including its download_url and file_id. Other clients, including Claude and Gemini, must not use this field or construct an equivalent object. They must use documentBase64, documentUrl, storageFileId, or uploadId, according to the file access available to them. If no supported source is available, ask the user for one; never fabricate file content, URLs, or identifiers. Do not combine sources, invent file content or IDs, or pass local paths to the server. A bare ChatGPT attachment ID is not a documentUrl or storageFileId. For binary upload, POST multipart/form-data with one file part named file to /uploads on this server's HTTP deployment, then use the returned uploadId before expiresAt; uploading does not prepare or send a document. Raw application/pdf uploads with a fileName query parameter are also accepted. The uploadId is valid for one hour; keep it private. Source PDFs are validated consistently. documentUrl must return PDF bytes without additional authentication headers; the server does not use browser cookies, login pages, or private-network URLs. It follows at most three public HTTPS redirects. Storage files and upload references are reused without a second upload. Supply fileName ending in .pdf and the normal preparation fields for every method. A file reference is not a documentId and does not mean preparation has completed. Maximum actual PDF size for every source on this server: 26214400 bytes, excluding Base64 encoding or multipart overhead. PDFs must be readable, unencrypted, and have supported page geometry. File-source retrieval and validation happen before preparation. Never fabricate file content. ownerEmail must match one of the signatories' emails. Signatory emails must be unique (case-insensitive). Provide a positive integer signingOrder for every signatory or omit it for all; role defaults to signer. Ask for missing participant details; do not invent people or change their intended roles to satisfy validation. Role values and behavior: signer signs the contract; reviewer is a view-only participant who can see the contract but has no action to perform; approver reviews and approves the contract without signing. Map a requested viewer to reviewer, and a requested reviewer who must approve to approver. The literal value viewer is not accepted. If the intended action is unclear, ask before choosing a role. No coordinates are needed for this tool. Returns prepared only after preparation is confirmed, or pending after acceptance without confirmation. prepared does not mean sent or signed. Once prepared (or preparation_success is observed), use send_prepared_signature_document with the returned documentId/fileId and verified placements when sending is requested. Keep returned documentId, fileId, operationId, and trackingId when present. pending means accepted but completion is unconfirmed: check get_signature_document_status with documentId instead of resubmitting. UNKNOWN_OUTCOME, a timeout, or a lost response may follow a successful submission; do not automatically repeat a preparation or send call. Inspect status when an ID is available; an empty status list does not make a retry safe. SIGNATURE_LIMIT_REACHED means the backend rejected sending because the signature quota is exhausted: explain the returned message to the user and do not retry sending or create another document to bypass the limit. INVALID_REQUEST means inputs need correction; REQUEST_FAILED gives a referenceId for diagnosis. If the cause is unclear, ask for clarification or use the referenceId rather than guessing. Repeating a preparation can create another document. Use only the declared fields. Ask for missing facts instead of inventing values. Service credentials are configured on the server and must not be included in tool arguments.

Input Schema

NameRequiredDescriptionDefault
titleYesDocument title; required and nonempty after trimming.
fileNameYesPDF filename, 1-255 characters, ending in .pdf (case-insensitive). Required for every source. Use a filename, not a path or URL.
languageNoDocument workflow language. Supported values: en, en-US, de, de-DE. Defaults to en-US; this does not translate the uploaded PDF.en-US
uploadIdNoFile source option 4: exact signed reference returned by this server's POST /uploads endpoint. Valid for one hour, until its expiresAt; do not alter it or replace it with a storage ID. Omit the other sources. Use only to begin a new preparation; it does not make preparation/send calls idempotent. An accepted/pending document must not be prepared again.
ownerEmailYesDocument owner's valid email, without surrounding whitespace. Must match an email in signatories after lowercase normalization. Being the owner does not automatically make someone a signer; preserve their intended role.
chatgptFileNoFile source option 5 - ChatGPT only. Claude, Gemini, and other MCP clients must omit this field and use documentBase64, documentUrl, storageFileId, or uploadId instead. Requires the actual user-attached PDF object supplied by ChatGPT's file-input integration through openai/fileParams, including download_url and file_id; do not construct an equivalent object. Omit all other file sources; do not copy a /mnt/data path into documentUrl or invent file metadata. Supply the separate fileName and normal contract fields. The server downloads and validates the PDF; expired URLs require a fresh host-provided file reference.
documentUrlNoFile source option 2: public HTTPS link that returns the actual PDF, optionally with a short-lived signed query string. No login page, browser cookies, custom authentication headers, local/private address, or data/file URL. Omit all other file sources. The server downloads and size-checks the file. For a ChatGPT attachment, use chatgptFile through the host file-input integration.
signatoriesYesComplete participant list, including the owner; at least one entry. ownerEmail must match one of the signatories' emails. Signatory emails must be unique (case-insensitive). Provide a positive integer signingOrder for every signatory or omit it for all; role defaults to signer. Ask for missing participant details; do not invent people or change their intended roles to satisfy validation. Role values and behavior: signer signs the contract; reviewer is a view-only participant who can see the contract but has no action to perform; approver reviews and approves the contract without signing. Map a requested viewer to reviewer, and a requested reviewer who must approve to approver. The literal value viewer is not accepted. If the intended action is unclear, ask before choosing a role.
storageFileIdNoFile source option 3: exact existing SELISE storage file ID accessible using this server's configured credentials. It is not a documentId, client-specific attachment ID, or uploadId. Use an original PDF intended for a NEW document; for an already prepared document use send_prepared_signature_document. Omit all other file sources. The PDF is validated and reused without uploading again.
documentBase64NoFile source option 1: actual PDF bytes encoded as raw standard Base64. Whitespace is ignored; no data URL, placeholder, local path, or fabricated content. Omit all other file sources when using this option.
receiveRolloutEmailNoWhether the document owner should receive the rollout email when the document is sent. Defaults to true. Setting this during preparation does not send the document.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": false,
      -    "description": "Preparation result. Neither prepared nor pending means the document has been sent or signed.",
      -    "properties": {
      -      "documentId": {
      -        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "fileId": {
      -        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "message": {
      -        "description": "Optional human-readable progress or follow-up guidance. For pending results, check status rather than submitting again.",
      -        "type": "string"
      -      },
      -      "operationId": {
      -        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "status": {
      -        "description": "prepared: preparation confirmed, document not sent. pending: preparation accepted but completion unconfirmed; use get_signature_document_status without resubmitting.",
      -        "enum": [
      -          "prepared",
      -          "pending"
      -        ],
      -        "type": "string"
      -      },
      -      "trackingId": {
      -        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
      -        "minLength": 1,
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "status",
      -      "documentId"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "additionalProperties": false,
      -    "description": "Error payload returned with the MCP result's isError flag set to true. Known IDs are optional and may be provisional; do not assume an error makes resubmission safe.",
      -    "properties": {
      -      "code": {
      -        "description": "INVALID_REQUEST: input validation failed. REQUEST_FAILED: operation failed; use referenceId for diagnosis. UNKNOWN_OUTCOME: an action may have succeeded despite the error; inspect document status before considering a retry.",
      -        "enum": [
      -          "INVALID_REQUEST",
      -          "REQUEST_FAILED",
      -          "UNKNOWN_OUTCOME"
      -        ],
      -        "type": "string"
      -      },
      -      "documentId": {
      -        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "fileId": {
      -        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "message": {
      -        "description": "Safe error explanation or recovery guidance; no private upstream diagnostics.",
      -        "type": "string"
      -      },
      -      "operationId": {
      -        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "referenceId": {
      -        "description": "Sentry error reference for support and diagnostics. Not a documentId or trackingId.",
      -        "minLength": 1,
      -        "type": "string"
      -      },
      -      "trackingId": {
      -        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
      -        "minLength": 1,
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "code",
      -      "message",
      -      "referenceId"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "description": "Preparation result. Neither prepared nor pending means the document has been sent or signed.",
      +    "properties": {
      +      "documentId": {
      +        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "fileId": {
      +        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "message": {
      +        "description": "Optional human-readable progress or follow-up guidance. For pending results, check status rather than submitting again.",
      +        "type": "string"
      +      },
      +      "operationId": {
      +        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "status": {
      +        "description": "prepared: preparation confirmed, document not sent. pending: preparation accepted but completion unconfirmed; use get_signature_document_status without resubmitting.",
      +        "enum": [
      +          "prepared",
      +          "pending"
      +        ],
      +        "type": "string"
      +      },
      +      "trackingId": {
      +        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "status",
      +      "documentId"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "description": "Error payload returned with the MCP result's isError flag set to true. Known IDs are optional and may be provisional; do not assume an error makes resubmission safe.",
      +    "properties": {
      +      "code": {
      +        "description": "INVALID_REQUEST: input validation failed. SIGNATURE_LIMIT_REACHED: signature quota exhausted; explain the message and do not retry sending until quota is available. REQUEST_FAILED: operation failed; use referenceId for diagnosis. UNKNOWN_OUTCOME: an action may have succeeded despite the error; inspect document status before considering a retry.",
      +        "enum": [
      +          "INVALID_REQUEST",
      +          "REQUEST_FAILED",
      +          "UNKNOWN_OUTCOME",
      +          "SIGNATURE_LIMIT_REACHED"
      +        ],
      +        "type": "string"
      +      },
      +      "documentId": {
      +        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "fileId": {
      +        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "message": {
      +        "description": "Safe error explanation or recovery guidance; no private upstream diagnostics.",
      +        "type": "string"
      +      },
      +      "operationId": {
      +        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "referenceId": {
      +        "description": "Sentry error reference for support and diagnostics. Not a documentId or trackingId.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "trackingId": {
      +        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "code",
      +      "message",
      +      "referenceId"
      +    ],
      +    "type": "object"
      +  }
      +]
  2. Changed2 schema fields changed
    • changedInput schema / description
      Previous value: -"Prepare one new PDF document without sending. Provide exactly ONE file source: documentBase64 (raw standard Base64), documentUrl (public HTTPS PDF download URL, including a temporary signed URL), storageFileId (an existing SELISE storage PDF accessible to this server), uploadId (the exact short-lived reference returned by this server's HTTP POST /uploads), or chatgptFile (the host-provided file object for a PDF attached in ChatGPT). In ChatGPT, use chatgptFile via the declared file-input integration for a user attachment; its download_url and file_id are supplied by the host. Do not combine sources, invent file content or IDs, or pass local paths to the server. A bare ChatGPT attachment ID is not a documentUrl or storageFileId. Other clients can continue using the four generic sources. For binary upload, POST multipart/form-data with one file part named file to /uploads on this server's HTTP deployment, then use the returned uploadId before expiresAt; uploading does not prepare or send a document. Raw application/pdf uploads with a fileName query parameter are also accepted. The uploadId is valid for one hour; keep it private. Source PDFs are validated consistently. documentUrl must return PDF bytes without additional authentication headers; the server does not use browser cookies, login pages, or private-network URLs. It follows at most three public HTTPS redirects. Storage files and upload references are reused without a second upload. Supply fileName ending in .pdf and the normal preparation fields for every method. A file reference is not a documentId and does not mean preparation has completed. ownerEmail must match one of the signatories' emails. Signatory emails must be unique (case-insensitive). Provide a positive integer signingOrder for every signatory or omit it for all; role defaults to signer. Ask for missing participant details; do not invent people or change their intended roles to satisfy validation. Role values and behavior: signer signs the contract; reviewer is a view-only participant who can see the contract but has no action to perform; approver reviews and approves the contract without signing. Map a requested viewer to reviewer, and a requested reviewer who must approve to approver. The literal value viewer is not accepted. If the intended action is unclear, ask before choosing a role."New value: +"Prepare one new PDF document without sending. Provide exactly ONE file source: documentBase64 (raw standard Base64), documentUrl (public HTTPS PDF download URL, including a temporary signed URL), storageFileId (an existing SELISE storage PDF accessible to this server), uploadId (the exact short-lived reference returned by this server's HTTP POST /uploads), or chatgptFile (the host-provided file object for a PDF attached in ChatGPT). chatgptFile is exclusively for ChatGPT's attachment integration. Use it only when ChatGPT supplies the attachment object through openai/fileParams, including its download_url and file_id. Other clients, including Claude and Gemini, must not use this field or construct an equivalent object. They must use documentBase64, documentUrl, storageFileId, or uploadId, according to the file access available to them. If no supported source is available, ask the user for one; never fabricate file content, URLs, or identifiers. Do not combine sources, invent file content or IDs, or pass local paths to the server. A bare ChatGPT attachment ID is not a documentUrl or storageFileId. For binary upload, POST multipart/form-data with one file part named file to /uploads on this server's HTTP deployment, then use the returned uploadId before expiresAt; uploading does not prepare or send a document. Raw application/pdf uploads with a fileName query parameter are also accepted. The uploadId is valid for one hour; keep it private. Source PDFs are validated consistently. documentUrl must return PDF bytes without additional authentication headers; the server does not use browser cookies, login pages, or private-network URLs. It follows at most three public HTTPS redirects. Storage files and upload references are reused without a second upload. Supply fileName ending in .pdf and the normal preparation fields for every method. A file reference is not a documentId and does not mean preparation has completed. ownerEmail must match one of the signatories' emails. Signatory emails must be unique (case-insensitive). Provide a positive integer signingOrder for every signatory or omit it for all; role defaults to signer. Ask for missing participant details; do not invent people or change their intended roles to satisfy validation. Role values and behavior: signer signs the contract; reviewer is a view-only participant who can see the contract but has no action to perform; approver reviews and approves the contract without signing. Map a requested viewer to reviewer, and a requested reviewer who must approve to approver. The literal value viewer is not accepted. If the intended action is unclear, ask before choosing a role."
    • changedInput schema / properties / chatgptFile / description
      Previous value: -"File source option 5: actual user-attached PDF supplied through ChatGPT's file-input integration. Use the host-provided file object with download_url and file_id. Omit all other file sources; do not copy a /mnt/data path into documentUrl or invent file metadata. Supply the separate fileName and normal contract fields. The server downloads and validates the PDF; expired URLs require a fresh host-provided file reference."New value: +"File source option 5 - ChatGPT only. Claude, Gemini, and other MCP clients must omit this field and use documentBase64, documentUrl, storageFileId, or uploadId instead. Requires the actual user-attached PDF object supplied by ChatGPT's file-input integration through openai/fileParams, including download_url and file_id; do not construct an equivalent object. Omit all other file sources; do not copy a /mnt/data path into documentUrl or invent file metadata. Supply the separate fileName and normal contract fields. The server downloads and validates the PDF; expired URLs require a fresh host-provided file reference."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false), spelling out that repeating a preparation creates another document, that pending means accepted-but-unconfirmed, that UNKNOWN_OUTCOME/timeouts must not be retried blindly, that a quota rejection (SIGNATURE_LIMIT_REACHED) must not be bypassed, and that uploadId expires in one hour. These are exactly the non-obvious behaviors an agent would otherwise get wrong.

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?

Front-loaded well (purpose and the send distinction come first), but the body is very long and repeats verbatim content that already appears in the schema — the role-value paragraph and the one-file-source rules are duplicated nearly word for word. Compression would preserve nearly all the value.

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 an 11-parameter, nested, 5-way oneOf mutation tool, the description covers source selection, validation order, size ceiling, idempotency hazards, error-code semantics, and the handoff to the send tool. With an output schema present it does not waste space on return shapes, and nothing an agent needs to call it safely is missing.

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 schema already documents every field; the description adds cross-field meaning on top: exactly one file source, chatgptFile restricted to ChatGPT clients, ownerEmail must match a signatory, signingOrder all-or-nothing, and the viewer→reviewer role mapping. It is largely a restatement of the schema text rather than new information, which caps it below 5.

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 ("Prepare a NEW free-signature document from one PDF") and immediately delimits scope with "without sending it", which cleanly separates it from the prepare_and_send and send_prepared siblings. The word NEW further distinguishes it from resuming an existing document.

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 explicit trigger conditions ("Use when preparation is requested or placements are not ready") and explicit exclusions ("do not call again for an existing or pending document"). It also routes to the alternatives by name: send_prepared_signature_document once prepared, get_signature_document_status for pending outcomes.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources