Signathing

Send a document for signature

send_document

Upload a PDF and send it to up to 25 signers and up to 25 view-only recipients. Give the file as an https URL (file_url) or base64 (file_base64). Optionally place signature/initials/date/text boxes with fields; without fields, signers sign on a certificate page appended to the PDF. Returns the document with each signer's private signing_url and what the send cost. Counts as one billable unit.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Document title shown to signers and on the certificate.
`fields`	No
`message`	No	A short note to the signers.
`signers`	Yes
`file_url`	No	https URL of the PDF to send (fetched once, up to 10 MB).
`filename`	No	Shown to signers, e.g. lease.pdf.
`sequential`	No	Deliver links one signer at a time, in order.
`file_base64`	No	The PDF bytes as base64, if you have the file in hand.
`expires_days`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 19, 2026

addedInput schema / properties / fields / items / properties / options

Added value: +{
+  "description": "Choices for radio and dropdown fields (2 to 20).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / fields / items / properties / required / description
```
Added value: +"Default true (checkbox defaults false)."
```

changedInput schema / properties / fields / items / properties / type / enum

Previous value: -[
-  "signature",
-  "initials",
-  "date",
-  "text"
-]New value: +[
+  "signature",
+  "initials",
+  "date",
+  "text",
+  "name",
+  "email",
+  "number",
+  "checkbox",
+  "radio",
+  "dropdown"
+]

changedInput schema / properties / signers / maxItems
```
Previous value: -8New value: +50
```

First observedOct 19, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses recipient limits, the certificate-page fallback when fields are omitted, the return payload (per-signer signing_url plus cost), and billing ('Counts as one billable unit'). It omits whether the send is irreversible, expiration behavior, and any permission requirements, keeping it short of a 5.

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

Conciseness5/5

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

Four dense sentences, each earning its place: send scope, file input, field-vs-certificate behavior, then return and billing. Front-loaded with the core action and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the essentials an agent needs: inputs, the fields/certificate trade-off, recipient limits, and return values. It leaves expiration and sequential delivery unexplained, but those are documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, so the schema already documents most parameters. The description adds the meaningful distinction between file_url and file_base64 ('if you have the file in hand') and reconciles the 25+25 cap with the schema's maxItems of 50, but says nothing about expires_days, sequential, message, or signerIndex.

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+resource+scope: upload a PDF and send it for signature, with explicit caps (25 signers, 25 view-only). This is unmistakably distinct from sibling tools like void_document, remind_document, and get_document, which operate on already-sent documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description explains the internal branch (with fields vs. certificate-page fallback) and the file-input alternatives, but never says when to choose this tool over remind_document or void_document, nor states prerequisites such as required auth. Adequate but with clear gaps.

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

All Signathing tools Inspect

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

Need Help?