@qed-proof/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QED_API_KEY | No | Workspace API key. Required for everything but offline verification. | |
| QED_API_URL | No | Base URL of the QED Proof API. Defaults to https://api.qedproof.site. | |
| QED_AGENT_ID | No | Default agent_id for claims. Defaults to the MCP client's name. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| submit_claimA | 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):
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. |
| get_verdictA | 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. |
| get_receiptA | 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. |
| verify_receiptA | 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. |
| get_log_headA | 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. |
| list_claimsA | 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. |
| list_connectionsA | 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. |
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 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.