Free e-signature for humans and AI agents - zero-document PDF signing from hashes only.
Scored across 5 tools
Each tool has a clearly distinct purpose: creation of an envelope, retrieval of OTS proof, retrieval of full receipt, verification of audit chain integrity, and lookup by document hash. No overlap.
All tool names follow a consistent 'verb_object' pattern with underscores (e.g., create_signing_envelope, get_ots_proof, verify_audit_chain). Verbs are clear and objects specific.
With 5 tools, the server is well-scoped for its domain—envelope creation, evidence retrieval, and verification. No unnecessary tools and sufficient coverage for core operations.
The tool surface covers creation, evidence retrieval, and verification of audit chains and document hashes. A minor gap is the absence of a direct signature verification tool, but this is partially addressed by get_receipt providing signature data.
Create a FreeSign envelope from a PDF SHA-256 hash. Do not send PDF bytes. The created envelope is NOT yet session-bound — the browser that opens the returned signing_url generates an ECDSA P-256 keypair locally and POSTs the public JWK to /api/envelopes/{id}/session-bind before any protected request will succeed. AI agents calling this tool just hand the signing_url to a human, who continues in a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| document_sha256 | Yes | SHA-256 of the original PDF bytes, computed locally by the user or agent. |
| Name | Required | Description |
|---|---|---|
| expires_at | Yes | |
| envelope_id | Yes | |
| signing_url | Yes | |
| session_binding_required | No | True when the envelope still needs the browser to call /api/envelopes/{id}/session-bind. Always true for MCP-created envelopes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that the envelope is not session-bound, the browser generates an ECDSA P-256 keypair, and that the human continues in a browser. This fully discloses the behavioral traits.
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 purpose, concise instructions, and no unnecessary details. Every sentence adds value.
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 one parameter, schema covering it, and an output schema present, the description covers the entire workflow and safety considerations, making it 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 100% and the parameter is well-described in schema. The description adds value by specifying that the hash is used to reference the PDF and instructs not to send PDF bytes, which is beyond 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?
The description clearly states the tool creates a FreeSign envelope from a PDF SHA-256 hash, distinguishing it from sibling tools that are for verification/audit purposes.
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?
Provides explicit guidance: 'Do not send PDF bytes' and explains the session-binding flow, including that the AI agent hands the signing_url to a human. While it doesn't mention alternatives, the siblings are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the .ots proof (base64) for a given OpenTimestamps anchor on an envelope. Use the official ots-cli to verify offline against Bitcoin block headers. Each seal has two anchors: kind: "byterange" commits to the signed document, kind: "signed_attrs" commits to SHA-256 of the CMS SignedAttributes (which carry the post-quantum key commitment).
| Name | Required | Description | Default |
|---|---|---|---|
| anchor_id | Yes | ||
| envelope_id | Yes |
| Name | Required | Description |
|---|---|---|
| kind | No | |
| status | Yes | |
| anchor_id | Yes | |
| envelope_id | Yes | |
| proof_base64 | Yes | Complete .ots file bytes, base64. |
| anchored_hash | Yes | |
| calendar_urls | No | |
| btc_block_hash | No | |
| btc_block_height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the two anchor types and their meanings, adding transparency about the returned data. It does not cover error handling or permissions, but the read-only nature is clear.
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 sentences, front-loaded with the core function, followed by a practical usage note and background. No wasted words.
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 retrieval tool with an output schema, the description adequately covers return format, usage hint, and anchor semantics. It could mention prerequisites (e.g., having envelope and anchor IDs from other tools) but is largely 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%, so the description must compensate. It mentions 'anchor on an envelope' but does not describe the parameters in detail. The parameter names are self-explanatory, and the description adds context about anchor kinds, but more explicit guidance on how to obtain these IDs would improve clarity.
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 clearly states the tool returns the .ots proof (base64) for a given anchor on an envelope, with specific verb and resource. It distinguishes from siblings like get_receipt and verify_audit_chain by focusing on proof retrieval.
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 description advises using ots-cli for offline verification, giving context but no explicit when-not or alternatives. The usage is implied: retrieve the proof then verify externally.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the envelope record (including final_pdf_sha256, final_signature_base64url, final_payload_json), per-signer signing receipts, and OpenTimestamps anchor metadata. Evidence only, never PDF bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope_id | Yes |
| Name | Required | Description |
|---|---|---|
| envelope | Yes | |
| receipts | Yes | |
| ots_anchors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that tool returns evidence only (no PDF bytes) and lists specific return fields. Does not mention permissions, idempotency, or side effects, but for a read-only tool with no destructive hint needed, this is acceptable.
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 sentences with no redundancy. Front-loaded with core output and key constraint (evidence only). Every sentence provides value.
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?
Given one parameter, simple schema, and presence of output schema (implied), the description adequately covers the tool's purpose and output. Could mention that it's a read-only operation or idempotent, but not essential.
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 has 0% description coverage and only one parameter (envelope_id). Description does not explain what envelope_id is, how to obtain it, or its format. Fails to add meaning beyond the schema's 'string' type.
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?
Clearly states it returns envelope record with specific fields (final_pdf_sha256, etc.), per-signer receipts, and OTS metadata. Distinguishes itself from siblings like get_ots_proof and verify tools by specifying 'evidence only, never PDF bytes'.
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?
Description implies use for retrieving evidence data but does not explicitly state when to use this tool vs alternatives like get_ots_proof or verify_document_hash. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return an envelope's append-only audit-event hash chain together with a server-computed integrity verdict: every event_hash is recomputed from its canonical material, and the prev_event_hash linkage and per-envelope seq contiguity are checked. Evidence only, never PDF bytes. The raw events are included verbatim so the caller can independently re-derive the verdict instead of trusting chain.valid.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope_id | Yes |
| Name | Required | Description |
|---|---|---|
| chain | Yes | |
| events | Yes | |
| envelope_id | Yes | |
| attested_audit_chain_head_hash | Yes | The audit-chain head derived from the signer-signed v2 final payload (G-01), fed into the verdict's head cross-check. NULL until the envelope is finalized. |
| attested_head_signature_verified | Yes | True when the final-payload signature carrying the attested head was re-verified against the signer's on-file public key. False when not finalized or the signature did not verify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it returns evidence only (no PDF bytes), recomputes hash chains, checks linkage and contiguity, and includes raw events for independent verification. The server-computed verdict is mentioned, and trust implications are hinted. Could add side effects or authentication needs.
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?
The description is relatively concise with two sentences, but the second sentence is long and packs multiple details. It is front-loaded with the main purpose. Slight improvement could be made by breaking into bullet points or shorter sentences, but overall efficient.
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?
Given the presence of an output schema and the tool's complexity, the description covers the key aspects: what is returned (hash chain, verdict, raw events), the verification process, and the read-only nature. Missing details about error conditions or performance impact, but sufficient for typical use.
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%, but the description does not explain the 'envelope_id' parameter beyond what the schema provides (e.g., pattern). It does not mention where to obtain the ID or format requirements beyond the regex. The parameter is simple but the description adds no semantic value.
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 clearly identifies the tool as returning an envelope's audit-event hash chain with a server-computed integrity verdict. It uses specific verbs ('Return') and resources ('append-only audit-event hash chain'), and distinguishes from siblings by focusing on audit chain verification, which is unique among the listed siblings.
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 description implies usage for verifying audit chain integrity but does not explicitly state when to use this tool versus alternatives like 'verify_document_hash' or 'get_ots_proof'. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find FreeSign receipts matching a local document SHA-256 hash.
| Name | Required | Description | Default |
|---|---|---|---|
| document_sha256 | Yes |
| Name | Required | Description |
|---|---|---|
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully shoulders behavioral disclosure. It fails to indicate read-only nature, idempotency, or behavior on no match (e.g., empty result vs. error).
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?
Extremely concise single sentence with no superfluous words, but brevity sacrifices detail needed for completeness.
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?
Despite low complexity (1 param, output schema exists), the description omits output structure or behavior, leaving the agent without sufficient context for correct invocation.
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 description only broadly mentions the parameter ('local document SHA-256 hash') without adding constraints, format, or usage context beyond the schema's pattern.
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 uses a specific verb ('Find') and resource ('FreeSign receipts') with a clear input ('local document SHA-256 hash'), distinct from sibling tools which handle creation or retrieval of proofs and receipts.
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?
No guidance on when to use this tool vs. siblings (e.g., get_receipt, verify_audit_chain) or prerequisites; the description only states its basic function.
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.
get_ots_proof1 field changedOutput schema / properties / kindAdded value: +{
+ "enum": [
+ "byterange",
+ "signed_attrs"
+ ],
+ "type": "string"
+}create_signing_envelopeget_ots_proofget_receiptverify_audit_chainverify_document_hash
Add one secure layer between your agents and this server.