FreeSign — Free e-signature
Server Details
Free e-signature for humans and AI agents — zero-document PDF signing from hashes only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.8/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: creating an envelope, retrieving OTS proof, retrieving receipt, verifying audit chain, and verifying document hash. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (create_, get_, verify_). The verbs are descriptive and the naming is uniform across the set.
With 5 tools, the set is well-scoped for the server's purpose of e-signature envelope creation and verification. Each tool serves a necessary function without redundancy or bloat.
The tool set covers envelope creation and comprehensive verification (OTS proof, receipt, audit chain, document hash). However, it lacks direct signing or revocation capabilities, though the signing is intentionally browser-based. Minor gap for a fully self-contained e-signature solution.
Available Tools
5 toolscreate_signing_envelopeCreate signing envelopeAInspect
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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fully explains the asynchronous session-binding process, local keypair generation, and the agent's role. It also warns against sending PDF bytes. This is comprehensive and far exceeds typical descriptions.
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, each adding unique value: first states the main action, second warns about input format, third explains the workflow. No wasted words, information is front-loaded. Excellent conciseness.
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 tool complexity (asynchronous signing flow), one parameter, and presence of an output schema, the description covers all essential aspects: input requirement, output (signing_url), state after creation, next steps for human, and agent's role. It is complete for an AI agent to correctly invoke and hand off.
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's own description already explains it. The description adds context about not sending bytes, which reinforces the parameter semantics, but does not provide additional syntactic or format details. Baseline 3 is appropriate.
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. It explicitly distinguishes from sibling tools (all verification-oriented) by the core action and the human-in-the-loop workflow. The verb 'create' and resource 'FreeSign envelope' are specific and 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?
The description provides clear context: it instructs the agent to hand the signing_url to a human and warns not to send PDF bytes. It does not explicitly list alternative tools but the sibling names (all verification tools) imply this is the only envelope creation tool. Could be improved by stating when to use alternatives, but overall guidance is strong.
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 proofAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| anchor_id | Yes | ||
| envelope_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or rate limits. It only states what is returned without additional context.
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 two sentences long, front-loads the main action, and contains no redundant 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?
While an output schema exists (reducing the need to explain return format), the description lacks an overview of what anchor_id and envelope_id represent, which is necessary for correct usage.
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% (no parameter descriptions), and the description does not explain anchor_id or envelope_id, leaving their meaning and source unclear.
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?
Description clearly states the tool returns a .ots proof in base64 for a specific anchor on an envelope, which uniquely distinguishes it from sibling tools like create_signing_envelope or get_receipt.
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 the ots-cli for offline verification, which gives context on how to use the result. However, it does not explicitly compare with siblings or provide 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.
get_receiptGet receiptBInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| envelope | Yes | |
| receipts | Yes | |
| ots_anchors | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it returns evidence data and excludes PDFs. Lacks details on permissions, side effects, or read-only nature. Adequate but not comprehensive.
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 key return fields. The phrase 'Evidence only, never PDF bytes' adds clarity without bloat. Slightly redundant but 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?
Tool is simple with one parameter and an output schema. However, the low schema coverage (0%) means the description should fully explain the parameter and return context beyond listing fields. It fails to clarify envelope_id or how to interpret the output.
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% for the single parameter envelope_id. The tool description does not clarify its format, source, or constraints, leaving the agent with only the schema's minimal type definition.
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, per-signer receipts, and OTS metadata. Explicitly excludes PDF bytes, distinguishing it from file retrieval tools. Sibling tools like get_ots_proof focus on specific aspects, making this unique.
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?
Implied usage for evidence/receipt data. Mentions 'never PDF bytes' as a negative cue, but no explicit when-to-use or when-not-to-use guidance, nor direct comparisons to siblings like verify_audit_chain.
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 chainAInspect
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 |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool recomputes event hashes, checks linkage and seq contiguity, includes raw events verbatim, and never returns PDF bytes. It does not mention authentication, rate limits, or error handling, but the provided details are sufficient for the tool's scope.
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 a 3-sentence paragraph without wasted words. It is concise and efficient, though a list or clearer segmentation could improve readability slightly.
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 existence of an output schema, the description does not need to detail return values. It covers purpose, behavioral aspects, and independent verification. However, it omits prerequisites (e.g., envelope must exist) and error cases, which is a minor gap 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?
The description does not add extra meaning to the envelope_id parameter beyond the schema's regex pattern. Since schema coverage is 0%, the description could elaborate on how to obtain the envelope_id or what it represents, but the single parameter is straightforward.
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 an envelope's audit-event hash chain with a server-computed integrity verdict. It specifies that it provides evidence only, not PDF bytes, which distinguishes it from sibling tools like get_receipt or verify_document_hash. The verb 'return' and resource 'envelope's append-only audit-event hash chain' are specific.
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 indicates the tool is for verifying audit trail integrity and suggests independent verification as an option ('so the caller can independently re-derive the verdict'). It contrasts evidence-only output with PDF retrieval, but does not explicitly list when to use this tool versus alternatives like verify_document_hash or get_ots_proof.
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 hashBInspect
Find FreeSign receipts matching a local document SHA-256 hash.
| Name | Required | Description | Default |
|---|---|---|---|
| document_sha256 | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| matches | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool finds matching receipts but does not disclose behavior such as what happens on no match, whether it returns receipt IDs or full receipts, or any side effects. The description is insufficient for safe invocation.
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 a single sentence of 11 words, front-loaded with the core action. No filler or extraneous information; every word earns its place.
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 simplicity (one parameter, no nested objects, output schema exists), the description is adequate but leaves ambiguity about what 'matching' entails and how it relates to sibling tools like verify_audit_chain. More context on the verification process would improve completeness.
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 adds meaning by stating the parameter is a local document's SHA-256 hash used for matching. However, this is somewhat redundant with the schema's pattern and does not provide deeper semantics like format or constraints beyond the 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 'Find FreeSign receipts matching a local document SHA-256 hash' clearly states the tool's function: it takes a hash and finds matching receipts. The verb 'Find' and resource 'FreeSign receipts' are specific, and distinguishing from siblings like verify_audit_chain is evident.
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 (e.g., verify_audit_chain). There is no mention of prerequisites, context, or when not to use it. The description is minimal and leaves the agent to infer usage scenarios.
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.
Discussions
No comments yet. Be the first to start the discussion!