Free e-signature for humans and AI agents — zero-document PDF signing from hashes only.
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. Dates show when Glama detected each change.
get_ots_proof1 field changedOutput schema / properties / kindAdded value: +{
+ "enum": [
+ "byterange",
+ "signed_attrs"
+ ],
+ "type": "string"
+}create_signing_envelopeget_ots_proofget_receiptverify_audit_chainverify_document_hashClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
E-signature API for AI agents: send contracts, sign PDF documents, track and download signed files.
Send AI-created PDFs for signature, track signers, and return verifiable document evidence.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
E-signatures for contracts and NDAs. Draft with AI, review, and send for signature.
Add one secure layer between your agents and this server.
Each tool targets a distinct function: envelope creation, OTS proof retrieval, receipt retrieval, audit chain verification, and document hash lookup. No overlap in purposes.
All tool names follow a consistent verb_noun pattern (create_signing_envelope, get_ots_proof, etc.) with imperative verbs and clear noun phrases.
With 5 tools, the server is well-scoped for a free e-signature service focusing on creation and verification, covering the core workflow without unnecessary extras.
The tool set covers the primary use cases: creating envelopes and retrieving/verifying evidence. Minor gaps like envelope listing or status checks are absent, but not critical for the stated purpose.
