Skip to main content
Glama
Nuraveda-Labs

@qed-proof/mcp

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
QED_API_KEYNoWorkspace API key. Required for everything but offline verification.
QED_API_URLNoBase URL of the QED Proof API. Defaults to https://api.qedproof.site.
QED_AGENT_IDNoDefault 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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):

  • 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:///, 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.

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 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 and the Merkle log inclusion proof. 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 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.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation5/5

Each tool maps to a clearly distinct operation: submit a claim, get a single verdict, retrieve a receipt, verify a receipt, list claims, and list connections. Though get_verdict and list_claims both expose verdict information, one is a targeted lookup and the other is a filtered list, so selection should be unambiguous.

Naming Consistency5/5

All tool names consistently follow a verb_noun snake_case pattern: get_*, list_*, submit_*, verify_*. There are no mixed casing styles, vague verbs, or unpredictable naming conventions.

Tool Count5/5

Six tools is well-scoped for the claim/receipt verification domain. Each tool covers a necessary step in the workflow without unnecessary duplication or bloat.

Completeness4/5

The full claim lifecycle is covered: submit, poll/check verdict, fetch receipt, verify receipt, and list claims/connections. The only notable limitation is that verify_receipt explicitly does not check the on-chain anchor, so full trust-level-2 verification is not available within this tool set, though this is documented as an intentional scope boundary.

Maintenance

ActivityMaintained
ResponsivenessNo issues