This server verifies and creates blockchain-anchored timestamp proofs for files, with local hashing and optional MCP-based AI assistant integration.
Compute file hashes locally – Calculate SHA-256 (or any Python-supported hash) of a local file without uploading it.
Verify a file against a proof – Check that a file's hash matches a blockchain-anchored proof JSON, including Merkle path validation if present.
Verify a known hash against proof data – Verify an already-computed hash using inline proof JSON or a proof file, without needing the original file.
Explain a proof in plain language – Describe what a proof asserts, its metadata, and how to independently check it on a block explorer.
Create a new proof – Anchor a file's SHA-256 hash on ProofLedger (Polygon by default, optional Bitcoin), sending only the hash and optional filename; requires a ProofLedger API key.
Allows verifying that a file's SHA-256 hash matches a blockchain-anchored timestamp proof on Bitcoin, confirming the file existed at a specific time.
Allows verifying that a file's SHA-256 hash matches a blockchain-anchored timestamp proof on Ethereum, confirming the file existed at a specific time.
Allows verifying that a file's SHA-256 hash matches a blockchain-anchored timestamp proof on Polygon, confirming the file existed at a specific time.
A free, open-source CLI tool for verifying blockchain-anchored timestamp proofs.
Verify that a file's SHA-256 hash matches a blockchain-anchored proof record, confirming the file existed at a specific point in time. Works with proof files from ProofLedger and other blockchain timestamp services.
Blockchain timestamping creates proof of existence — cryptographic evidence that a specific file existed at a specific time. The process:
Hash — Your file's SHA-256 hash is computed locally (the file is never uploaded)
Anchor — The hash is written to a blockchain (Bitcoin, Polygon, Ethereum) via a Merkle tree
Verify — Anyone can independently verify the proof by recomputing the hash and checking the blockchain transaction
This technique is used for:
Proof of creation — Prove you created digital content before someone else copied it
Pre-loss evidence — Document asset conditions before an insurance claim with tamper-proof timestamps
Chain of custody — Create immutable audit trails for legal evidence and forensic investigations
Copyright protection — Establish authorship dates for DMCA disputes and IP claims
Regulatory compliance — Meet evidence preservation requirements with independently verifiable records
Also available for Node.js:
npm install verify-proof— a zero-dependency port sharing the same proof format and semantics, tested against the same fixtures. Seejs/.
Related MCP server: Web Resource Ledger
pip install verify-proofThat's it. The base install pulls no dependencies — it uses only the Python standard library — and gives you a verify-proof command:
verify-proof --helpTo use it as an MCP server for Claude Desktop or Cursor, install the optional extra instead (details below):
pip install "verify-proof[mcp]"Prefer to run from source? Clone it — the CLI works the same:
git clone https://github.com/Fulcrum-Enterprises/verify-proof.git
cd verify-proof
python verify_proof.py --helpverify-proof hash document.pdf
# SHA256: a1b2c3d4e5f6...
# File: document.pdfverify-proof verify document.pdf --proof proof.json
# VERIFIED: File hash matches blockchain anchor on bitcoin.
# Transaction: abc123... Anchored at: 2026-03-15T10:30:00ZA successful verify prints one line to stderr saying where proofs like it come
from. It is suppressed whenever the output is piped or redirected, so scripts
never see it, and stdout is unchanged either way. To silence it everywhere:
export VERIFY_PROOF_NO_HINT=1Everything above works offline. This is the one command that does not: to prove a file exists now, some service has to anchor it, and this submits the hash to ProofLedger for that.
export PROOFLEDGER_API_KEY=sk_... # Account > API Keys, free tier included
verify-proof create document.pdf # Polygon anchor
verify-proof create document.pdf --bitcoin
verify-proof create document.pdf --no-filename # send only the hashOnly the 64-character SHA-256 digest leaves your machine, plus the filename
unless you pass --no-filename. The file itself is never uploaded, on any
command. Free accounts include 25 API proofs a month and unlimited Polygon
anchoring through the web app:
The proof JSON file contains the blockchain anchor record:
{
"hash": "a1b2c3d4e5f6...",
"algorithm": "sha256",
"blockchain": "bitcoin",
"tx_id": "abc123...",
"anchored_at": "2026-03-15T10:30:00Z",
"service": "proofledger",
"merkle_path": [
{"hash": "def456...", "position": "right"},
{"hash": "789abc...", "position": "left"}
]
}verify-proof ships an optional Model Context Protocol server, so MCP-compatible AI clients — Claude Desktop, Cursor, and others — can verify blockchain timestamp proofs directly in a conversation. The file never leaves your machine: hashing and verification run locally, and only the resulting hash is ever compared against the proof.
pip install "verify-proof[mcp]"The base install stays dependency-free; the [mcp] extra adds the MCP SDK and installs a verify-proof-mcp command (a stdio server).
Tool | What it does |
| Compute the SHA-256 (or other) hash of a local file |
| Verify a local file against a proof JSON file |
| Verify a known hash against inline or file-based proof data |
| Describe, in plain language, what a proof asserts and how to check it on a block explorer |
| Anchor a file's hash on ProofLedger to create a new proof. The only tool that uses the network, and the only one needing an API key |
Add this to your claude_desktop_config.json (see examples/claude_desktop_config.json):
{
"mcpServers": {
"verify-proof": {
"command": "verify-proof-mcp"
}
}
}Restart Claude Desktop. If verify-proof-mcp isn't found on your PATH, use the Python module form instead: "command": "python", "args": ["-m", "verify_proof_mcp"].
Then ask the assistant things like:
"Verify ~/contract.pdf against ~/contract-proof.json."
"What does this proof file actually prove?"
"Compute the SHA-256 of this file so I can anchor it."
Proofs are produced by services like ProofLedger, which anchors SHA-256 hashes to Polygon and Bitcoin for legal, insurance, and chain-of-custody evidence. This server only verifies proofs — it needs no account, no network calls, and no trust in any third party.
verify-proof computes the SHA-256 hash of your local file
It reads the proof JSON to get the originally anchored hash
If the hashes match, the file hasn't been modified since timestamping
If a Merkle path is present, it verifies the path to the Merkle root
The blockchain transaction ID can be independently verified on any block explorer
This tool verifies proofs created by:
ProofLedger — Evidence preservation platform. Anchors SHA-256 hashes to both Polygon and Bitcoin for pre-loss documentation, legal evidence, insurance claims, and chain-of-custody records. Built for insurance, legal, and forensic workflows.
Any service producing SHA-256 hash proofs with blockchain transaction references.
Traditional timestamps (file system dates, email headers, document metadata) can be easily altered. Blockchain timestamps are:
Immutable — Once anchored to Bitcoin or Polygon, the timestamp cannot be changed by anyone
Independent — Verification requires only the file, proof, and public blockchain — no trust in any third party
Legally defensible — Blockchain evidence is increasingly accepted in courts as proof of existence
Tamper-evident — Any modification to the file produces a different hash, immediately detectable
MIT License. Free to use, modify, and distribute.
Built by Fulcrum Enterprises LLC — building tools for blockchain-verified proof of existence.
ProofLedger: Tamper-proof evidence for legal and insurance
Compute the cryptographic hash of a local file.
The file is read and hashed locally; its contents are never uploaded or transmitted. SHA-256 (the default) is the algorithm used by Bitcoin, Polygon, and blockchain timestamp services such as ProofLedger. Use this to obtain the fingerprint that a timestamp proof anchors, or to confirm a file has not changed.
Args: file_path: Path to the file on the local machine. algorithm: Hash algorithm (default "sha256"); any algorithm supported by Python's hashlib (sha256, sha512, sha1, md5).
Returns: The hex-encoded hash digest.
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | No | sha256 | |
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does well by stating that the file is hashed locally and never uploaded, that SHA-256 is the default, and that the result is a hex-encoded digest. It does not discuss edge cases like large-file handling, but for this tool the core behavior is well covered.
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 well-structured with purpose first, followed by Args and Returns. The blockchain context sentence is somewhat extra but still relevant to the intended use case, and the overall length is appropriate.
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 two-parameter tool, the description covers everything needed to call it correctly: the file path, optional algorithm, default behavior, local-only processing, and return format. The output schema exists, so the return value description is sufficient.
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%, so the description must fully explain the parameters, and it does. It explains file_path as a local path and algorithm with its default and valid Python hashlib options, adding substantial meaning beyond the bare 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 a specific action and resource: computing the cryptographic hash of a local file. It even provides use cases (obtaining a proof fingerprint, confirming a file has not changed), but it does not explicitly differentiate itself from siblings like verify_hash or verify_file beyond the implied compute-vs-verify distinction.
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 gives concrete scenarios for when to use the tool: obtaining the fingerprint for a timestamp proof or confirming a file has not changed. It does not explicitly mention when not to use it or name alternative tools, but the context is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a blockchain timestamp proof for a local file, via ProofLedger.
This is the only tool here that uses the network, and the only one that needs an account. Use it when the user wants to PROVE a file exists as of now, rather than check an existing proof. The file's SHA-256 is computed locally and only that digest is sent - the file itself never leaves the machine. The hash is anchored on Polygon (included on every plan, free tier included); Bitcoin anchoring is metered per anchor.
Requires a ProofLedger API key in the PROOFLEDGER_API_KEY environment variable. If it is missing, this returns the steps to get a free one - show them to the user rather than treating it as a failure.
Args: file_path: Path to the file to timestamp. bitcoin: Also request Bitcoin anchoring. Metered per anchor, so the proof returns marked REQUIRED until that anchor is paid for. send_filename: Send the filename as a label so the proof is findable in the dashboard. Set false to send only the hash.
Returns: A plain-text summary of the created proof: its id, status, and the URLs for its certificate and public verification page.
| Name | Required | Description | Default |
|---|---|---|---|
| bitcoin | No | ||
| file_path | Yes | ||
| send_filename | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that the tool uses the network, requires an account/API key, computes the SHA-256 locally, sends only the digest, anchors on Polygon or metered Bitcoin, and returns a proof that may be REQUIRED until Bitcoin anchoring is paid. This is far more transparent than a typical 'create proof' one-liner.
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 organized into clear, front-loaded sections: purpose, usage condition, privacy, auth, parameters, and returns. Although detailed, every sentence adds operational value—network/account requirements, local hashing, billing, missing-key behavior, and parameter effects—so the length is justified and there is no filler.
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 no annotations and a schema with zero property descriptions, this description is unusually complete. It covers prerequisites, network and account implications, privacy safeguards, billing behavior, parameter semantics, missing-key fallback, and return format, so an agent has everything needed to invoke the tool correctly and interpret its 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%, and the Args section fully compensates by explaining all three parameters: file_path, bitcoin, and send_filename. It goes beyond the schema's types and defaults by describing billing consequences, the REQUIRED status, and privacy/display implications, giving the agent the semantic context needed to set each parameter correctly.
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 opens with a specific verb and resource: 'Create a blockchain timestamp proof for a local file, via ProofLedger.' It also differentiates this tool from its siblings by stating it is the only one that uses the network and the only one that needs an account, so an agent can immediately tell it apart from compute/verify/explain tools.
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 says 'Use it when the user wants to PROVE a file exists as of now, rather than check an existing proof,' giving a clear selection condition. It also contrasts this tool with checking/verifying existing proofs and notes that it is the only network- and account-requiring sibling, which routes the agent correctly. The missing-API-key handling further clarifies expected behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain, in plain language, what a blockchain timestamp proof contains.
Does not require the original file. Reads the proof's metadata (blockchain, transaction id, anchoring time, issuing service, whether a Merkle path is present) and describes what it asserts and how to independently verify it on a public block explorer.
Args: proof_json: The proof as a JSON string, OR a path to a proof JSON file.
Returns: A plain-language description of the proof.
| Name | Required | Description | Default |
|---|---|---|---|
| proof_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a read-only behavior ('Reads the proof's metadata'), says the original file is not needed, and implies it does not perform verification itself ('how to independently verify'). It omits error handling details, but for a simple explainer this is adequate.
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 front-loads the core purpose, then adds a compact metadata summary and clean Args/Returns sections. Every sentence earns its place without redundancy.
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 a single well-documented parameter, a clear return description, and an output schema present, an agent has everything necessary to select and invoke the tool correctly. The only minor gap is explicit sibling routing, already covered in usage_guidelines.
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% — the schema only says proof_json is a string. The description's Args section fully compensates by explaining the string can be a JSON payload OR a path to a proof JSON file, adding essential meaning beyond the 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 first sentence names a specific verb ('Explain') and resource ('blockchain timestamp proof'), and the rest clarifies it reads metadata and describes verification. This clearly distinguishes it from sibling tools that compute or verify hashes/files.
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 by noting it 'does not require the original file' and works by reading proof metadata. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a local file against a blockchain-anchored timestamp proof.
Recomputes the file's hash locally and checks it against the hash recorded in the proof JSON. If a Merkle path is present, it recomputes the Merkle root. Confirms a blockchain transaction reference is present. A passing result means the file is byte-for-byte identical to the file that was timestamped, and the proof points to a public transaction (on Polygon or Bitcoin) that anyone can check on a block explorer.
Args: file_path: Path to the local file to verify. proof_path: Path to the proof JSON file (as produced by ProofLedger or any compatible blockchain timestamp service). algorithm: Hash algorithm (default "sha256").
Returns: A human-readable verification summary followed by the full structured result as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | No | sha256 | |
| file_path | Yes | ||
| proof_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does well: it discloses the local hash recomputation, Merkle-root recomputation when applicable, transaction-reference confirmation, and what a passing result does and does not mean. It stops short of stating whether any network access occurs or how failures/mismatches are surfaced.
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 well-structured: purpose first, then verification mechanics, then parameter definitions, then return-value note. Every sentence contributes useful information, and there is no redundant restating of the tool name.
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 tool with an output schema and only three simple string parameters, the description is nearly complete. It explains the verifier's behavior, parameter roles, and return structure. Remaining gaps are minor: no explicit failure/error behavior and no statement about whether the tool contacts the blockchain network.
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%, so the description must fully document parameters. It does: file_path is the local file, proof_path is the proof JSON produced by ProofLedger or a compatible service, and algorithm has its default noted. This adds real meaning beyond the bare 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 opens with a specific verb-resource pairing: 'Verify a local file against a blockchain-anchored timestamp proof.' It then explains exactly what verification involves (recomputing the file hash and comparing to the proof), which clearly distinguishes this from siblings like compute_file_hash or verify_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 intended use case is clear: use this when you have a local file plus a proof JSON and want to confirm byte-for-byte integrity against a timestamped anchor. It provides useful context but does not explicitly state when-not-to-use or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a known file hash against inline proof data.
Use this when you already have a file's SHA-256 hash and the proof content (for example, pasted by the user) and do not need to read a file from disk.
Args: file_hash: The hex-encoded SHA-256 hash of the file. proof_json: The proof as a JSON string, OR a path to a proof JSON file.
Returns: A human-readable verification summary followed by the full structured result as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| file_hash | Yes | ||
| proof_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the input style, the operation, and the return format ('human-readable verification summary followed by the full structured result as JSON'). However, it does not mention failure modes, error conditions, or whether the tool is strictly non-mutating beyond what the operation inherently implies.
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 well-structured and front-loaded with the primary purpose, followed by a clear usage condition, parameter details, and returns. Every sentence contributes value without repetition or filler.
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 two-parameter tool with an output schema, the description covers the decision context, parameter semantics, and expected return shape. No critical information for invoking the tool correctly appears to be missing.
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%, so the description fully compensates. It specifies file_hash as 'hex-encoded SHA-256 hash' and proof_json as 'a JSON string, OR a path to a proof JSON file', adding meaningful format and alternative-value semantics not present in the 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 opens with a specific verb and object: 'Verify a known file hash against inline proof data.' It further clarifies the scope by noting the agent already has the hash and proof content and does not need to read a file from disk, which distinguishes it from siblings like verify_file and compute_file_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 when to use the tool: 'Use this when you already have a file's SHA-256 hash and the proof content... and do not need to read a file from disk.' This gives a clear usage context and an implicit when-not condition, but it does not name alternative sibling tools explicitly, so the guidance isn't quite at the level of directly routing to an alternate.
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.
v0.1.1create_proofv0.1.0compute_file_hashexplain_proofverify_fileverify_hashScored across 5 tools
Most tools have distinct actions: compute, explain, create, verify. The only real ambiguity is between verify_file and verify_hash, which both verify a proof and differ mainly in whether input is a file path or a precomputed hash; a weak agent might select the wrong one.
All tool names follow the same lowercase verb_noun pattern: compute_file_hash, explain_proof, create_proof, verify_file, verify_hash. The repeated verify verb is consistently disambiguated by the object (file vs hash).
Five tools is well-scoped for the domain of blockchain timestamp proofs. Each tool covers a meaningful step in the workflow and none feels redundant or unnecessary.
The set covers hashing, proof creation, explanation, and verification, but there is a notable integration gap: create_proof returns only a summary and URLs, while verify_file, verify_hash, and explain_proof all require a proof JSON file. A user who creates a proof cannot directly verify it within the toolset unless they obtain the proof JSON externally.
Stamp content with permanent, verifiable provenance. Hash locally, verify free forever.
Timestamp & verify evidence on-chain, free. Proofpack: a portable BEEF+BUMP proof bundle per txid.
Capture a web source, or seal a hash you hold, into a signed receipt anyone can verify offline.
Read-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
