Skip to main content
Glama

SELISE Signature

by com.selisesignature
OverviewDiscussionsAdmin

Send prepared signature document

send_prepared_signature_document
Destructive

Add field placements to an EXISTING prepared free-signature document and send it to its participants. This tool does not upload, prepare, or itself sign a document. Use only when sending is requested and preparation is confirmed; for a pending preparation, check status first. Reuse the matching documentId and fileId from preparation. All coordinate arrays apply to that single PDF and must refer to its existing participants. The server downloads the current PDF to read page dimensions for conversion; it does not discover intended field locations or retrieve participants. Obtain the participants and intended placements before calling. This tool uses only the prepared document's fileId, not documentBase64, documentUrl, storageFileId, uploadId, or chatgptFile. Maximum downloaded PDF size: 26214400 bytes. To start a new document from any of the five file sources, use a preparation tool instead. 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. 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. Returns sent when rollout succeeds, or pending when accepted but unconfirmed. sent means dispatched for signing, not that all participants have signed; use the status tool for completed. Do not send again after sending_success or completed, or while a previous send is pending. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileIdYesExact fileId for the PDF in that prepared document, returned by preparation. Every supplied coordinate applies to this one file. Do not use a documentId, local path, or URL.
documentIdYesExact documentId returned by preparation for the existing document to send. Confirm preparation succeeded before calling. Do not invent an ID or substitute a fileId, operationId, or trackingId.
coordinateSystemYesRequired: page_percent. All positions and sizes use 0-100 percentages of the visible PDF page, from its top-left. This explicit marker prevents old pixel/backend coordinates from being misinterpreted. Do not relabel old values; calculate their page percentages first.
signatureCoordinatesYesRequired nonempty signature-placement list for this PDF. In the combined tool, every signer needs at least one entry and every entry must refer to a supplied participant. For send-only, use the prepared document's participants and placements.
textFieldCoordinatesNoOptional text placements for this PDF; omit or use [] when none are requested. Each entry requires propertyName and participant/page/position/size fields.
simpleImageCoordinatesNoOptional simple-image placements for this PDF; defaults to []. Each entry requires a verified type and participant/page/position/size fields.
stampPostInfoCoordinatesNoOptional post-signing information placements for this PDF; defaults to []. Each entry requires verified entityName/propertyName and participant/page/position/size fields.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true, and the description goes well beyond them: it warns that retrying after UNKNOWN_OUTCOME/timeout may duplicate a successful submission, defines sent vs pending vs completed semantics, lists rejection conditions (unreadable PDFs, 180-degree rotated pages, text on cropped pages), states the 26214400-byte download cap, and specifies preconditions (participants and placements must pre-exist). This is unusually rich disclosure for a mutation tool.

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 with the scope and the key exclusions, but the page-percentage paragraph appears verbatim in the schema root, again in the description, and a third time inside signatureCoordinates, and the same rejection/size text is duplicated. Substantial length is spent repeating structured fields rather than adding new information.

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?

An output schema exists, so return values need not be documented, yet the description still explains the sent/pending outcomes and which IDs to retain. Combined with error-code handling, retry safety, and preconditions, there is nothing material an agent needs to invoke this tool correctly that is left unstated.

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, but the description adds meaning the schema does not carry: which file sources are excluded (documentBase64, documentUrl, storageFileId, uploadId, chatgptFile), the requirement to reuse the preparation's documentId/fileId, and the role semantics (signer/reviewer/approver, with 'viewer' not accepted). It loses a point because the coordinate-unit explanation largely duplicates the schema text rather than adding to it, and the referenced role values do not appear as schema properties.

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 ('Add field placements to an EXISTING prepared free-signature document and send it to its participants') and immediately bounds scope by naming what it does not do (upload, prepare, sign). An agent can separate it from prepare_free_signature_document and prepare_and_send_free_signature_document without opening a 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?

Explicitly conditions use ('Use only when sending is requested and preparation is confirmed'), names the prerequisite alternative ('for a pending preparation, check status first'), and routes new-document work to a preparation tool. It also tells the agent not to repeat a send after success/completed/pending, which is exactly the when-not guidance an agent needs.

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

All SELISE Signature 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