Proof of existence, names and chain data of the Doichain blockchain for AI agents
Scored across 13 tools
Each tool targets a distinct resource and action: proof creation vs. checking, name lookup vs. expiry vs. search vs. history, and separate tools for addresses, transactions, blocks, and chain status. There is no overlap or ambiguity between tool purposes.
All tool names follow a consistent verb_noun pattern (e.g., anchor_proof, check_proof, get_address, lookup_name). While the verbs vary (anchor, check, get, hash, lookup, search, verify), the structure is uniform and predictable, making it easy to infer tool behavior from its name.
With 13 tools, the server is well-scoped for a blockchain API covering proofs, names, transactions, blocks, and network status. Each tool serves a distinct purpose and the count is within the ideal range, not overwhelming or sparse.
The tool surface covers the core workflows of the Doichain domain: anchoring and verifying proofs, querying names (lookup, search, history, expiry), retrieving transactions, blocks, address balances, and chain status. Read-only name operations are complemented by anchoring, and the server appropriately delegates name creation/update to wallets, so there are no obvious gaps.
Anchor a SHA-256 hash on the Doichain as proof that the document exists now (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. Only the hash and the optional note and file name become public, never the document itself.
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral detail beyond the annotations: free but rate-limited per IP/day, confirmation within ~10 minutes via next block, idempotent behavior (returns existing proof if already anchored), and a privacy guarantee (only hash, note, filename become public). The idempotentHint annotation is consistent with the described behavior, and the description explains the mechanics and the privacy implications, which are not in the annotations.
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 focused paragraph of five sentences. It front-loads the primary action, then delivers quota, timing, idempotency, and privacy in a logical order. Every sentence adds necessary information without redundancy or fluff.
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 an output schema present, the description does not need to explain return values. It covers the action, the blockchain context, quota, confirmation time, verification path, idempotency, and privacy. It also references the relevant sibling tools for follow-up actions, making the tool's role in the ecosystem clear. Nothing an agent needs to invoke 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 coverage is 100%, so all parameters are documented. The description adds the naming convention 'poe/<sha256>' and the global privacy statement 'Only the hash and the optional note and file name become public.' These details are not present in the schema descriptions, giving the agent extra semantic context about the parameters' roles and implications.
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 clear verb+resource: 'Anchor a SHA-256 hash on the Doichain as proof that the document exists now.' It specifies the exact artifact (poe/<sha256>) and references sibling tools (check_proof, get_anchoring_quota) to set itself apart. An agent immediately knows what this tool does and how it differs from related tools.
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 provides context for when to use the tool: it is free, quota-limited, and confirms with the next block. It explicitly points to get_anchoring_quota for limits and check_proof for verification, implying the workflow. It does not give an explicit 'use this when X, use Y when Z' statement, but the sibling references and the idempotent behavior (returning existing proof) cover most usage scenarios.
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), block height, block time of the first anchoring, transaction and links. A confirmed or expired proof shows that a document with exactly this hash existed no later than the block time.
| 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 already declare readOnlyHint and idempotentHint, and the description adds valuable behavioral detail: it lists the possible statuses, the included block height/time/transaction/links, and interprets what a confirmed or expired proof means. This goes beyond the structured data without contradicting it.
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?
Three sentences with no waste: first sentence states purpose and the name format, second enumerates return values, third explains the meaning of confirmed/expired. The most important information 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?
For a single-parameter, read-only tool with an output schema, the description covers the operation, the result semantics, and the interpretation of statuses. No essential calling context 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?
The input schema provides complete parameter documentation (format, length, acceptable prefixes) at 100% coverage. The description adds only the context that the hash is used as a name 'poe/<sha256>', which is a minor extra. This meets the baseline for high schema coverage.
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 uses a specific verb ('check') and resource ('SHA-256 hash anchored on the Doichain (name poe/<sha256>)'), clearly distinguishing it from siblings like anchor_proof (which creates the proof) and lookup_name (which looks up names generically).
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 states the tool's function and the meaning of its results, giving clear context for when to use it. It does not explicitly name alternatives or exclusions, but the specific name pattern 'poe/<sha256>' and the focus on proof-of-existence status make the intended use unambiguous.
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 active names that start with a prefix, in the node's order (shorter names first, then byte order). 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/ |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds valuable behavioral context beyond that: the node's ordering (shorter names first, then byte order), the pagination contract using next_after until exhausted is true, and the security-relevant warning that names and values are user-controlled.
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?
Three dense sentences with no filler: purpose, ordering, pagination, and trust considerations are each covered in sequence. Essential information is front-loaded before secondary details.
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 annotations covering safety and idempotency, an output schema available, and all params documented in the schema, the description supplies the remaining needed context: result ordering, pagination mechanics, and untrusted-data caveats. Nothing crucial for correct invocation or interpretation 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?
The input schema already documents all three parameters with 100% coverage, so the description does not need to repeat their meaning. It adds marginal semantic value by tying 'prefix' to the active-name enumeration behavior and by noting untrusted user input, but it does not meaningfully extend the schema's parameter documentation.
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 uses a specific verb-resource pair ('List active names that start with a prefix') and specifies the ordering, making the tool's function unmistakable. It also distinguishes this from sibling tools like lookup_name by emphasizing prefix enumeration rather than exact lookup.
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 when to use the tool: when you need to enumerate active names by prefix and page through results. It does not explicitly name alternatives or state when not to use it, but the prefix-list semantics and pagination instructions provide strong contextual guidance.
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_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.
Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
Cryptographic proof-of-existence notarization for AI agents. Free tier + paid $0.01 USDC via x402.
Machine-native utility network: verified evidence services for autonomous agents.
Add one secure layer between your agents and this server.
