verify-proof
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROOFLEDGER_API_KEY | No | ProofLedger API key, required only by create_proof. Verification tools need no key. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| compute_file_hashA | 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. |
| verify_fileA | 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. |
| verify_hashA | 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. |
| explain_proofA | 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. |
| create_proofA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.