@qed-proof/mcp
You can submit claims for independent verification and inspect signed receipts through MCP tools.
Submit claims for actions on targets (e.g., GitHub, Slack, X) to get a claim_id and, when inline, a verdict and receipt_id.
Get a claim's state and verdict: verified, late, mismatch, failed, or unverifiable, with meaning and receipt_id.
Fetch full signed receipts, including shareable public links, verifier-read facts/fingerprints, Ed25519 signature, and log inclusion/anchor proof.
Verify receipts or change entries offline: schema, integer-only encoding, key validity, Ed25519 signature, claim digest, and Merkle inclusion; on-chain anchor is not checked and trust level is at most 1.
Get the public Merkle log's signed tree head (size, root, key id, issue time, signature) and latest on-chain anchor; no API key required.
List recent workspace claims with filters (agent_id, action, verdict, state) and pagination.
List read-only connected destinations and whether a verifier is live for each.
Note: no tools to connect/disconnect accounts or manage keys; those stay in the QED Proof console. Documented verified actions are github.commit.push, github.pr.open, github.checks.pass, x.post.publish, and slack.message.post.
Click on "Deploy 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., "@@qed-proof/mcp Check if my claim that I pushed commit abc123 to GitHub is verified."
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.
@qed-proof/mcp
QED Proof as an MCP server. An AI agent says it did something; QED Proof reads the destination itself — never the agent's own report — decides a verdict, and issues a signed receipt anyone can check.
This server lets any MCP client (Claude, Claude Code, Cursor, and others) submit claims, read verdicts, fetch receipts and verify them offline, with no code.
Tools
Tool | What it does |
| Records a claim (an action on a target) for QED Proof to verify. Returns a |
| A claim's state, verdict ( |
| The full signed receipt, with a shareable link. Receipts are public. |
| Checks a receipt offline: schema, integer-only encoding, key validity, Ed25519 signature, claim digest, and Merkle inclusion. It doesn't read the chain, so the anchor is reported as not checked and the achieved trust level is at most 1. |
| The public Merkle log's signed tree head (size, root, key id, issue time) and latest on-chain anchor, with whether the signature verifies against the published keys. Needs no API key. |
| Recent claims in your workspace, with filters. |
| Destinations your workspace has connected read-only, and whether a verifier is live for each. |
There are no tools to connect accounts, disconnect them or manage keys: those stay in the console.
Actions verified today are the ones with a published verifier profile in the QED Proof spec: github.commit.push,
github.pr.open, github.checks.pass, x.post.publish and slack.message.post. Any other action is accepted and
decided as unverifiable — QED Proof never guesses.
Related MCP server: vantic-mcp
Use it
You need a workspace API key from the console (Developers → API keys).
Local (stdio):
claude mcp add qed-proof --env QED_API_KEY=<your key> -- npx -y @qed-proof/mcpEnvironment: QED_API_KEY (required for everything but offline verification), QED_AGENT_ID (the default agent_id
for claims; otherwise the MCP client's name), QED_API_URL (defaults to https://api.qedproof.site, e.g. for a
self-hosted node).
Hosted (Streamable HTTP): https://mcp.qedproof.site/mcp with Authorization: Bearer <your key>.
claude mcp add --transport http qed-proof https://mcp.qedproof.site/mcp --header "Authorization: Bearer <your key>"The hosted server keeps no state and stores nothing. It forwards your key to the QED Proof API for each request, so the API's own workspace scoping and rate limits apply, and it logs only the method, tool name, status and latency.
Data
target and params of a claim are copied into its receipt, which is public and permanent. Receipts record
fingerprints and the facts a verifier read (a commit SHA, an HTTP status), never content.
Develop
npm install
npm test # includes every spec test vector
npm run buildApache-2.0. QED Proof has no token.
Available Tools
7 toolsget_log_headGet the public log's signed tree headARead-onlyIdempotent
Returns the signed tree head of QED Proof's public Merkle log: the log id, the number of entries (tree_size), the root hash, when it was issued, and the Ed25519 signature, plus the latest on-chain anchor (chain, transaction hash, tree size and block) when one has landed. The signature is checked against the issuer's published poaw-keys.json and the result says whether it verifies. Needs no API key and reads only public data. It checks the head's signature, not that the head extends an earlier one; a consistency proof does that.
Inputs: no named parameters.
get_receiptGet a signed receiptARead-onlyIdempotent
Returns the full signed receipt for a receipt_id: the claim, what the verifier read at the destination (facts and fingerprints, never content), the verdict, the Ed25519 signature, and the log inclusion and anchor proof. Receipts are public, and the response includes a shareable link.
Inputs: receipt_id (required).
get_verdictGet a claim's verdictARead-onlyIdempotent
Returns a claim's state ("queued" or "decided"), its verdict when decided, and the receipt_id. Verdicts: verified, late, mismatch, failed, unverifiable; the response includes what the verdict means. Only claims in the API key's own workspace are visible.
Inputs: claim_id (required).
list_claimsList recent claimsARead-onlyIdempotent
Lists claims in the API key's workspace, newest first, with each claim's state, verdict and receipt_id. Filters: agent_id, action, verdict, state (queued or decided). Paginate with the returned next_cursor.
Inputs: limit, state, action, cursor, +2 more.
list_connectionsList connected destinationsARead-onlyIdempotent
Lists the destinations the workspace has connected read-only (for example GitHub, Slack, X) and whether a verifier is live for each. Read-only: connecting or disconnecting happens in the QED Proof console, not here.
Inputs: no named parameters.
submit_claimSubmit a claim for verificationA
Records that an agent says it performed an action, so QED Proof can check the destination and issue a signed receipt. Returns a claim_id and, when the check finishes inline, the verdict and receipt_id; otherwise state is "queued" and get_verdict returns the outcome later.
Documented actions (verifier profiles published in the QED Proof spec):
github.checks.pass: Every check run on the claimed commit completed without failing. target: owner/repo; params: sha (string, 40 lowercase hex)
github.commit.push: The claimed commit exists on the remote and the claimed branch contains it. target: owner/repo; params: sha (string, 40 lowercase hex), branch (string)
github.pr.open: The claimed pull request exists, optionally against the claimed base branch and at the claimed head commit. target: owner/repo; params: number (integer ≥ 1), base? (string), head_sha? (string)
slack.message.post: A message with exactly the claimed timestamp exists in the claimed channel, and (optionally) its text matches a target: slack://<team_id>/<channel_id>, with a team ID T… and a public (C…) or private (G…) channel ID,; params: ts (string,
^[0-9]{10}\.[0-9]{6}$), text_sha256? (string, 64 lowercase hex)x.post.publish: The claimed post exists on X, was written by the account the target handle is connected as, and (optionally) its text target: @handle (1–15 of A–Z a–z 0–9 _, with the @); params: post_id (string of 1–20 digits), text_sha256? (string, 64 lowercase hex)
Any other action string is accepted and decided as "unverifiable" (reason unsupported_action). target and params are copied into the receipt, which is public and permanent; params are limited to 4 KB. Resubmitting with the same client_claim_id returns the existing claim instead of creating a new one.
Inputs: action (required), target (required), params, agent_id, +2 more.
verify_receiptVerify a receipt or change entry offlineARead-onlyIdempotent
Checks a receipt or a change entry independently of QED Proof's servers, as the reference checker in the QED Proof spec does: the JSON Schema, integer-only encoding, the signing key's validity window, the Ed25519 signature, the claim digest (receipts only; a change entry has no claim) and the Merkle log inclusion proof. A change entry is signed under its own domain and the report carries entry_kind "change" with a null verdict. If the body carries a policy, pass the pipeline document to check it (its digest, id and version); without it the policy check is reported as not_checked. It does not read the blockchain, so the on-chain anchor is reported as not checked and the achieved trust level is at most 1. Pass receipt_json (a receipt or a change entry) for a fully offline check, or receipt_id to fetch the receipt first. The public keys come from keys_json or, when omitted, from the issuer's published poaw-keys.json.
Inputs: pipeline, keys_json, receipt_id, receipt_json.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
get_receipt, get_verdict, and verify_receipt all touch receipts/verdicts and could initially be confused, but descriptions clearly separate them: get_verdict reads a claim's state/verdict, get_receipt returns the full signed artifact, and verify_receipt does an independent offline cryptographic check. The remaining tools (submit_claim, list_claims, list_connections, get_log_head) target distinct resources, so boundaries are mostly clear.
All names follow a consistent snake_case verb_noun pattern: get_receipt, get_verdict, get_log_head, verify_receipt, list_claims, list_connections, submit_claim. Verbs (get/list/verify/submit) map predictably to read, enumerate, validate, and write actions.
Seven tools is well-scoped for a claim-verification service covering submit, poll, retrieve, independently verify, list, and log-head inspection. Nothing feels padded or redundant, and each tool earns its place.
The claim lifecycle is well covered (submit, get_verdict, get_receipt, verify_receipt, list_claims) plus supporting list_connections and get_log_head. Minor gaps: no tool to fetch a Merkle log entry or a consistency proof (the log-head description notes a consistency proof is what extends a head, but none is exposed), and receipts themselves cannot be listed directly.
Maintenance
Related MCP Connectors
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
One-stop claim verification for AI agents: verdicts with confidence, evidence, signed receipts.
A paid remote MCP for ZeroID, built to return verdicts, receipts, usage logs, and audit-ready JSON.
Verify claims, resolve FIGI identity, extract claims, and sign x402 delivery receipts over MCP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables verification of AI agent identity, authority, and integrity at transaction time, returning signed verdicts for allow, step-up, review, or block.MIT

vantic-mcpofficial
AlicenseNot gradedqualityDmaintenanceEnables MCP hosts to verify agent spending mandates and receipts, providing stateless tools for authorization, chain verification, credential verification, and DID resolution.Apache 2.0- AlicenseNot gradedqualityBmaintenanceEnables AI agents to verify claims against evidence through MCP tools, returning approved, rejected, or needs_review verdicts with replayable receipts.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to create and verify tamper-evident cryptographic evidence, manage key-bound Agent Passports, and support verifiable handoffs, approvals, and audit trails through MCP, REST, and A2A.MIT