Free e-signature for humans and AI agents — zero-document PDF signing from hashes only.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 5 of 5 tools scored. Lowest: 2.9/5.
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.
create_signing_envelopeCreate signing envelopeAInspectCreate 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.
get_ots_proofGet OpenTimestamps proofAInspectReturn 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.
get_receiptGet receiptAInspectReturn 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.
verify_audit_chainVerify audit chainAInspectReturn 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.
verify_document_hashVerify document hashCInspectFind 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!