prepare_and_send_free_signature_document

com.selisesignature/signature · Verify this server

Prepare a NEW free-signature document from one PDF, add placements, and send it in one workflow. 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. Uploads new bytes or reuses the existing storage file. Use only when sending is requested and all participant details and actual PDF placements are known. For an already prepared document, use send_prepared_signature_document instead. This tool does not itself sign the PDF. 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. 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. Set coordinateSystem to page_percent. ALL field types use the same page-relative percentages: (0,0) is the top-left of the visible page, x increases rightward, y increases downward; 100 is the full page width or height, not 1. pageNumber is zero-based (0 is the first page). x/width are percentages of page width; y/height are percentages of page height. Positions must be >= 0, sizes > 0, x + width <= 100 and y + height <= 100. Example: x=10,y=80,width=30,height=10 starts 10% from the left and 80% from the top, covering 30% of page width and 10% of its height. The server reads each PDF page and handles backend units and field-specific conversions. Do not supply pixels, PDF points, or backend coordinates, or guess a placement from an unrelated image. Use the actual visible page and the user's intended field location. Unrepresentable placements, unreadable PDFs, 180-degree rotated placement pages, and text fields on rotated/cropped pages are rejected before sending; provide a flattened PDF if requested by the error. Provide at least one signatureCoordinates entry; optional coordinate arrays default to empty. Every coordinate's signatoryEmail must identify a participant in this document. Every signatory with role signer (including the default role) must have at least one signatureCoordinates entry, and every signature coordinate email must appear in signatories. The reviewer (view-only) and approver (approval without signing) roles do not sign and are not subject to this MCP signer-coverage check; do not invent signature placements for them. Every coordinate array applies to the selected source PDF. If placements are missing, obtain them; use prepare_free_signature_document only when preparation alone is intended. Returns sent when rollout succeeds, or pending when accepted but unconfirmed. sent does not mean completed signing. A failed combined workflow may already have uploaded or prepared a document; inspect its status before choosing a follow-up action. 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. 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.