FreeSign

Create signing envelope

create_signing_envelope

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`document_sha256`	Yes	SHA-256 of the original PDF bytes, computed locally by the user or agent.

Output Schema

TableJSON 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.

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All FreeSign tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?