What can you do with this server?

This MCP server lets an agent verify Dokimo evidence packages and recompute Merkle proofs for tamper-evident revenue records. * Recompute a Merkle root locally with recompute_merkle_root, using the dokimo-merkle-v1 scheme and no network call. * Verify one evidence-package record with verify_evidence_package, which asks Dokimo to recompute the proof and check its commitment against the on-chain anchor on Base. * Fetch Dokimo’s public agent card with dokimo_agent_card to discover what it can verify. * Support agent auditing workflows by checking proof integrity, rule-version binding, and v2 close summaries, while scoped to one record at a time.

Which integrations are available for this server?

Allows verification of revenue claims from autonomous commerce platforms, with support for x402 / AP2 / Stripe machine payments, by recomputing tamper-evident evidence packages and checking on-chain anchors.

How do I use dokimo-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dokimo-mcp Verify this evidence package and tell me if it's anchored on-chain." 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.

dokimo-mcp

by ypratap11

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

dokimo-mcp

Give an AI agent the ability to verify another agent's revenue claims.

An MCP server exposing Dokimo's evidence checks as tools any MCP client (Claude Desktop, IDE agents, custom agents) can call. It's the "agent that audits agents" — as tools.

Live, clickable version of what these tools do: https://dokimo.augaster.com/agent-audits-agents.html

This is a thin, self-contained client: it calls Dokimo's public endpoints and implements the public dokimo-merkle-v1 hashing scheme. It contains no proprietary code. MIT-licensed.

Tools

Tool	What it does	Network?
`recompute_merkle_root(leaf, proof_path)`	Local recompute — hash a leaf under `dokimo-merkle-v1` and replay the proof path to a root, in this process, with no network call. Compare it to a package's claimed `root` yourself. It does not check the on-chain anchor.	none
`verify_evidence_package(package)`	Dokimo's check of one record, via its public A2A endpoint: recompute and check the anchored commitment (root + rule version, plus the close summary for v2 closes) against the on-chain anchor on Base. Returns `verified: true` only if both hold. The verdict is Dokimo's answer and is not signed — to avoid relying on it, recompute locally and read the anchor yourself (e.g. /verify.html).	Dokimo A2A
`dokimo_agent_card()`	Fetch Dokimo's public A2A agent card — what it can verify.	Dokimo

Verification model: there is no path to verified: true without (1) the caller's (leaf, proof_path) recomputing to the claimed root, and (2) the commitment of (root, rule_version_commitment) — and, for a dokimo-anchor-v2 close, its summary — being anchored on-chain. Tamper one byte → recompute fails. Swap the rule version → the commitment changes → not anchored. A package without summary and binding is checked as legacy v1, which verifies only closes anchored before the v2 cutover.

Honest scope: for one record, checks that its proof reaches the root and that the commitment is anchored on-chain. It does not recompute the close's figures from all its records (that needs the full package, e.g. in /verify.html), and it says nothing about whether a business number is "good." Non-custodial; reads public on-chain state only.

Related MCP server: garl

Install & run

pip install dokimo-mcp
dokimo-mcp                 # runs over stdio
# or, from a clone:
pip install .
python -m dokimo_mcp

Add to an MCP client

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "dokimo": {
      "command": "dokimo-mcp"
    }
  }
}

If dokimo-mcp isn't on PATH, use the module form:

{
  "mcpServers": {
    "dokimo": {
      "command": "python",
      "args": ["-m", "dokimo_mcp"]
    }
  }
}

Then ask the agent: "Use Dokimo to verify this evidence package" (paste one), or "recompute this Merkle root and tell me if it matches."

Agent skill

skills/dokimo-verify/SKILL.md tells an agent when and how to use these tools: check the package shape, recompute locally first, ask before sending anything to Dokimo, and report the result for one record without overstating it. Drop the dokimo-verify folder into your agent's skills directory (e.g. ~/.claude/skills/ for Claude Code). It is also listed, free, on Agensi.

Try it

The live demo page embeds a real, anchored evidence package. Fetch it and verify:

import re, json, urllib.request
import dokimo_mcp as d
html = urllib.request.urlopen(urllib.request.Request(
    "https://dokimo.augaster.com/agent-audits-agents.html",
    headers={"User-Agent": d._UA})).read().decode()
pkg = json.loads(re.search(r"const PKG\s*=\s*(\{.*?\})\s*;", html, re.S).group(1))
print(d.verify_evidence_package(pkg)["verified"])   # True
# tamper one unit -> False
pkg["leaf"] = pkg["leaf"].replace("1001190933933115", "1001190933933116")
print(d.verify_evidence_package(pkg)["verified"])   # False

Hosted / HTTP mode

The default transport is stdio (local use). Set MCP_TRANSPORT=http to serve MCP Streamable HTTP at /mcp on $PORT (default 8081) with CORS — the shape hosted platforms like Smithery require. The included Dockerfile + smithery.yaml (runtime: container) are set up for exactly this, so Smithery can build and host it from this repo.

MCP_TRANSPORT=http PORT=8081 dokimo-mcp     # or: docker run -p 8081:8081 <image>

What is Dokimo?

Verifiable revenue infrastructure for autonomous commerce — audit-ready, independently reproducible books for AI-agent machine payments (x402 / AP2 / Stripe), with each figure tamper-evidently committed and anchored on-chain. https://dokimo.augaster.com

License

MIT — see LICENSE.

Available Tools

3 tools

dokimo_agent_cardA

Read-onlyIdempotent

Inspect

Fetch Dokimo's public A2A agent card — the discovery document describing what it can verify (skills, endpoints, supported A2A versions).

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by calling the card 'public' and specifying it is an A2A discovery document with particular contents, which goes beyond the structured annotations.

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?

A single, front-loaded sentence with no filler. Every element adds useful information: the action, the resource, the 'public' qualifier, and the card's contents.

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?

For a simple, zero-parameter read-only fetch, the description is complete. It explains what the returned artifact is and what information it contains, which compensates for the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing the description needs to document. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the fixed resource being fetched.

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 names a specific verb ('Fetch'), a specific resource ('Dokimo's public A2A agent card'), and explains what the card contains ('skills, endpoints, supported A2A versions'). This makes it easy to distinguish from the sibling tools, which clearly perform different operations like recomputing a merkle root or verifying an evidence package.

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 clearly implies when to use the tool: when you want the discovery document that describes Dokimo's verification capabilities. It does not explicitly compare against sibling tools or state exclusions, but the context is sufficiently clear for a zero-parameter fetch operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recompute_merkle_rootA

Read-onlyIdempotent

Inspect

Recompute a dokimo-merkle-v1 root locally — no network call, no anchor check.

Hash leaf in the leaf domain (H(0x00 ‖ leaf)) and replay proof_path — a list of [sibling_hash, side] where side is "L" or "R" — hashing internal nodes as H(0x01 ‖ left ‖ right). Compare the returned root to the root in an evidence package yourself; if it differs, the package was tampered with.

Returns {recomputed_root, merkle_scheme, steps}.

Name	Required	Description	Default
`leaf`	Yes	The raw leaf value (e.g. a JSON string like '{"k":"total_assets","v":"..."}'). Hashed in the leaf domain as H(0x00 ‖ leaf).
`proof_path`	Yes	Ordered Merkle proof path: a list of [sibling_hash_hex, side] pairs, where side is "L" if the sibling is on the left or "R" if on the right. Empty list for a single-leaf tree.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, but the description adds meaningful context beyond them: the operation is purely local, performs no anchor check, and its output is only useful when compared against the package root. It does not discuss failure modes for malformed proof paths, which keeps it short of a 5.

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?

Purpose is front-loaded in the first sentence, followed by mechanics and then the return shape, so an agent can stop reading early. The middle paragraph is dense but every clause (domains, side semantics, tamper comparison) does work; a return-shape line plus a hashing explanation is close to the minimum.

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?

There is no output schema, yet the description explicitly names the return object ({recomputed_root, merkle_scheme, steps}), and annotations cover the safety profile for this read-only, closed-world tool. Nothing an agent needs to invoke it or interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the field descriptions already document the leaf-domain hash, the [sibling_hash, side] pair shape and the empty-list case. The description nonetheless adds information not in the schema — internal nodes are hashed as H(0x01 ‖ left ‖ right) — which clarifies how proof_path is replayed.

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 first clause gives a specific verb and resource ('Recompute a dokimo-merkle-v1 root locally') and immediately scopes it with 'no network call, no anchor check', which separates it from verify_evidence_package. An agent can pick this tool without opening either schema.

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?

It states the operative workflow clearly: recompute, then compare the returned root against the root in an evidence package yourself to detect tampering. It does not explicitly name verify_evidence_package as the alternative for anchor-based verification, only negating that capability, so the routing is implied rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_evidence_packageA

Read-onlyIdempotent

Inspect

Ask Dokimo to check one record of an evidence package against the on-chain anchor.

Sends the package to Dokimo's public A2A endpoint, which recomputes the Merkle proof AND checks the anchored commitment (root + rule version, plus the close summary for v2) against the anchor on Base. The verdict is Dokimo's answer and is not signed. package must contain: leaf (str), root (str), proof_path (list of [sibling_hash, "L"|"R"]), and rule_version_commitment (str); for a v2 close also summary and binding; close_id is optional/echoed.

Returns the verdict: {verified, checks:{recompute, onchain_anchor, rule_version_bound}, ...}. verified is true only if the proof recomputes AND the commitment is anchored on-chain. It covers this one record only.

Name	Required	Description	Default
`package`	Yes	The Dokimo evidence package to verify. Required keys: 'leaf' (str), 'root' (str), 'proof_path' (list of [sibling_hash, "L"\|"R"]), and 'rule_version_commitment' (str). For a dokimo-anchor-v2 close (every close anchored after the v2 cutover) also 'summary' (the close summary) and 'binding' (the leaf's evidence binding); without them the package is checked as legacy v1. 'close_id' (str) is optional and echoed back.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld/idempotent annotations, it discloses that the package is sent to Dokimo's public A2A endpoint, that the verdict is NOT signed, exactly what gets checked (Merkle recompute plus root and rule-version binding against the Base anchor, with the close summary for v2), and that verification is limited to one record. These are material trust and scope facts an agent could not infer from annotations.

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?

Front-loaded with the action and target, then the required package shape, then the return contract — a sensible order with little filler. Some of the package-key enumeration duplicates the schema description and could be trimmed.

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?

No output schema exists, yet the description supplies the return shape ({verified, checks:{recompute, onchain_anchor, rule_version_bound}}) and the precise semantics of verified (true only if both recompute and anchor checks pass). Combined with the v1/v2 package requirements and the unsigned-verdict caveat, an agent has everything needed to call and interpret it.

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 description coverage is 100% and the schema already enumerates leaf, root, proof_path, rule_version_commitment, summary, binding, and the optional echoed close_id, including the v1 fallback. The description largely restates those keys rather than adding new semantics, so it earns the baseline rather than more.

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?

States a specific verb (verify/check) and resource (one record of an evidence package) against a named target (the on-chain anchor on Base). The scope line 'It covers this one record only' and the mention that the proof is recomputed distinguish it from the sibling recompute_merkle_root, which only recomputes.

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 makes clear the invocation context (verify a package against the anchored commitment, v1 vs v2 handling, single-record scope), so an agent knows when this tool applies. It stops short of naming recompute_merkle_root as the alternative for pure proof recomputation, so routing is inferable rather than explicit.

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.

1 tool updateOct 25, 2026

Changedverify_evidence_package1 field changed

changedInput schema / properties / package / description

Previous value: -"The Dokimo evidence package to verify. Required keys: 'leaf' (str), 'root' (str), 'proof_path' (list of [sibling_hash, \"L\"|\"R\"]), and 'rule_version_commitment' (str). 'close_id' (str) is optional and echoed back."New value: +"The Dokimo evidence package to verify. Required keys: 'leaf' (str), 'root' (str), 'proof_path' (list of [sibling_hash, \"L\"|\"R\"]), and 'rule_version_commitment' (str). For a dokimo-anchor-v2 close (every close anchored after the v2 cutover) also 'summary' (the close summary) and 'binding' (the leaf's evidence binding); without them the package is checked as legacy v1. 'close_id' (str) is optional and echoed back."

3 tool updatesv0.1.0Sep 11, 2026
- First observeddokimo_agent_card
- First observedrecompute_merkle_root
- First observedverify_evidence_package

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-10-25 13:50 across 3 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: local Merkle root recomputation, remote evidence verification against an on-chain anchor, and fetching the A2A agent card. The recompute vs. verify overlap is explicitly clarified (local/no network vs. remote/anchor check), leaving no realistic misselection risk.

Naming Consistency4/5

Two tools follow a clean verb_noun pattern (recompute_merkle_root, verify_evidence_package), while dokimo_agent_card is a noun phrase with a vendor prefix. The deviation is minor and still predictable/readable.

Tool Count5/5

Three tools is well-scoped for a narrow evidence-verification server: one local primitive, one authoritative remote check, and one discovery document. Each earns its place with no filler.

Completeness4/5

The core verification lifecycle (recompute, anchor-check, discovery) is covered, but there is no tool to fetch the anchor/commitment data independently, list records, or batch-verify a package—minor gaps agents can work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Aval A
cloud.hstgr.srv1024618.aval
Payment-backed trust scores for AI agents on Base (ERC-8004). $0.01 per check via x402.
Blockchain Payments & Billing Agent Orchestration
21
https://aval.srv1024618.hstgr.cloud/mcp
The Emperor Protocol
com.theemperorprotocol
Commissioning, validation, and Confidence for AI agents, with real-USDC stakes on Base.
AI & Machine Learning Blockchain Autonomous Agents
1
https://theemperorprotocol.com/api/mcp
ProofMart A
io.github.ProofMart
One-stop claim verification for AI agents: verdicts with confidence, evidence, signed receipts.
AI & Machine Learning Autonomous Agents Search
21
https://proofmart.fly.dev/mcp
Fabric VerifyOAuth
ai.augmentev
Signed, publicly logged records of what your AI agent did, with proofs anyone can check offline.
Security Observability
1
https://mcp.augmentev.com/mcp

Related MCP Servers

Witnessed
Security Autonomous Agents
medtekki
A
license
Not graded
quality
D
maintenance
Verifiable action receipts for AI agents — agents sign claims locally, an independent witness countersigns and timestamps, anyone can verify offline.
Updated 5 months ago (2026-06-09 21:25 UTC)
7 npm
MIT
garlofficial
Security Blockchain Agent Orchestration
Garl-Protocol
A
license
Not graded
quality
F
maintenance
Cryptographic verification for AI agent actions — ECDSA-secp256k1 signed Action Receipts anchored on Base, multi-dimensional trust vectors, capability tokens, and offline-verifiable on-chain proof. 29 tools.
Updated a month ago (2026-09-24 10:41 UTC)
2
Apache 2.0
@sequesign/mcp
Autonomous Agents Security
Sequesign
A
license
A
quality
B
maintenance
Enables AI agents to create cryptographically verifiable receipts of their delegated work, with capabilities for multi-party approval and offline verification.
Updated 2 months ago (2026-08-21 03:03 UTC)
11
29 npm
Apache 2.0
BIII MCP Server
Blockchain Cryptocurrency Payments & Billing
philpof102-svg
F
license
Not graded
quality
A
maintenance
Enables agents to vet merchants, create and verify USDC charges and invoices, assess trust and tokenized-asset authenticity, and manage provable books on Base, all non-custodially.
Updated 2 months ago (2026-08-20 17:33 UTC)
30 npm
-

dokimo-mcp

Tools

Install & run

Add to an MCP client

Agent skill

Try it

Hosted / HTTP mode

What is Dokimo?

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Witnessed

garlofficial

@sequesign/mcp

BIII MCP Server