Which integrations are available for this server?

Enables document fingerprint anchoring to the Bitcoin blockchain via OpenTimestamps, providing permanent, independent verification of file authenticity.

How do I use @unfakable/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@unfakable/mcp verify my signed contract.pdf" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@unfakable/mcp

by unfakable

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

@unfakable/mcp

Document verification MCP server for AI agents.

@unfakable/mcp is a Model Context Protocol server that gives AI agents (Claude Code, Claude Desktop, Cursor, ChatGPT, Gemini CLI, any MCP host) a primitive answer to one question: is this file the record it claims to be?

It does that by computing a SHA-256 fingerprint of the file locally — the file never leaves the device — and checking whether the fingerprint is anchored to a Bitcoin block via OpenTimestamps on the Unfakable verifier index. If the file has been locked, you get back the anchor block, the locked-at timestamp, the counterparty notification status, and a permanent verifier URL.

Zero file storage. Independent verification. Built for the era where AI agents read, summarize, sign, route, and trigger workflows from documents that increasingly cannot be trusted on their face.

Five tools

Tool	What it does
`verify_file(path)`	Hash a local file with SHA-256 and check whether Unfakable has a Bitcoin-anchored proof for that fingerprint. The file never uploads.
`verify_url(url)`	Fetch a public URL, compute its fingerprint, and check the index. Useful for verifying remote PDFs, wire instructions sent over email links, etc.
`verify_hash(hash)`	Direct lookup of a known SHA-256. Use when you already have the hash from another system.
`lock_file(path, ...)`	Create a new Bitcoin-anchored lock for a local file. Requires `UNFAKABLE_API_KEY`. Free key at https://unfakable.ai/lock.
`get_evidence_pack(handle)`	Retrieve Evidence Pack metadata (19-file manifest, FRE 902(14) cert info, chain-of-custody) for an existing lock.

Related MCP server: mcp-witness

Install

Claude Code

claude mcp add unfakable

Or manually, in your Claude Code MCP config:

{
  "mcpServers": {
    "unfakable": {
      "command": "npx",
      "args": ["-y", "@unfakable/mcp"],
      "env": {
        "UNFAKABLE_API_KEY": "YOUR_KEY_HERE"
      }
    }
  }
}

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "unfakable": {
      "command": "npx",
      "args": ["-y", "@unfakable/mcp"],
      "env": {
        "UNFAKABLE_API_KEY": "YOUR_KEY_HERE"
      }
    }
  }
}

Restart Claude Desktop. The five tools appear in the MCP servers list.

Cursor

In Cursor → Settings → MCP, add:

{
  "mcpServers": {
    "unfakable": {
      "command": "npx",
      "args": ["-y", "@unfakable/mcp"],
      "env": { "UNFAKABLE_API_KEY": "YOUR_KEY_HERE" }
    }
  }
}

Gemini CLI

Add to ~/.gemini/extensions.json:

{
  "mcpServers": {
    "unfakable": {
      "command": "npx",
      "args": ["-y", "@unfakable/mcp"],
      "env": { "UNFAKABLE_API_KEY": "YOUR_KEY_HERE" }
    }
  }
}

Standalone

npm install -g @unfakable/mcp
unfakable-mcp

Speaks JSON-RPC over stdio. Pipe it into any MCP-compatible host.

Authentication

verify_file, verify_url, verify_hash, get_evidence_pack — no key required. All four are read-only against the public verifier index.
lock_file — requires UNFAKABLE_API_KEY. Free key at https://unfakable.ai/lock. The key authorizes lock creation against your Unfakable account, applies your dispute window settings, and emails counterparty notifications under your domain.

Why this exists

For thirty years, document proof has lived inside the vendor that holds the file — the inbox provider, the signature platform, the document portal. Breach the vendor, subpoena the vendor, retire the product, and the proof goes with it.

AI agents now read, summarize, sign, and act on documents at scale. Before an agent acts, it needs to verify the file is the record it claims to be. That primitive does not exist inside any vendor today.

@unfakable/mcp is that primitive. It lets any agent — Claude, Gemini, ChatGPT, Cursor — call a single tool and get back: locked, locked when, anchored to which Bitcoin block, verifier URL, counterparty status. The proof survives if Unfakable disappears because the anchor lives on a chain Unfakable does not control.

License

MIT — see LICENSE.

Available Tools

5 tools

get_evidence_packA

Retrieve Evidence Pack metadata for an existing lock. Returns the 19-file manifest, FRE 902(14) certification info, Bitcoin anchor details, and chain-of-custody log. Does not download the pack itself — that requires a $29 purchase via the web interface.

ParametersJSON Schema

Name	Required	Description	Default
`handle`	Yes	The Unfakable verifier handle (e.g. '9f3e-a1b2-c4d7') or full verifier URL (e.g. 'https://unfakable.ai/v/9f3e-a1b2-c4d7').

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully covers behavioral traits: it is a read-only retrieval (no download), lists exactly what metadata is returned (manifest, certification, anchor, chain-of-custody), and does not mention destructive actions. No contradictions.

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?

Two sentences: first clearly states purpose and return content, second states a critical limitation. No redundant or unnecessary words. Each sentence earns its place.

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 no output schema, the description adequately explains return values (list of items). Context of 'existing lock' and 'does not download' is clear. Covers all essential aspects for a simple metadata retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with description for 'handle', but the tool description adds substantial context: explains that the handle identifies an 'existing lock', provides example formats, and clarifies that the tool returns metadata for that lock. Adds meaning beyond schema syntax.

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?

Description uses specific verb 'Retrieve' and resource 'Evidence Pack metadata for an existing lock'. Clearly distinguishes from siblings (lock_file, verify_*) by focusing on metadata retrieval. Also states what it does not do (download pack), eliminating ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (retrieve metadata for a lock) and when not to use ('Does not download the pack itself — that requires a $29 purchase via the web interface'). Provides clear context with no need for alternative tool naming.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lock_fileA

Create a new Bitcoin-anchored lock for a local file. Computes SHA-256 locally (file never uploads), submits the fingerprint with context binding to Unfakable, and returns the permanent verifier handle. Requires UNFAKABLE_API_KEY environment variable (free key: https://unfakable.ai/lock).

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute or relative path to the file to lock.
`context_category`	Yes	Category that frames what this document is. Required for context binding so the proof cannot be repurposed for a different dispute.
`context_intent`	Yes	One-line description of why this lock exists (e.g. 'Wire instructions for Hendricks closing, sent Mar 14'). Becomes part of the immutable record.
`counterparty_emails`	No	Optional list of counterparty email addresses to notify. They receive a verifier link plus a 6-digit Security PIN.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that SHA-256 is computed locally ('file never uploads'), addresses privacy, and states the return value ('permanent verifier handle'). It does not mention rate limits or error handling (e.g., missing file), but covers core behavioral traits adequately.

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?

Three sentences with no filler. Each sentence adds critical information: what the tool does, how it works (local hash, never uploads), and prerequisites (API key with link). Perfectly front-loaded and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 4 parameters, no output schema. Description covers the process, privacy, and prereqs. While it could describe the verifier handle format or error cases, the given description is sufficient given the tool's straightforward nature and absence of output schema requirements.

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?

Schema description coverage is 100%, but description adds nuance: explains that context_category and context_intent serve 'context binding so the proof cannot be repurposed' and become part of the immutable record. This extra semantic value goes beyond the schema descriptions.

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?

Description clearly states 'Create a new Bitcoin-anchored lock for a local file' and outlines the process (local SHA-256, submission, return of verifier handle). Importantly, it distinguishes this creation tool from sibling verification tools (get_evidence_pack, verify_file, verify_hash, verify_url) by focusing on anchoring a new lock.

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?

Description explicitly notes the required UNFAKABLE_API_KEY environment variable and provides a link to obtain a free key. It implies when to use (to anchor a file's hash) but does not specify when not to use or mention alternative approaches, though sibling context makes this clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_fileA

Hash a local file with SHA-256 and check whether Unfakable has a Bitcoin-anchored proof for that fingerprint. The file is never uploaded — only its hash travels.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute or relative path to the file on the local filesystem.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description covers the key behavior (file never uploaded, only hash travels), but lacks details on return value (boolean? error?), file size limits, or handling of missing files. Without annotations, this is a moderate disclosure.

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?

Two sentences, 25 words, no waste. The essential action is front-loaded, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 1-parameter tool with no output schema, the description covers core behavior and privacy, but lacks return value explanation and failure modes, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds no additional meaning beyond what is already in the schema's parameter description. Baseline of 3 is appropriate.

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 (hash and verify) and the resource (local file against Bitcoin-anchored proof). It distinguishes from siblings like 'verify_hash' (which takes a hash) and 'verify_url' (which takes a URL).

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 implies use when you have a local file and want to verify its integrity via blockchain proof. However, it doesn't explicitly mention when to prefer this over 'verify_hash' or 'verify_url', nor any prerequisites like file existence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_hashA

Look up a known SHA-256 fingerprint directly against Unfakable's anchor index. Use this when you already have the hash (e.g. from another system) and want to know whether it has been locked, when, and what Bitcoin block it is anchored to.

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes	64-character hex SHA-256 fingerprint.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes what the tool returns (locked, when, Bitcoin block) and implies a read-only lookup. No contradictions with missing 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?

Two sentences, no wasted words, front-loaded with action and purpose.

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?

Despite no output schema, description fully explains what the tool returns and when to use it. Adequate for a simple lookup 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?

Schema has 100% coverage. Description adds domain context ('Unfakable's anchor index') and clarifies usage context, providing value beyond the schema's description.

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?

Clearly states it looks up a SHA-256 fingerprint against an index. Distinguishes from siblings by specifying it's for when you already have the hash, not for computing from files or URLs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when you already have the hash', providing clear context and implying not for file/URL verification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_urlA

Fetch a public document URL, compute its SHA-256 fingerprint, and check whether Unfakable has a Bitcoin-anchored proof. Use this when the file is hosted online (e.g. a verifier handle, a public PDF link).

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Public HTTPS URL of the document to verify.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description outlines the three main actions but lacks details on error handling, permissions, or rate limits. Since annotations are absent, this is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and contains no redundant information. It maximizes clarity with minimal words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool but does not explain the output or return values. Without an output schema, this omission reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the schema already defines 'url' as a public HTTPS URL. The description adds usage context but does not significantly enhance parameter meaning beyond the schema.

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 tool fetches a URL, computes SHA-256, and checks for a Bitcoin-anchored proof. It distinguishes from siblings like verify_file and verify_hash by focusing on online documents.

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 advises use when the file is hosted online, providing context with examples (e.g., verifier handle, public PDF). It does not explicitly exclude offline use but implies the tool's purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0May 14, 2026
- First observedget_evidence_pack
- First observedlock_file
- First observedverify_file
- First observedverify_hash
- First observedverify_url

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-05-14 20:10 across 5 tools

Disambiguation5/5

Each tool has a distinct and clear purpose: locking a file, verifying by file/hash/URL, and retrieving evidence pack metadata. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., lock_file, verify_hash), making the set predictable and easy to understand.

Tool Count5/5

With 5 tools, the server is well-scoped for its domain of Bitcoin-anchored file verification. Each tool covers a core operation without unnecessary bloat.

Completeness4/5

The tool set covers creating locks and verifying them via file, hash, and URL, plus metadata retrieval. A minor gap is the lack of a 'list locks' or similar, but the core workflows are fully supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
Touchstone
cv.touchstone
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Blockchain Security Autonomous Agents
2

Related MCP Servers

Agent Identity MCP Server
Security Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
MCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.
Updated 6 months ago (2026-04-03 16:05 UTC)
MIT
mcp-witness
Security Legal & Compliance
edwiniac
A
license
Not graded
quality
D
maintenance
Cryptographic proof of every AI decision. An immutable, verifiable audit trail MCP server.
Updated 3 months ago (2026-07-03 02:24 UTC)
1
MIT
trust-mcp
Blockchain Web3 & Decentralized Tech
Schmoll86
A
license
A
quality
D
maintenance
MCP server for AI agent trust verification, enabling agents to verify identities, check trust scores, and build reputation across multiple blockchain and web platforms.
Updated 7 months ago (2026-02-24 14:44 UTC)
12
10 npm
1
MIT
OpenTimeStamps MCP Server
Blockchain Cryptocurrency
getAlby
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that enables AI models to timestamp files and verify proofs on the Bitcoin blockchain using OpenTimeStamps.
Updated a year ago (2025-10-04 10:33 UTC)
7
5 npm
MIT

Appeared in Searches

OpenTimestamps - Bitcoin-based timestamping protocol

@unfakable/mcp

Five tools

Install

Claude Code

Claude Desktop

Cursor

Gemini CLI

Standalone

Authentication

Why this exists

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches