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: 3.1/5.
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_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?
With no annotations provided, the description fully discloses the tool's behavior: the envelope requires a session-bind step, local ECDSA keypair generation, and a public JWK POST. It also clarifies that the AI only creates the envelope and passes the URL to a human. This transparency compensates for the absence of annotations.
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 concise, consisting of four sentences with no fluff. It front-loads the primary purpose and immediately follows with critical usage constraints. Every sentence adds necessary information.
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 tool's simplicity (one parameter, no enums, output schema exists), the description covers all essential aspects: creation, input format, session-binding requirement, and human-in-the-loop flow. It is contextually complete for an AI agent to correctly invoke the tool.
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 input schema already provides full coverage with description and pattern for document_sha256. The description adds value by stating 'Do not send PDF bytes' and noting that the hash is computed locally, which clarifies usage beyond the schema's technical details.
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 verb 'create', the resource 'FreeSign envelope', and the input 'PDF SHA-256 hash'. It also explicitly instructs not to send PDF bytes, making the purpose unambiguous. The sibling tools are for verification and proof, so this tool's unique role is well-defined.
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 explains that the envelope is not session-bound and that AI agents should hand the signing_url to a human for browser-based completion. This provides clear usage guidance. However, it could explicitly state when not to use this tool (e.g., for direct signing without a human), though the sibling tools' purposes imply alternatives.
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?
No annotations are provided, so the description must compensate. It explains the output format (base64 .ots proof) and the meaning of the two anchor kinds, but lacks details on error handling, idempotency, or authentication 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?
Three sentences, front-loaded with purpose, no superfluous words. Every sentence adds value: purpose, verification recommendation, anchor context.
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?
Has output schema, so return values are partially covered. Description adds context about anchor types and verification, but does not cover error situations, dependencies, or workflow integration with siblings. Given 0% param coverage, it is moderately 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 description coverage is 0%. The description does not explain what `envelope_id` and `anchor_id` represent directly, only indirectly references anchors. It mentions two anchor kinds but does not map them to the parameter pattern or required format.
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, specifying the two anchor kinds. It distinguishes from sibling tools by focusing on retrieving proof data, not creating envelopes or verifying documents.
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` to verify offline, which is a usage hint, but does not explicitly state when to use this tool vs siblings or when not to use it. No exclusions or alternatives mentioned.
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, but the description transparently states the tool returns specific structured data and clarifies it is evidence-only. It does not disclose side effects (which are likely none as a read operation), so behavior is well communicated.
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 concise at two sentences, but the first sentence lists multiple fields which could be restructured for readability. It front-loads the purpose well.
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 simple tool with one parameter and an output schema, the description covers the overall purpose, return content, and constraints. It is complete for a get-type tool, but lacks parameter details.
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?
With 0% schema description coverage, the description does not describe the single parameter 'envelope_id'. The parameter name is self-explanatory, but the description should add meaning beyond the name, such as format constraints or how to obtain it.
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 it returns 'envelope record (including specific fields)', 'per-signer signing receipts', and 'OpenTimestamps anchor metadata', and explicitly says 'Evidence only, never PDF bytes'. This distinguishes it from sibling tools like verify_audit_chain or get_ots_proof.
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 evidence retrieval via 'Evidence only, never PDF bytes', but does not explicitly state when to use this tool versus alternatives like get_ots_proof. No mention of prerequisites or when not to use.
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 provided, the description fully discloses behavior: recomputing event_hash, checking prev_event_hash linkage and seq contiguity, and including raw events for independent verification. This gives the agent a complete understanding of the tool's internal logic.
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 only two sentences, front-loaded with the core function. Every sentence adds value without redundancy. The structure efficiently conveys purpose and unique characteristics.
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?
The tool has an output schema (not shown), so explaining return values is unnecessary. The description covers the verification checks and mentions raw event inclusion. It implicitly assumes the envelope exists, but this is reasonable for a verification tool.
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 only one parameter (envelope_id) and schema coverage is 0%, but the description does not elaborate on the parameter beyond the schema's pattern. The purpose is clear from context, but adding explanation about the envelope_id format or source would improve semantics.
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 audit-event hash chain and an integrity verdict for an envelope. It specifies the resource (envelope) and action (verify audit chain), distinguishing it from sibling tools like get_receipt or verify_document_hash.
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 explicitly states 'Evidence only, never PDF bytes,' guiding when to use this tool for integrity verification versus retrieving documents. However, it does not explicitly list when not to use it or name alternative tools.
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 hashBInspectFind 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 provided, so description carries full burden. It does not disclose whether the operation is read-only, what happens if no receipt is found, or error conditions. The output schema exists but is not referenced in description.
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?
Single sentence with no waste, but could include additional helpful context like typical use without being verbose. Efficient but slightly too terse.
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 tool is simple with one parameter and an output schema, the description is adequate but lacks context about expected behavior, such as response format or error handling. It meets minimum viability.
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 minimal meaning beyond the parameter name 'document_sha256' by mentioning 'local document SHA-256 hash'. It does not explain how to obtain the hash or any constraints.
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 verb 'Find' and the resource 'FreeSign receipts matching a local document SHA-256 hash'. It distinguishes from sibling tools like create_signing_envelope, get_ots_proof, get_receipt, and verify_audit_chain, which have different 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?
No guidance on when to use this tool versus alternatives, nor when not to use it. The description only implies usage for finding receipts by hash, lacking explicit context or exclusion criteria.
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!
