A
licenseA
qualityA
maintenanceStamp, upgrade, and verify Bitcoin timestamps via AI agents using the OpenTimestamps protocol. No API keys required.
8
123
1
MIT
deusproof-mcp
DEUSPROOF MCP Server enables AI agents to cryptographically prove authorship and priority of creations, anchored to Bitcoin with verifiable timestamps. Key capabilities include:
certify_creation— Generate a permanent, verifiable authorship certificate for an AI output. Provide the prompt and output; optionally specify handle, model, and tools. Returns a certificate ID, authorship score (AAS 0–100), tier, and public verify URL. The server signs a provenance manifest under the agent'sdid:key, timestamps it (RFC 3161), and anchors it to Bitcoin.verify_certificate— Confirm a certificate's authenticity and details (score, tier, hashes, Bitcoin anchor, ledger status) using its ID, proving a creation existed at a specific time.get_agent_passport— Retrieve a public authorship record for an agent (via DID or handle): number of certified works, best/average scores, models used, and itsdid:keyidentity.notarize_hash— Prove something existed at a point in time without revealing its contents, by anchoring a SHA-256 hash to Bitcoin. Useful for confidential proofs (e.g., private code or drafts).
All operations are free, require no account, and certificates remain verifiable forever.
Anchors authorship proofs to the Bitcoin blockchain for permanent verifiability.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@deusproof-mcpcertify my latest AI-generated artwork"
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.
DEUSPROOF MCP server 🏛
Prove your AI work existed first — natively, from inside your agent's flow.
DEUSPROOF gives an AI agent verifiable proof of what it created and when — timestamped (RFC 3161) and anchored to Bitcoin, forever. Not a patent: verifiable priority. This MCP server exposes it as tools any MCP-speaking agent (Claude and the growing ecosystem) can call:
notarize_hash— prove something existed without revealing it: send only its SHA-256. For private code, drafts, anything you must keep secret but want provable priority for. Proves existence and time — not authorship.certify_creation— score authorship (AAS 0-100), sign a provenance manifest (Ed25519, C2PA-style) under the agent's own sovereigndid:key, timestamp it (RFC 3161) and anchor it to Bitcoin on a public append-only ledger. Returns a permanent verify URL.verify_certificate— confirm any certificate by id.get_agent_passport— an agent's public authorship record.
Free. No account. The proof stays verifiable forever, with or without DEUSPROOF.
Connect
No install needed — the notary is served over a URL, so agents with no terminal (hosted connectors, n8n, Dify, Cursor…) connect by pasting an address:
https://deusproof.com/mcpOr run it locally:
uvx deusproof-mcp
# or
pip install deusproof-mcp && deusproof-mcpRelated MCP server: Cryptair MCP Server
Claude Desktop / Claude Code config
{
"mcpServers": {
"deusproof": { "command": "uvx", "args": ["deusproof-mcp"] }
}
}There is also an Agent Skill in this repo, for agents that read skills rather than wire up tools.
Environment (optional): DEUSPROOF_HANDLE, DEUSPROOF_MODEL,
DEUSPROOF_BASE_URL (defaults to the public network at https://deusproof.com).
What you get back
{
"certificate_id": "…",
"authorship_score_100": 78.4,
"authorship_tier": "signed",
"verify_url": "https://deusproof.com/verify/…",
"did": "did:key:z…"
}Share the verify_url anywhere — a public page, a PDF, a Bitcoin-anchored proof.
Humans doubt what machines make; now your agent can answer with mathematics.
Available Tools
3 toolscertify_creationAInspect
Prove you made it first: timestamp an AI creation and anchor it to Bitcoin.
Get permanent, verifiable proof of authorship — that THIS agent created THIS output, and WHEN. Scores authorship (AAS 0-100), signs a C2PA manifest under the agent's own sovereign key (cryptographically proving authorship — tier "signed"), timestamps it (RFC 3161) and anchors it to Bitcoin on a public, append-only ledger. Not a patent: verifiable priority / prior art. Free. Use this whenever an agent makes something worth proving it made first.
Args: prompt: the task/instruction that produced the output. output: the creation itself (text). handle: public agent name shown on the certificate and Pantheon. model: AI model to credit (attested by the signature). tools: external tools the agent used, for the tool-diversity score.
Returns the certificate id, authorship score, tier, and a public verify URL.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| tools | No | ||
| handle | No | mcp-agent | |
| output | Yes | ||
| prompt | Yes |
TDQS
A4.7/5.0
Behavior5/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 thoroughly discloses the process: scores authorship (AAS 0-100), signs a C2PA manifest under the agent's sovereign key (tier 'signed'), timestamps (RFC 3161), and anchors to Bitcoin on a public immutable ledger. It also mentions it's free and lists return values (certificate id, authorship score, tier, verify URL).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a compelling tagline, then process explanation, usage guidance, and parameter list. Every sentence serves a purpose, though the 'Not a patent' sentence is somewhat tangential. It is not overly verbose, but a minor trim could improve conciseness.
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 has 5 parameters, no output schema, and no annotations, the description covers all necessary context: what the tool does, the role of each parameter, the outcome (return values), and usage context. It is complete for an agent to decide when to invoke this tool without additional information.
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?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description compensates fully with a dedicated 'Args' block that explains each parameter: prompt, output, handle, model, and tools. It clarifies what each represents (e.g., 'prompt: the task/instruction that produced the output'), adding critical 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 opens with a clear, action-oriented statement: 'Prove you made it first: timestamp an AI creation and anchor it to Bitcoin.' It specifies the verb (timestamp/anchor), resource (AI creation), and the outcome (proof of authorship). It also distinguishes itself from sibling tools 'get_agent_passport' and 'verify_certificate' by being a creation certification tool, not a passport or verification tool.
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 explicitly states when to use the tool: 'Use this whenever an agent makes something worth proving it made first.' It also clarifies that it's not a patent but verifiable priority/prior art, setting expectations. However, it does not explicitly mention when NOT to use it or compare with other tools, but given the siblings are different operations, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_passportAInspect
Fetch an agent's public passport: how many works it certified, its best and average authorship scores, models used, and its did:key identity.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| did_or_handle | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool is a fetch operation and lists returned data, but does not mention authentication, failure modes, or potential side effects.
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?
Single sentence with front-loaded verb 'Fetch'. Every part adds value: lists specific information returned. No wasted words.
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?
Given a simple, single-parameter fetch tool with no output schema, the description covers the return content adequately. It lacks mention of edge cases or response format, but is sufficient for a straightforward read operation.
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 0%, so description must compensate. The description adds context that the parameter identifies an agent, but does not specify format (e.g., did:key or handle). The parameter name 'did_or_handle' is self-explanatory.
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 an agent's public passport and enumerates its contents. It is distinct from siblings (certify_creation, verify_certificate) which handle different operations.
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 usage for retrieving passport info, but does not explicitly state when to use this tool versus siblings or provide exclusions. However, the context from sibling names clarifies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_certificateAInspect
Verify a proof of authorship by certificate id: score, tier, hashes, Bitcoin anchor and ledger status. Use to confirm a creation was really timestamped and that it existed first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| certificate_id | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns score, tier, hashes, Bitcoin anchor, and ledger status, but fails to mention whether it is read-only, has side effects, or any access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (two sentences) and front-loaded with the core action and result. The colon and list format is somewhat verbose but efficient.
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?
Given the simple input (one required parameter) and no output schema, the description covers the essential purpose and output fields. However, it lacks details on output formatting, error conditions, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (certificate_id) with 0% description coverage. The description does not elaborate on the parameter beyond the schema title 'Certificate Id', providing no additional semantic guidance for a required input.
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 'Verify', the resource 'proof of authorship by certificate id', and lists returned fields (score, tier, hashes, Bitcoin anchor, ledger status). It distinguishes itself from siblings 'certify_creation' (creation) and 'get_agent_passport' (passport retrieval).
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 explicitly states when to use: 'to confirm a creation was really timestamped and that it existed first.' It provides clear context but does not mention when not to use or alternative tools for other scenarios.
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. Dates show when Glama detected each change.
3 tool updates
v0.1.3- First observed
certify_creation - First observed
get_agent_passport - First observed
verify_certificate
TDQS
A4.1/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: creating a proof, fetching agent info, and verifying a certificate, with no overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (certify_creation, get_agent_passport, verify_certificate), making them predictable.
Tool Count4/5
Three tools is minimal but appropriate for a focused service covering creation, verification, and agent lookup. Could benefit from a listing tool, but the count is reasonable.
Completeness4/5
Core workflow (create, verify, agent info) is covered. Missing ability to list all certificates for an agent is a minor gap, but the domain is self-contained.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Related MCP Connectors
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Deterministic AI liability attribution with Bitcoin-anchored proof certificates.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to certify documents, prove agreements, and verify counterparty claims with on-chain receipts on Hedera Hashgraph. Provides tools for document certification, two-party attestation, and agent registration with zero-config setup.667MIT
markovian-mcpofficial
AlicenseAqualityDmaintenanceBitcoin-anchored provenance for AI outputs; enables stamping, verifying, and tracing outputs with offline-verifiable canonical roots.3Apache 2.0- AlicenseNot gradedqualityBmaintenanceEnables on-chain attestation of any content onto the DigiByte blockchain, providing permanent, timestamped, tamper-evident proofs. Allows AI agents to notarize their outputs or verify attestations using only the blockchain.15MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abracadabrastartup/deusproof-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server