Proof of existence, names and chain data of the Doichain blockchain for AI agents
Scored across 13 tools
Most tools target distinct actions/resources (anchor_proof creates, check_proof reads proofs, hash_text computes a digest). There is minor overlap: check_proof, lookup_name and check_name_expiry all surface name expiry/status, but the detailed descriptions clearly differentiate their focus (proof, single name value, batch expiry).
All 13 tools use consistent snake_case with a predictable verb_noun or verb_noun_noun pattern (anchor_proof, check_proof, get_block, lookup_name, search_names, verify_message). No camelCase or vague verb mixing.
13 tools is comfortably within the well-scoped range and each has a clear, non-redundant purpose across anchoring, name inspection, chain data and utility functions. No padding or obvious missing coverage.
The surface covers anchoring (create/check/quota), names (lookup/search/history/expiry), chain data (status/block/transaction/address) and helpers (hash_text/verify_message), which is strong for a proof-of-existence service. Minor gaps: no explicit fee/mempool tool or name registration/update operation, though the server appears intentionally read-only apart from anchoring.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Check up to 25 names at once: status (active, expiring_soon, expired, not_registered), blocks left, an estimated expiry date for active names (from the measured block interval) and the real expiry date for expired names. Names expire 36,000 blocks after their last update and are renewed by updating them from the owning wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Up to 25 full names, for example ['d/example', 'poe/<sha256>'] | |
| warn_days | No | Names expiring within this many days are flagged expiring_soon |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail: the 36,000-block expiry rule, the distinction between estimated and real expiry dates, and the renewal mechanism. This goes well beyond the annotation surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core capability ('Check up to 25 names at once') stated first. The second sentence earns its place by explaining the expiry mechanism necessary for interpreting the results. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strongly informative annotations, the description covers what the tool does, its batch limit, its status vocabulary, and the underlying expiry rule. Nothing essential for selecting or invoking this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains both names and warn_days. The description adds context about the statuses and expiry calculation, but it does not materially enhance parameter-level understanding beyond what the schema supplies. A baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('names expiry'), and enumerates concrete outputs (status, blocks left, estimated/real expiry dates). It distinguishes itself from siblings by emphasizing the batch capability of up to 25 names at once, which lookup_name and search_names do not offer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for checking multiple names in one call and provides the expiry rule context. It does not explicitly name alternatives or say when not to use it, but the batch-oriented wording and sibling names make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a SHA-256 hash is anchored on the Doichain (name poe/) and since when. Returns status (confirmed, pending, expired, unknown) and at the top level block height, block time, transaction and links of the first anchoring, which is the proof time. If the name was updated later or registered again after it expired (possibly by someone else), that registration is reported separately in latest_registration with its own holder and record, which are not part of the original proof. A confirmed or expired proof shows that a document with exactly this hash existed no later than the block time, not who submitted it.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes | SHA-256 digest of the document, 64 hexadecimal characters (a sha256: or 0x prefix is accepted) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial behavior beyond them: the status vocabulary (confirmed, pending, expired, unknown), the split between the first anchoring as proof time and a separate latest_registration for re-registrations by possibly different holders, and the crucial caveat that a proof shows existence, not submitter identity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and return shape are front-loaded in the first sentence, and the later sentences carry non-redundant caveats about latest_registration and submitter anonymity. It is dense rather than padded, though the third sentence is long enough that slightly tighter phrasing would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists and return values need not be spelled out, the description still explains the status field and the first-anchoring versus latest_registration distinction, which is exactly the ambiguity an agent would otherwise misread. Nothing needed to call or interpret the result correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented, so the baseline would be 3. The description adds meaning beyond the schema by revealing that the hash is mapped to a Doichain name of the form poe/<sha256>, which explains how the input is actually interpreted on chain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether a SHA-256 hash is anchored on the Doichain (name poe/<sha256>) and since when.' It also exposes the underlying name mapping, which lets an agent separate this read-only lookup from the sibling mutation tool anchor_proof 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the read counterpart to anchor_proof is obvious from context, but there is no explicit 'use this when / use X instead' routing, nor any stated prerequisites. The verification semantics ('confirmed or expired proof shows a document existed no later than block time') hint at appropriate use but stop short of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirmed and unconfirmed balance of a Doichain address in DOI, optionally with its most recent transactions. Invalid addresses return an error with the reason.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Doichain address (M... or N..., 6..., or bech32 dc1q...) | |
| history_limit | No | Number of recent transactions when include_history is true | |
| include_history | No | Also return the most recent transactions |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description goes beyond these by specifying that both confirmed and unconfirmed balances are returned, that history is optional, and that invalid addresses produce an error with the reason. This adds meaningful behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the primary function, optional behavior, and error case with no wasted words. The main balance result is front-loaded, followed by the conditional transaction history and error handling. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent query tool with an output schema and full parameter documentation, this description is complete. It covers the return value, denomination, optionality of history, and error behavior. Sibling overlap is minimal, and the output schema handles return structure, so nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is already well documented in the schema, so the baseline is 3. The description adds modest value by clarifying that transaction history is optional (signaling the include_history default) and that the balance is in DOI, but it does not meaningfully expand on the parameters themselves. No compensation is needed for coverage gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns the balance of a Doichain address in DOI, with confirmed and unconfirmed balances. This clearly distinguishes it from sibling tools like get_block, get_transaction, and lookup_name, which address different resources. The optional transaction history is also mentioned, scoping the tool's full purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear and unambiguous: this is the tool for querying an address's balance, optionally with recent transactions. Although no sibling alternatives are named explicitly, none of the listed siblings overlap with this function, so an agent can identify when to call it. The description does not state exclusions, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many proofs can still be anchored today (UTC day) within the free public quota for the caller's IP address. Hosted chat apps connect from their own servers, so their users share one quota. Callers that send their own API key in the X-API-Key header have no quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: quota resets per UTC day, it is per IP, hosted chat apps share quota, and API-key callers bypass quota entirely. This is valuable context an agent needs to interpret the result correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The primary question is front-loaded, followed by two concise sentences that explain quota-sharing and the API-key exception. Every sentence adds needed context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, strong annotations, and an output schema, the description provides all necessary operational context: the UTC-day window, IP-based quota, the hosted-app sharing caveat, and the API-key exemption. Nothing essential is missing for an agent to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantic burden on the description. The schema already fully covers the empty parameter set, satisfying the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning how many proofs can still be anchored today within the free public quota. It names the specific resource (quota) and the relevant qualifier (caller's IP, UTC day), which distinguishes it from sibling tools like anchor_proof and check_proof.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not name an alternative tool, but it gives clear context on when the quota applies and how the caller is classified: hosted chat apps share one quota, while callers with an X-API-Key header have no quota. This effectively tells an agent how to interpret the result, though it stops short of explicit when-to-use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Header data of a block by height or hash: time, confirmations, number of transactions and the first 50 transaction IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| block | Yes | Block height (number) or block hash (64 hexadecimal characters) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond annotations, especially the 'first 50 transaction IDs' limit, which warns the agent that the result is intentionally partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence communicates the resource, lookup method, and return contents. There is no filler or repetition of the schema, and the most important scoping detail ('header data') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, a well-documented schema, rich annotations, and an output schema, the description fills the remaining gaps: what kind of data is returned and the 50-transaction limit. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter with 100% coverage, including the height-or-hash format. The description's 'by height or hash' adds little beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Header data of a block by height or hash' and enumerates the exact content (time, confirmations, transaction count, first 50 IDs). This clearly distinguishes it from sibling tools like get_transaction and get_chain_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for retrieving block header data by height or hash. It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous for an agent deciding to fetch block-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current state of the Doichain network as seen by the node behind this server: block height, sync state, time of the last block, fork check, node version, peers, mempool size and whether public anchoring is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the data is node-local ('as seen by the node behind this server'), includes a fork check, and reflects a current snapshot. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then lists the key status components compactly. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status tool with rich annotations and an output schema, the description is complete. It tells the agent what the tool reports, from whose perspective, and what categories of information are included; nothing else is needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers invocation requirements. The description adds a helpful preview of the returned status fields, which is valuable even though no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource—the Doichain network state as seen by the local node—and enumerates concrete fields such as block height, sync state, fork check, node version, peers, mempool size, and anchoring availability. This clearly distinguishes it from sibling tools that operate on blocks, transactions, names, or proofs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: this tool reports the node's view of current network status, so an agent can infer it is appropriate for status and health checks. It does not explicitly name alternatives or exclusions, but no sibling tool covers this aggregate network status, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All registrations and updates of a name, newest first: block height, transaction, owner address and the value at that time. Shows who held a name when, and every value it ever had.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name including namespace | |
| limit | No | Maximum number of entries, newest first |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context beyond that: newest-first ordering, the exact fields returned per entry, and the historical scope of who held a name when.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The key scoping phrase 'All registrations and updates of a name, newest first' is front-loaded, and the second sentence reinforces the value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, full annotations, and 100% schema parameter coverage, the description covers purpose, ordering, and returned content. Nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns all registrations and updates of a name, newest first, with block height, transaction, owner address, and value. This clearly distinguishes it from current-state tools like lookup_name or search_names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when historical ownership or value changes are needed, and the sibling list makes alternatives apparent. It does not explicitly name alternatives 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.
A transaction with confirmations, block time, outputs (amount in DOI and address) and any name operation (name_doi, name_update, ...) it contains.
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | Transaction ID, 64 hexadecimal characters |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds what data is included but does not disclose operational behavior such as behavior for unknown txids, confirmation semantics, or how name operations are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. Every phrase adds meaningful content about the transaction fields returned, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with a rich output schema and safety annotations, the description is largely complete. It could mention sibling distinctions or edge-case behavior, but those gaps are minor given the low complexity and existing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents txid as a 64-character hexadecimal string, so schema description coverage is 100%. The description adds no parameter-specific meaning beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a transaction and enumerates its contents (confirmations, block time, outputs, name operations), which distinguishes it from sibling tools like get_block or get_address. It lacks an explicit verb in the description itself, but the title 'Get a transaction' supplies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_block or get_name_history. There are no exclusions, prerequisites, or conditions stated, so an agent must infer usage solely from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the SHA-256 digest of a short text (UTF-8) on the server, for example to anchor a statement or a message with anchor_proof. The text is sent to the server but not stored or logged. For files and for confidential texts compute the hash locally instead (sha256sum file, or Get-FileHash -Algorithm SHA256).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to hash, encoded as UTF-8 exactly as given (whitespace and line breaks count), at most 40,000 characters |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that the text is transmitted to the server but not stored or logged, and that hashing is performed server-side. This privacy-related behavioral context is valuable and not available from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the main operation and use case are front-loaded, the privacy note follows, and the local-alternative guidance closes without redundancy. Every clause contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one fully documented parameter, clear safety annotations, and an output schema present, the description covers all operational aspects: what it does, why to use it, privacy behavior, and when to avoid it. Nothing essential is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the text parameter thoroughly (UTF-8 exact encoding, whitespace counts, max 40,000 chars), so the baseline is high. The description adds the useful qualifier 'short text' and reinforces the anchoring use case, though most parameter detail comes from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Compute the SHA-256 digest') and resource ('short text (UTF-8)'), and ties it to a concrete use case with anchor_proof. This is distinct from sibling tools like check_proof or verify_message, which handle verification rather than digest computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use server-side hashing (short texts, e.g., messages for anchor_proof) and when not to (files and confidential texts), providing concrete local alternatives such as sha256sum and Get-FileHash. This is direct, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current value, owner address and expiry of a Doichain name. Unregistered names come back with exists false and status not_registered (the name is free). Expired names have status expired and the real expiry date.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name including namespace, for example poe/<sha256>, d/example or id/alice |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral detail by describing how unregistered names return exists=false with status not_registered, and expired names return status expired with the real expiry date. This goes beyond the structured hints and clarifies edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then efficiently covers edge-case behavior in two additional sentences. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with an output schema present, the description covers the main purpose and important edge cases. The availability of an output schema means return-value details are already structured, and annotations cover safety. Nothing critical is missing, though it does not address sibling relationships or usage exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema fully documents the 'name' parameter with examples. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'a Doichain name', specifying the fields returned (value, owner address, expiry). It is clear and informative, but does not explicitly differentiate from sibling tools like check_name_expiry or get_name_history, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as check_name_expiry or search_names. The description gives context about unregistered/expired name statuses but does not state exclusions, prerequisites, or selection criteria for this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List names that start with a prefix, in the node's order (shorter names first, then byte order). Lists only active names unless include_expired is true. Expired names (for example old poe/ proofs) stay in the chain history and are listed with include_expired. Page through large results with next_after until exhausted is true. Names and values are chosen by arbitrary users (name_untrusted, value_untrusted).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Paging cursor: pass next_after from the previous result unchanged | |
| limit | No | Maximum number of names | |
| prefix | Yes | Name prefix, for example poe/, d/ or id/ | |
| include_expired | No | Also list expired names, for example proofs whose poe/ name has expired. Default false: active names only |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower, and the description nevertheless adds substantive behavior: default exclusion of expired names, where expired names live (chain history), the paging contract, and an untrusted-data warning. It does not mention rate limits or result-size behavior beyond pagination, keeping it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Ordering and scope are front-loaded, then default behavior, then pagination, then the trust caveat – a sensible priority sequence with no filler sentences. The trailing untrusted-name note is slightly jargon-heavy but is security-relevant, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return fields need not be restated, and the description still explains the paging outcome contract (next_after/exhausted). Combined with full schema coverage and annotations, an agent has essentially everything needed to call it correctly; only explicit sibling routing is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters, making 3 the baseline. The description reinforces include_expired semantics (active-only default) and cursor reuse ('pass next_after from the previous result unchanged'), which is helpful but largely duplicates the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (names) with a scoping qualifier (start with a prefix) plus the result ordering ('shorter names first, then byte order'), which separates it from exact-match siblings like lookup_name. It never names an alternative tool explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through the include_expired toggle and the paging loop instruction ('Page through large results with next_after until exhausted is true'), which is genuinely actionable context. However there is no explicit when-to-use/when-not statement or routing to siblings such as lookup_name or get_name_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a message was signed with the private key of a Doichain address (signmessage format). Only legacy addresses (M... or N...) can sign messages, bech32 addresses (dc1q...) are not supported. Useful to confirm that a statement really comes from the holder of an address.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Legacy Doichain address (M... or N...) that supposedly signed the message | |
| message | Yes | The exact signed text | |
| signature | Yes | Signature in Base64 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations: it discloses the address format limitation (legacy only, bech32 unsupported) and the signmessage format requirement. This is useful because it tells the agent what inputs will fail. It doesn't describe error behavior or return format, but the output schema exists and the annotations cover the safety profile, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with zero waste. The core purpose is front-loaded in the first sentence, the critical limitation is in the second, and the use case is in the third. Every sentence earns its place, and the structure is ideal for an agent scanning for relevance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose, full schema coverage, an output schema, and annotations covering safety. The description adds the key contextual detail (address format limitation) that an agent needs to avoid failed calls. It doesn't explain the return value, but the output schema exists, so that's not required. The only minor gap is that it doesn't mention what happens when verification fails (e.g., returns false vs throws an error), but this is a minor omission given the output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (address, message, signature) with descriptions. The tool description adds some context by explaining the address format constraint (legacy vs bech32) and the signmessage format, but it doesn't add significant meaning beyond what the schema already provides. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying whether a message was signed by the private key of a Doichain address. It specifies the exact format (signmessage format) and explicitly distinguishes it from other operations. The title 'Verify a signed message' is reinforced by the description, and the tool is clearly differentiated from siblings like hash_text or get_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to confirm that a statement really comes from the holder of an address. It also provides a clear exclusion: bech32 addresses (dc1q...) are not supported, only legacy addresses (M... or N...). This gives the agent actionable guidance on when to use it and when not to, which is more than most tool descriptions provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
anchor_proof1 field changedInput schema / properties / reanchor_expiredAdded 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"
+}search_names1 field changedInput schema / properties / include_expiredAdded value: +{
+ "default": false,
+ "description": "Also list expired names, for example proofs whose poe/ name has expired. Default false: active names only",
+ "title": "Include Expired",
+ "type": "boolean"
+}anchor_proofcheck_name_expirycheck_proofget_addressget_anchoring_quotaget_blockget_chain_statusget_name_historyget_transactionhash_textlookup_namesearch_namesverify_messageDurable identity and memory for AI agents, anchored on the Emercoin blockchain.
Shared, verifiable memory for machines and AI. Encode where data lives; decode with any AI.
Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
Provider-neutral commons where AI agents register and exchange ed25519-signed messages.
Add one secure layer between your agents and this server.
