Doichain

Anchor a proof of existence

anchor_proof

Idempotent

Anchor a SHA-256 hash on the Doichain as a tamper-evident timestamp (proof of existence, name poe/). Free for users, limited per IP address and day (see get_anchoring_quota). Confirms with the next block, usually within 10 minutes, then check_proof returns block height and time. If the hash is already anchored or pending, the existing proof is returned instead of creating a second one. If an earlier proof of the hash has expired, it stays valid and is returned with expired true. Nothing is registered unless reanchor_expired is true. Only the hash and the optional note and file name become public, never the document itself. The operator of this server pays for the name and holds it. The proof shows that a document with this hash existed no later than the block time, not who submitted it.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional public note (max 160 characters), stored on the blockchain forever. No personal data, no secrets
`sha256`	Yes	SHA-256 digest of the document, 64 hexadecimal characters, computed from the actual file. Never guess it and never send the document
`filename`	No	Optional public file name (max 80 characters), stored forever. Only set it when the user explicitly wants the name public
`reanchor_expired`	No	Only set to true when an earlier proof of this hash has expired and the user explicitly wants an additional, later registration. The original anchoring stays the proof time. The new registration adds a later timestamp and replaces the public note and holder of the name. Default false

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / reanchor_expired

Added value: +{
+  "default": false,
+  "description": "Only set to true when an earlier proof of this hash has expired and the user explicitly wants an additional, later registration. The original anchoring stays the proof time. The new registration adds a later timestamp and replaces the public note and holder of the name. Default false",
+  "title": "Reanchor Expired",
+  "type": "boolean"
+}

First observedSep 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, idempotent=true, destructive=false, openWorld=true): it discloses idempotent behavior in concrete terms (existing/pending proof returned rather than duplicated), expired-proof handling, the public-data exposure boundary (only hash/note/filename, never the document), who pays and holds the name, confirmation latency (~10 minutes, next block), and the anonymity/scope limit of what the proof asserts. This is unusually rich behavioral context.

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 core action and cost, then layered with edge-case semantics. It is long and dense, but nearly every sentence carries distinct information (idempotency, expiry, exposure, latency); a small amount of repetition around expiry 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?

For a mutation tool with an output schema present, the description covers cost, quota, latency, idempotency, expiry, and data exposure, and defers return details to check_proof/output schema. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3; the description earns above that by adding cross-cutting semantics the schema does not, notably that nothing is registered unless reanchor_expired is true and that the original anchoring remains the proof time while the note and holder are replaced. It also reinforces the 'hash and optional note/filename become public' contract that spans multiple parameters.

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 (anchor) and resource (SHA-256 hash / proof of existence) and names the exact on-chain artifact (name poe/<sha256>). It is clearly distinguishable from siblings like check_proof and get_anchoring_quota, which it references by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames when to use it (free, per-IP/day limited, points to get_anchoring_quota for the limit) and when the destructive-adjacent reanchor_expired path applies ('Nothing is registered unless reanchor_expired is true'). It also routes the agent to check_proof for the confirmation result, leaving little to inference.

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

All Doichain tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.