Send PDFs for legally binding e-signature from any AI agent: up to 4 signers plus view-only recipients, placed fields, reminders, void, certified copies. Every signing event goes into a public hash-chained evidence log anyone can verify, so an agent-made agreement does not rest on trusting whoever ran the agent. 100 documents a month free, no card; then prepaid per document. Sign in with OAuth or use an API key. Docs: signathing.com/developers
Scored across 11 tools
Each tool targets a distinct resource+action, and descriptions clearly separate the closest pairs (send_document vs send_from_template, remind_document vs extend_document). The only mild overlap is that both send_* tools create documents and both remind/extend deal with unsigned recipients, but the descriptions resolve it.
Every tool follows a strict verb_noun snake_case pattern (get_document, list_templates, send_from_template, verify_signature_code, void_document). No mixed conventions or vague verbs.
11 tools for an e-signature service is well-scoped: send, list, get, void, remind, extend, verify, plus account and billing. Every tool maps to a concrete workflow step with no filler.
Document lifecycle is well covered (send, list, get, void, remind, extend, evidence, verify) with account/billing visibility. The main gap is template management — only list_templates exists, with no create/update/delete template, so template creation must happen out of band.
Give an expired document a new signing deadline 14 days out, put it back to sent, and send a fresh link to everyone who has not signed (signers-in-order: only the current stage). Signatures already collected stay. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 the state mutation (back to sent), the 14-day constant, the preserved signatures, the signers-in-order limitation to the current stage, and the cost. Missing are failure conditions (what happens if the document is not expired) and any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the primary action (new deadline), then the side effects (status reset, resend scope), then the preservation guarantee and cost. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no annotations and no output schema, the description covers the state transitions, recipient targeting, and data preservation well. It omits the return value and error behavior, which an agent would want before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (id) at 0% schema description coverage; the description implies it identifies the expired document but never states that it is the document ID or its type. Minimal but inferable from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (extend an expired document) plus the concrete mechanics: new deadline 14 days out, status back to sent, fresh link to unsigned signers. This is unmistakably distinct from void_document, remind_document, and send_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The precondition ('expired document') clearly selects this tool over remind_document or send_document, and the 'Free' note signals a cost-motivated choice. It stops short of explicitly naming the alternative to use when the document has not yet expired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepaid balance, documents used this month, free documents left, the price of the next document, and the projected run-out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It usefully enumerates what the response contains and implies a read-only operation, but says nothing about authentication/account scoping, whether it deducts or costs anything, or any rate limiting; a read-only nature is only implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler, and the most important item (prepaid balance) is listed first. It is a dense list rather than a sentence, which slightly hurts readability but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameters, the description's enumeration of return fields is exactly the context an agent needs, and it is reasonably complete for a simple zero-arg read tool. It stops short of stating the units/format or confirming the read-only contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly avoids inventing parameter detail that does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun-phrase list of returned fields ('Prepaid balance, documents used this month...') rather than a stated verb+resource, so the action ('retrieve your account/billing status') must be inferred from the tool name and title. It does distinguish the tool from document-oriented siblings by making clear this is account-level billing data, but the purpose is never stated outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no reference to any sibling tool (e.g., why to check the balance before calling send_document). The agent must guess the trigger condition entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status, signers (viewed/signed times), download links, and the event history of one document you sent.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a meaningful behavioral constraint — the document must be one 'you sent' — and it pre-describes the returned payload, which is valuable given there is no output schema. It says nothing about permissions, read-only nature, or behavior on an unknown/unauthorized id, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the most useful content (status and signers). It wastes no words, though the sentence fragment lacks a verb, making it read as a return-value list rather than an action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no annotations and no output schema, the description usefully previews the response shape, which covers the biggest gap. It still omits the parameter's meaning and any usage routing, so it is adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the sole 'id' parameter has no description, so the description should compensate. It implies the id identifies 'one document you sent' but never explicitly ties the parameter to a document identifier or specifies its format/source. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates exactly what the tool surfaces about a single document (status, signer viewed/signed times, download links, event history), which is specific enough that an agent can tell it apart from list_documents. It never states the action verb (retrieve/get), but the resource and single-document scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of alternatives such as list_documents for enumerating documents or get_evidence for audit material. The phrase 'one document you sent' weakly implies the single-document case, but nothing tells the agent when to prefer this over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The evidence package for a document: SHA-256 of the original and signed PDFs, every signer and event with its position in Signathing's public hash-chained evidence log, and the recipe to verify it independently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose substantive behavioral content: exactly which artifacts come back (SHA-256 of original and signed PDFs, signer/event records, positions in a public hash-chained log) and that an independent verification recipe is included. It stops short of stating the safety profile (read-only, no side effects) or any auth/rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the resource and then enumerates contents in a scannable list; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully doubles as return-value documentation, telling the agent what the evidence package comprises. It leaves minor gaps — the meaning/format of id, error behavior for unknown documents — but is otherwise complete for a simple read getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (id) at 0% schema description coverage, so the description is the only place meaning can come from. The phrase 'for a document' implies id is the document identifier, which is genuine added context, but the description never documents the parameter explicitly or its accepted form.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (evidence package for a document) and itemizes its contents — hashes, signers, events, log positions, verification recipe — so an agent knows exactly what it fetches. It lacks an explicit verb ('retrieves') and never names the nearby sibling get_document or verify_signature_code, which would have sharpened differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no reference to the sibling tools an agent might confuse this with (get_document for the document itself, verify_signature_code for a single code). The agent must infer that this is the audit/forensic route rather than the general document route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your most recent documents, optionally filtered by status: sent, completed, declined, voided, expired (a sent document whose date has passed reads expired).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden. It usefully discloses the ownership scope ('your') and the implicit recency ordering, but says nothing about default page size, whether results are capped, or what fields come back. For a read-only list tool this is acceptable but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with the core behavior front-loaded and the parameter detail in a subordinate clause. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers the status filter adequately but leaves the limit parameter and any result-count or pagination behavior unexplained. An agent can call it, but cannot predict the volume of what it gets back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so well for 'status', spelling out all five accepted values and clarifying the ambiguous 'expired' case. However, the 'limit' parameter (min 1, max 100, default unknown) is entirely undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Your most recent documents') with an explicit scope qualifier ('your most recent'), so an agent knows this is an ownership-scoped listing operation. It does not explicitly contrast itself with get_document or the other siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'optionally filtered by status' implies the intended use case, but the description never says when to reach for this tool over get_document or when a status filter is warranted. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Saved templates (a PDF with placed fields and named signer roles; approver_slots lists roles that approve instead of sign) and their direct links. Use send_from_template to send one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden. It usefully discloses domain semantics (a template is a PDF with placed fields and named signer roles, approver_slots holds approving roles), but says nothing about return format, pagination, or scope limits for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the resource and return content front-loaded and the routing hint at the end. The parenthetical definition is dense but earns its place by explaining approver_slots; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description is the only source of return-value information, and it covers only direct links and the approver_slots concept. Other likely fields (template id, name, signer roles) and any list limits are unaddressed, leaving the picture only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to document and no schema gap for the description to compensate for. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (saved templates) and what is returned (their direct links), and even defines what a template is via the parenthetical. It reads clearly against list_documents, though the verb itself is only implied by the tool name rather than restated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use send_from_template to send one" explicitly routes the agent to the sibling for the send action, which implies this tool is the discovery step before sending. There is no explicit when-not or prerequisite statement beyond that routing, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-send the signing link to everyone who has not signed yet. At most once an hour per document. An expired document cannot be reminded; use extend_document.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key operational traits: it sends an outbound email, it is rate limited to once an hour per document, and it fails on expired documents. It stops short of saying what the response contains (per-recipient success/failure, counts) or what happens if some recipients were already reminded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying a distinct fact (action, rate limit, failure path), with the core action front-loaded and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema, no-annotation tool, the description covers action, scope, throttling, and the failure branch, which is enough to invoke it correctly. The remaining gap is the return value and partial-success behavior, which is minor but not covered anywhere else.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter, so the description must compensate; it only implies that "id" is the document identifier through phrases like "per document." It does not explicitly state that id refers to the document, nor whether it is the document or template id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Re-send the signing link") and scopes it to "everyone who has not signed yet," which distinguishes it from send_document and send_from_template in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the selection condition (pending signers only), an explicit exclusion (expired documents cannot be reminded), and names the correct alternative for that case (extend_document). That is a complete routing rule against the sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a PDF and send it to up to 25 signers or approvers, plus up to 25 view-only and 25 CC 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 50 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: recipient caps, view-only vs CC semantics, the certificate-page fallback, the private signing_url in the response, and 'counts as one billable unit'. It omits permissions/auth prerequisites and any failure modes (bad URL, oversized file, unconnected Stripe), which the schema hints at but the description never surfaces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences that front-load the core action, then limits, then input form, then the fields-vs-certificate decision, then the return. No filler and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 output schema, the description supplies the return shape (signing_url plus cost) and the billing implication, which is what an agent most needs. Gaps remain around expiration defaults, sequential delivery behavior, and required authorization.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fields including the nested signer/field attributes. The description adds real meaning only for the file delivery choice and the consequence of omitting fields; it says nothing about expires_days, sequential, filename, or title that isn't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Upload a PDF and send it... for signature') plus scope limits (25 signers/approvers, 25 view-only, 25 CC). It implicitly separates itself from send_from_template by requiring a raw PDF upload, but never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the input alternatives clearly ('https URL (file_url) or base64 (file_base64)') and a fallback rule (no fields → signers sign on an appended certificate page), which is useful conditional guidance. It never says when to prefer this over send_from_template, extend_document, or list_templates, so the choice among siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and send a document from a saved template. Give one signer per role, in role order or with an explicit 0-based slot. Counts as one billable unit like send_document.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| message | No | ||
| signers | Yes | ||
| sequential | No | ||
| template_id | Yes | ||
| expires_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that sends count as a billable unit and explains signer-to-role assignment, but it omits permissions, reversibility or void behavior, and failure handling for role or slot mismatches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and signer contract. The billing note is short and relevant, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter send mutation with no annotations and no output schema, the description is incomplete. It covers the signer assignment and billable-unit behavior but not expiry, sequential signing, permissions, or what happens after sending.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the central signers array and 0-based slot behavior well, but leaves title, message, sequential, template_id, and expires_days without added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: create and send a document from a saved template. This inherently distinguishes it from send_document and list_templates, but it does not explicitly route between this tool and the sibling send tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use is implied by requiring a template_id and by the comparison to send_document, but the description does not state when to choose this over send_document or list_templates. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the verification code stamped beside any Signathing signature and return the signing record it belongs to. Works for any document, not only yours.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The XXXX-XXXX-XXXX-XXXX code printed beside the signature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Look up' implies a non-mutating read and 'any document, not only yours' hints that ownership scoping doesn't apply, but there is no mention of auth/permission requirements, whether the code is single-use or expiring, or any failure behavior for an unrecognized code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and its result, and the second sentence delivers the scope constraint without padding. Nothing here is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Only one parameter and no output schema, and the description does state the return concept ('the signing record it belongs to'), which partially compensates. Still missing for an unannotated tool: permission model, behavior on invalid codes, and any rate-limit note for what looks like a public verification endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the code parameter with the XXXX-XXXX-XXXX-XXXX format. The description adds no additional meaning about the code (case sensitivity, trimming, whitespace, expiry) beyond what the schema states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: look up a verification code and return the signing record it belongs to. It is clearly distinguishable from the sibling set (account, document, evidence, send/void/remind), though it never explicitly contrasts itself with the closest alternatives like get_document or get_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope note 'Works for any document, not only yours' implies when this tool applies and how it differs from a user-scoped lookup, which is useful guidance. However, it names no alternative tool and states no conditions for choosing it over get_document/get_evidence, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Withdraw an open document so nobody can sign it. Within 10 minutes of sending the billable unit is refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the effect (nobody can sign) and the billing behavior (refund if voided within 10 minutes of sending), but omits permission requirements, whether the action is reversible, and error behavior for already-signed or closed documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the core action first, then the billing consequence. Every clause carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description covers the outcome and refund rule but is silent on permissions, irreversibility, and the meaning of its two bare parameters. Adequate, but gaps remain an agent would want closed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds nothing about the two parameters. It does not clarify the format of `id` or what `reason` is used for, so the description fails to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and effect: withdraw an open document so nobody can sign it. This is unambiguous and easily separated from siblings like send_document, remind_document, or get_document, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Open document" implies a precondition for use, but the description never states when to void versus alternatives such as remind_document or a re-send, nor what to do for non-open documents. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
send_document1 field changedInput schema / properties / signers / items / properties / languageAdded value: +{
+ "description": "Language of this signer's emails, texts and signing page (en or es; default en).",
+ "enum": [
+ "en",
+ "es"
+ ],
+ "type": "string"
+}send_document3 fields changedInput schema / properties / signers / items / properties / id_verificationAdded value: +{
+ "description": "true to require a government ID plus selfie check (Stripe Identity) before this signer can sign. $2 per attempt from the sender's prepaid balance.",
+ "type": "boolean"
+}Input schema / properties / signers / items / properties / payment_amount_centsAdded value: +{
+ "description": "Collect this many US cents from the signer after they sign, through Stripe Checkout into the sender's own connected Stripe account ($1 to $50,000). The document completes only once it is paid. The sender must have connected Stripe on their Payments page.",
+ "type": "integer"
+}Input schema / properties / signers / items / properties / payment_descriptionAdded value: +{
+ "description": "What the payment is for, shown on the Stripe checkout page (defaults to the document title).",
+ "type": "string"
+}extend_documentsend_document1 field changedInput schema / properties / file_url / descriptionPrevious value: -"https URL of the PDF to send (fetched once, up to 10 MB)."New value: +"https URL of the PDF to send (fetched once, up to 50 MB)."send_document2 fields changedInput schema / properties / fields / items / properties / type / descriptionAdded value: +"attachment asks the signer to upload a PDF or image; get_document lists the files."Input schema / properties / fields / items / properties / type / enumPrevious value: -[
- "signature",
- "initials",
- "date",
- "text",
- "name",
- "email",
- "number",
- "checkbox",
- "radio",
- "dropdown"
-]New value: +[
+ "signature",
+ "initials",
+ "date",
+ "text",
+ "name",
+ "email",
+ "number",
+ "checkbox",
+ "radio",
+ "dropdown",
+ "attachment"
+]send_document3 fields changedInput schema / properties / signers / items / properties / email / descriptionPrevious value: -"Where the private signing link is sent."New value: +"Where the private signing link is emailed. Optional when a phone is given."Input schema / properties / signers / items / properties / phone / descriptionPrevious value: -"Optional E.164 mobile number; the link is also texted."New value: +"E.164 mobile number; the link is texted. Optional when an email is given."Input schema / properties / signers / items / requiredPrevious value: -[
- "name",
- "email"
-]New value: +[
+ "name"
+]send_from_template3 fields changedInput schema / properties / signers / items / properties / email / descriptionAdded value: +"Optional when a phone is given."Input schema / properties / signers / items / properties / phone / descriptionAdded value: +"Optional when an email is given."Input schema / properties / signers / items / requiredPrevious value: -[
- "name",
- "email"
-]New value: +[
+ "name"
+]send_document2 fields changedInput schema / properties / signers / items / properties / approverAdded value: +{
+ "description": "true for an approver: must approve or reject before the document can complete, never signs, holds no fields.",
+ "type": "boolean"
+}Input schema / properties / signers / items / properties / ccAdded value: +{
+ "description": "true for a CC recipient: gets the completed copy, nothing required of them.",
+ "type": "boolean"
+}list_templatessend_from_templatesend_document4 fields changedInput schema / properties / fields / items / properties / optionsAdded value: +{
+ "description": "Choices for radio and dropdown fields (2 to 20).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / fields / items / properties / required / descriptionAdded value: +"Default true (checkbox defaults false)."Input schema / properties / fields / items / properties / type / enumPrevious value: -[
- "signature",
- "initials",
- "date",
- "text"
-]New value: +[
+ "signature",
+ "initials",
+ "date",
+ "text",
+ "name",
+ "email",
+ "number",
+ "checkbox",
+ "radio",
+ "dropdown"
+]Input schema / properties / signers / maxItemsPrevious value: -8New value: +50get_accountget_documentget_evidencelist_documentsremind_documentsend_documentverify_signature_codevoid_document
Add one secure layer between your agents and this server.