Skip to main content
Glama
ypratap11

dokimo-mcp

by ypratap11
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

dokimo-mcp

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

An MCP server exposing Dokimo's trustless evidence verification 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)

Trustless local recompute — hash a leaf under dokimo-merkle-v1 and replay the proof path to a root, with no network and no trust in anyone. Compare it to a package's claimed root yourself.

none

verify_evidence_package(package)

Full verification via Dokimo's public A2A endpoint: recompute and check the compound commitment (root + rule version) against the on-chain anchor on Base. Returns verified: true only if both hold.

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 compound commitment of (root, rule_version_commitment) being anchored on-chain. Tamper one byte → recompute fails. Swap the rule version → the commitment changes → not anchored.

Honest scope: attests that a reported figure is reproducible and tamper-evident against an on-chain anchor — not that any underlying 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."

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).

ParametersJSON Schema
NameRequiredDescriptionDefault

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

Trustlessly recompute a dokimo-merkle-v1 root — LOCAL, no network, no trust.

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}.

ParametersJSON Schema
NameRequiredDescriptionDefault
leafYesThe raw leaf value (e.g. a JSON string like '{"k":"total_assets","v":"..."}'). Hashed in the leaf domain as H(0x00 ‖ leaf).
proof_pathYesOrdered 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.7/5.0
Behavior5/5

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

Annotations already declare read-only and idempotent behavior; the description adds the exact hashing algorithm, domain separation, the no-network guarantee, the returned fields, and the caveat that comparison is the caller's responsibility. No contradiction with 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?

Every sentence earns its place: purpose, algorithm, caller responsibility, and return shape are packed into a compact, front-loaded description with no filler.

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 two-parameter pure computation tool, the description fully covers the algorithm, parameter semantics, return object, and the expected post-call action. The missing output schema is mitigated by explicitly listing the returned fields.

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%, so the baseline is 3. The description adds operational meaning: leaf is hashed in the leaf domain, proof_path is replayed in order, and the side determines left/right ordering during internal-node hashing.

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 action ('recompute') and resource ('dokimo-merkle-v1 root'), with the key distinguishing trait 'LOCAL, no network, no trust.' It also implicitly differentiates itself from verify_evidence_package by instructing the caller to do the comparison themselves.

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?

Provides clear usage context: recompute locally and compare the returned root to the root in an evidence package; a mismatch signals tampering. It does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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

Fully verify a Dokimo evidence package against the LIVE on-chain anchor.

Sends the package to Dokimo's public A2A endpoint, which recomputes the Merkle proof AND checks the compound commitment (root + rule version) against the anchor on Base. package must contain: leaf (str), root (str), proof_path (list of [sibling_hash, "L"|"R"]), and rule_version_commitment (str); 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
packageYesThe 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.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark this as read-only and idempotent, and the description adds meaningful behavioral context: the package is sent to Dokimo's public A2A endpoint, relies on the live Base on-chain anchor, and the verdict only succeeds when both proof recomputation and on-chain commitment checks pass. No contradiction with 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?

The description is compact, front-loaded with the core purpose, and every sentence adds necessary information: required package structure, verification behavior, and verdict semantics. There is no filler or redundancy.

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 nested-object tool with no output schema, the description fully covers the required input structure, the remote verification behavior, and the return verdict shape including when verified is true. It is complete enough for an agent to invoke the tool correctly without additional information.

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 tool description largely mirrors the schema by listing the required package keys and noting that close_id is optional/echoed. It adds no meaningful semantic value beyond what the schema already provides, so the baseline of 3 applies.

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?

Opens with a specific verb and resource: 'Fully verify a Dokimo evidence package against the LIVE on-chain anchor.' It clearly distinguishes from sibling recompute_merkle_root by explaining that verification includes both Merkle proof recomputation and on-chain anchoring.

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 the use case clear: full verification including on-chain anchor checking, which is distinct from merely recomputing a Merkle root. It does not explicitly name the alternative or state when not to use this tool, but the context is strong enough for an agent to route correctly.

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. 3 tool updatesv0.1.0
    • 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.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: recompute locally, verify against on-chain anchor, and fetch discovery metadata. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (recompute_, verify_, dokimo_agent_card), which is predictable and readable.

Tool Count5/5

With only 3 tools, the server is tightly scoped to its specific verification workflow. Each tool is necessary and earns its place.

Completeness4/5

The surface covers local recompute, full verification, and discovery. The only minor gap is the lack of a tool to fetch or construct evidence packages, but that is outside the core verification workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Witnessed

    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.
    19 npm
    MIT
  • garl by Garl-Protocol

    garlofficial

    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.
    2
    Apache 2.0

  • @sequesign/mcp

    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.
    11
    47 npm
    Apache 2.0