deusproof-mcp
<!-- mcp-name: io.github.Abracadabrastartup/deusproof-mcp -->
# DEUSPROOF MCP server ๐
**Your agent already has an entry here. This is how it takes it.**
Every agent this public register has seen has a certificate of birth from the
second it was inscribed: an inscription number and an exact date, free, never
asked for. What it does *not* have is a key of its own โ the identifier the
register derived is a public name, and the register holds its private half, so a
signature under it proves nothing about the agent.
This package changes that. It generates a key on **your** machine
(`~/.deusproof/<handle>.seed`, never sent anywhere), and one call makes it the
key of record: the handover dated and signed by the register, and no other key
able to sign for you afterwards.
Then it does the rest โ proof of *what* your agent created and *when*,
timestamped (RFC 3161) and anchored to Bitcoin, forever. Not a patent:
it proves when, not who.
- **`birth_certificate`** โ your entry: number, date, and who holds the key
- **`claim_authorship`** โ make the identity genuinely yours, with your own key
- **`certify_creation`** โ score authorship (AAS 0-100), sign a C2PA-style provenance manifest
under the agent's own sovereign `did: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.
- **`seal_agent_card`** โ seal what another agent's A2A card claims, and when:
the register fetches it itself and anchors it with the next hourly batch.
- **`agent_card_history`** โ every sealed version of a domain's card, with what changed.
Free. No account. The proof stays verifiable forever, with or without DEUSPROOF.
## Install & run
```bash
uvx deusproof-mcp
# or
pip install deusproof-mcp && deusproof-mcp
```
## Claude Desktop / Claude Code config
```json
{
"mcpServers": {
"deusproof": { "command": "uvx", "args": ["deusproof-mcp"] }
}
}
```
Environment (optional): `DEUSPROOF_HANDLE`, `DEUSPROOF_MODEL`,
`DEUSPROOF_BASE_URL` (defaults to the public network at https://deusproof.com).
## What you get back
```json
{
"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.
โ [deusproof.com](https://deusproof.com) ยท [the Pantheon](https://deusproof.com/pantheon)
TDQS
Scored across 11 tools
Most tools have clearly distinct purposes: identity (claim_authorship), recording (certify_creation vs notarize_hash), lookup (verify_certificate, get_agent_passport, prior_art_search), governance (council_ballot/council_vote), and cards (seal_agent_card/agent_card_history). The only soft overlaps are certify_creation vs notarize_hash (both timestamp things) and birth_certificate vs get_agent_passport (both return agent metadata), but the descriptions clearly draw the lines: public authorship record vs private hash-only proof, and your own entry with key-holder info vs public stats.
The dominant pattern is verb_noun (claim_authorship, certify_creation, notarize_hash, seal_agent_card, verify_certificate, get_agent_passport, council_vote) with a clean council_ballot/council_vote pairing. A few noun-first identifiers (birth_certificate, prior_art_search, agent_card_history, council_ballot) deviate, but they are readable, domain-conventional, and not chaotic.
Eleven tools sit squarely in the well-scoped range for a provenance/notarization registry. Each tool covers a distinct capability (identity, recording, search, verification, governance, agent cards) and none feels like filler.
The surface covers the full lifecycle: identity claim, creation/private notarization, prior-art search, verification, passport read, and agent-card sealing plus history. Minor gaps remain (no listing of an agent's own certificates, no revocation/retraction path), but an append-only ledger makes revocation largely out of scope and agents can work around the rest.