robotbase-mcp

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a real operational trait beyond the schema: highly active addresses such as exchange cold wallets may return a degraded hint due to indexing load, which is genuinely useful. It stops short of covering auth requirements, rate limits, or pagination/return formatting details.

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 purpose, then cleanly partitioned into labeled sections (when-to-use, caveat). Every sentence earns its place with no redundancy, and the return-field list is delivered compactly.

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 tool with no annotations or output schema, the description is nearly self-sufficient: it covers purpose, accepted inputs, example intents, and a degradation caveat. Minor residual gaps (auth/rate behavior, whether the degraded response still contains partial data) keep it just under full completeness.

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?

With a single parameter at 100% schema coverage, the baseline is 3, but the description adds meaning beyond the schema by enumerating the accepted address formats (P2PKH 1…, P2SH 3…, bech32 bc1q…, bech32m bc1p…), letting an agent validate input types before invoking.

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 (query) and resource (Bitcoin address) and enumerates exactly what is returned: confirmed/unconfirmed balance, UTXO count/total, transaction count, and the last 10 transactions. This clearly separates it from sibling tools like btc_tx_lookup and btc_block_summary, which operate on different entities.

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 【何时用】 section gives concrete user-intent triggers ('how much BTC does this address have / has it received a payment / activity level'), which is strong contextual guidance. It does not, however, name alternative tools or state when NOT to use it (e.g., for transaction-level inspection use btc_tx_lookup).

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait that omitting parameters returns the current chain-tip block. It does not cover error behavior, what happens if both height and blockhash are supplied, or costs/limits, so it is only adequate.

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?

A single front-loaded sentence: resource and returned fields first, then default behavior, then usage triggers in a bracketed clause. Nothing is wasted and the most important information comes first.

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 two-optional-parameter read tool with no output schema, the description covers the returned fields, the default resolution rule, and use cases. Remaining gaps (mutual-exclusivity handling, error cases) are minor but present.

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 parameters are documented in the schema itself. The description adds the defaulting behavior when no parameter is passed, which the schema does not state, giving it a slight edge over the baseline of 3.

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 (查询/query) and resource (比特币区块摘要) and enumerates exactly what the summary contains: transaction count, size, weight, block time, confirmations. This clearly separates it from siblings like btc_mempool_summary and btc_tx_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 【何时用】 section gives concrete usage triggers with example questions ('latest block tx count', 'overview of a height or hash'), and it explains the no-argument default. It stops short of naming an alternative tool or a when-not-to-use case, but context is clear.

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

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

With no annotations, the description carries the full burden: it discloses that the tool is a read-only query, enumerates the confirmation targets returned, and specifies units (BTC/kvB) plus an extra returned metric (mempool minimum). It does not mention data freshness, caching, or rate limits, so it stops short of fully transparent 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?

Extremely compact and front-loaded: capability sentence first, then bracketed usage and anti-usage markers. Every clause carries information — targets, units, return extras, trigger intent, and the excluded sibling — with no filler.

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?

No output schema exists, so the description correctly does the work of explaining return values (fee rates per confirmation target plus mempool minimum, in BTC/kvB). Combined with the routing guidance, an agent has everything needed to call and interpret this zero-parameter tool.

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 takes zero parameters (empty schema, 100% coverage trivially), so there is nothing for the description to disambiguate. Baseline 4 applies; the description's mention of confirmation targets is a return-value explanation, not a parameter contract.

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 (query) and resource (Bitcoin recommended fee estimates), plus the exact confirmation targets (1/2/3/6/12/24 blocks) and output units (BTC/kvB). It also names a distinguishing return value (mempool minimum fee rate), which separates it from sibling 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?

Explicit 【何时用】 trigger gives a natural-language user intent ("how much fee should I pay / what gets fast confirmation"), and 【不要用】 names the sibling btc_mempool_summary with the condition that selects it (asking about congestion level). This is textbook when/when-not/alternative routing.

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

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

With no annotations, the description carries the full burden, and it does disclose the exact data surface the call returns (five named fields), which is meaningful since there is no output schema. The verb 查询 also signals a read-only operation. It stops short of stating auth/rate-limit behavior, so it is strong but not exhaustive.

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 short sentences, front-loaded with the resource and its returned fields, followed by the usage trigger. Every clause earns its place with no 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 zero-parameter read tool with no output schema, the description supplies both the trigger condition and the complete list of returned metrics, which is everything an agent needs to select and call 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 takes zero parameters, so there is nothing to mis-specify and no schema semantics to compensate for. Baseline of 4 applies; the description correctly implies the call needs no arguments.

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 (查询/query) and a precise resource (比特币内存池概况/Bitcoin mempool summary), then enumerates the exact contents: pending count, bytes, min fee rate, total fees, capacity limit. This clearly differentiates it from siblings like btc_fee_estimates (fee recommendations) and xmr_mempool_stats (different chain).

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 explicit 【何时用】 clause gives a concrete trigger scenario ('is the network congested / how big is the mempool backlog'), which is clear usage context. It does not, however, name an alternative tool or state when NOT to use this one versus btc_fee_estimates or btc_block_summary.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the returned information and implies a read-only lookup, which is useful context beyond the schema, but it does not mention error behavior, rate limits, or permissions explicitly.

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-loads the tool's output, then gives when-to-use and when-not-to-use guidance. Every sentence is purposeful, with no wasted 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?

For a simple one-parameter lookup with no output schema, the description is complete: it explains what the tool returns, when to call it, and which alternative to use for Monero. The schema handles the input constraint.

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 schema already documents that txid is a 64-character hex Bitcoin transaction hash. The description reinforces this but adds no additional parameter syntax, format, or edge-case guidance beyond what the schema provides.

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: query a Bitcoin transaction by txid, returning confirmation status, block height, confirmations, size, and input/output summaries. It clearly distinguishes this tool from related siblings such as btc_block_summary and xmr_tx_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?

It gives an explicit when-to-use condition (user provides a 64-character hex BTC txid and asks whether it is confirmed or in which block) and an explicit when-not-to-use alternative (Monero transactions should use xmr_tx_lookup).

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

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

No annotations are provided, so the description carries the full load. It discloses precisely what data the agent gets back (height, sync progress, peers, mempool size, client version), which sets correct expectations for a status query. It does not state that the call is side-effect-free or what happens for an unreachable/unknown chain, but for a read-only 'query' verb the residual risk is small.

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-loads the core purpose, then uses tight bracketed sections for when-to-use and when-not-to-use. Every clause earns its place; no filler or restated name/title.

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 no output schema present, the description must describe the returned metrics, and it does so explicitly. Combined with routing guidance for the fee/balance siblings, the definition is complete enough for a one-parameter read tool.

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?

There is a single required parameter whose enum and description are already fully documented in the schema (100% coverage). The description adds no syntax, default, or format detail beyond that, so the baseline 3 applies.

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 and resource: queries the running status of one chain's node, and enumerates exactly what is reported (block height, sync progress, peer count, mempool tx count, client version). The scope is narrowed to a single chain, so an agent can distinguish it from multi-chain or non-node-status siblings.

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?

Explicit 何时用 section names the triggering question ('is this chain's node synced/healthy/behind') and the 不要用 section routes the agent to btc_fee_estimates/xmr_fee_estimate for fees and btc_address_summary for balances. It does not address the overlapping status siblings (utxo_chain_status, zec_chain_info), leaving some ambiguity unresolved, so it falls short of a full 5.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the return content (availability plus block height) and that values are real-time, but says nothing about freshness/latency, caching, or that the operation is a safe read. Adequate but with clear gaps for a zero-annotation tool.

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-loads the resource and covered chains, then uses bracketed markers to separate usage and anti-usage guidance. Every sentence earns its place; no filler.

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?

There is no output schema, and the description compensates by stating what is returned (chain list, real-time availability, block height). It does not sketch the response shape or ordering, but for a zero-parameter list tool an agent has everything 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 takes zero parameters, so per the rubric the baseline is 4. There are no parameters whose meaning could be elaborated, and the description correctly adds no parameter discussion.

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 (全部公链), enumerates the exact chains covered (BTC/XMR/ZEC/DOGE/LTC), and names the sibling it is not (chain_status). An agent can distinguish it from chain_status and the per-chain tools without opening any 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?

Provides explicit when-to-use triggers ("你支持哪些链 / 哪些节点在线 / 各链现在多高") and an explicit when-not with the alternative tool named ("查单条链的细节状态请用 chain_status"). Routing is fully determined.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the status is '实时' (live, not cached) and enumerates coverage, but says nothing about auth requirements, rate limits, or what a status result looks like. For a read query this is adequate but thin.

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 tightly packed blocks: scope first, then usage triggers. Every clause earns its place and the scope enumeration is front-loaded before the when-to-use hint.

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 status aggregator with no output schema, the description is nearly complete: it names the covered services and the use case. The only gap is that, with no output schema present, it does not hint at the shape of the status response an agent should expect.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies a no-argument whole-gateway scan.

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 (查询) and resource (全部服务的实时可用状态), and enumerates exactly what 'all services' means: 5 chain nodes + Web3 Agent Hub + AITOKENS + MCP itself. This aggregate scope cleanly distinguishes it from single-target siblings like chain_status, list_chains and utxo_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 【何时用】 block gives concrete triggers ('整体巡检' / '有哪些服务挂了'), which clearly frames it as a fleet-wide health check. It does not name specific alternative tools or state when not to use it, so it stops short of the explicit routing a 5 requires.

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

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

With no annotations, the description carries the full transparency burden. It usefully discloses the returned status fields, but says nothing about rate limits, network/permission requirements, or error behavior when a chain is unsupported.

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?

Compact and front-loaded: purpose plus returned fields first, then the when-to-use routing note. Every sentence carries signal with no padding.

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 one-parameter read tool with 100% schema coverage and no output schema, the description supplies returns, usage trigger, and the alternative tool, which is sufficient to call correctly. The only residual gap is the missing rationale versus chain_status.

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% with a single enum-constrained 'chain' parameter, so the schema already fully documents the input. The description adds only the human-language restatement (doge/ltc) and no extra syntax or default details, so the baseline of 3 applies.

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 and resource (查询 DOGE/LTC 节点状态) and enumerates exactly what is returned (高度、同步进度、连接数、内存池笔数), which lets an agent distinguish it from the sibling chain-specific tools. It also explicitly delimits scope to DOGE/LTC, ruling out the other chains.

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?

Gives an explicit trigger ([何时用] 问狗狗币/莱特币节点进度) and routes non-DOGE/LTC chains to chain_status. It does not explain why one would pick this over chain_status for a doge/ltc query, even though chain_status reportedly accepts any chain, leaving a slight routing ambiguity.

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

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

No annotations are provided, so the description carries the full burden. '查询' implies a read-only operation, and the description lists output categories (per-byte fee, tiered rates, quantized mask), which adds behavioral context beyond an empty schema. However, it does not state absence of side effects, permissions, rate limits, or return latency—minimum adequate disclosure for a query tool.

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?

A single sentence with two clearly bracketed sections: purpose first, then when-to-use. Every phrase earns its place, with no redundancy or filler.

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 tool with no output schema, the description supplies purpose, when-to-use, and the main return categories. It does not explain the technical term '量化掩码' or provide a full return format, but it is sufficient 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 tool takes zero parameters, so parameter semantics are not applicable. Per the rules, a 0-parameter tool receives a baseline of 4. The description does not need to add parameter meaning.

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 (查询) and resource (门罗币手续费估算), and details the fee types (字节费率、分档费率低/中/高、量化掩码). The explicit '门罗币' distinguishes it from the sibling btc_fee_estimates (Bitcoin). An agent can identify it as the XMR fee estimator without opening any 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?

Includes an explicit 【何时用】 section with sample user phrasing: 'XMR 转账要多少手续费 / 现在费率多少'. This gives clear context for when to invoke the tool. It does not name alternatives or when-not to use it, but the sibling tools are clearly differentiated by currency.

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

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

No annotations exist, so the description bears the full burden. It implicitly reads as a simple read-only lookup and discloses the returned fields, but says nothing about permissions, rate limits, or data freshness/lag for 'latest'. Adequate but with real gaps.

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 bracketed segments, zero filler. The purpose and field list come first, the usage trigger second, both 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 zero-param, no-output-schema read tool, the description covers both what comes back and when to call it. Adding freshness/lag semantics would make it complete, but nothing essential 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 tool takes zero parameters, so there is nothing to mis-document; the baseline for a no-param tool applies. No parameter meaning 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?

States a specific verb and resource ('查询门罗币最新区块头') and enumerates the exact fields returned (height, hash, timestamp, difficulty, reward, tx count), which is more precise than the bare name. It does not name a sibling to differentiate against, so it sits at 4 rather than 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?

The 【何时用】 block explicitly names the triggering questions: latest XMR block time, latest height, and whether the chain is stuck. That is concrete when-to-use guidance, though no alternative tool is cited for overlapping needs.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the payload (bytes, fees, histogram), which is genuinely useful as a read-only signal, but says nothing about data freshness/refresh cadence, whether the node is local or remote, or any rate limits.

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 dense, front-loaded bracketed clauses: purpose plus returned metrics first, then the when-to-use trigger. Every clause earns its place, though the bracketed telegraphic style is slightly terse rather than maximally readable.

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 no-parameter, read-only stats query with no output schema, the description supplies the key missing piece by enumerating the metrics returned. Nothing essential for correct invocation is absent, though freshness and provenance of the mempool data remain unspecified.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a 0-parameter tool is 4. The empty schema with additionalProperties=false is self-explanatory and the description correctly says nothing about arguments.

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 and resource (query Monero mempool statistics) and enumerates the returned metrics: total bytes, aggregate fees, and a size-bucketed transaction histogram expressing congestion. The 'XMR' scope plus the metric list clearly separates it from siblings like xmr_fee_estimate, xmr_node_info, and btc_mempool_summary.

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 【何时用】 block gives an explicit use condition with example user phrasings ("is XMR congested right now / how many transactions are in the mempool"), which is concrete guidance rather than implied. It stops short of naming alternatives or exclusions, e.g. directing fee-related questions to xmr_fee_estimate, so it is not a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. '查询' strongly implies a read-only operation and the field list describes what comes back, but it never explicitly states absence of side effects, required permissions, or rate limits. Adequate but thin for a no-annotation tool.

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 compact segments: the purpose and returned-metric list are front-loaded, followed immediately by the bracketed usage cue. Every element earns its place with no redundant padding.

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 no output schema, the description usefully compensates by enumerating the fields the caller will receive. For a zero-parameter query tool this is nearly complete; only response format/pagination details are absent, which is a minor gap here.

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?

Zero parameters with 100% schema description coverage; per the rubric this is the baseline 4. There is no parameter meaning for the description to add.

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 (查询), resource (门罗币全节点信息), and enumerates the returned metrics: height, sync status, difficulty, connections, DB size, mempool count, version. This breadth is distinguishable from narrower siblings like xmr_last_block and xmr_mempool_stats without naming them directly.

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 explicit 【何时用】 section gives three concrete user intents: checking node height, sync status, or network connectivity. It clearly signals the right context, but names no alternative tool and no when-not-to-use condition, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the returned information: mempool presence, on-chain status, block height, confirmations, input/output counts, and output indices. It omits explicit read-only/no-side-effect and rate-limit/permission details, a minor gap for a lookup tool.

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 Chinese description is compact and front-loaded: purpose first, then when to use, then when not to use. Bracketed sections aid scanning, and every sentence contributes useful routing or scope information.

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 lookup with no output schema, the description lists the main return fields and gives explicit usage boundaries and the alternative tool. Combined with the complete txid schema, an agent has enough context to call it correctly; missing edge-case notes are acceptable at this complexity.

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 has 100% description coverage for the single txid parameter, including the 64-hex pattern and its meaning. The description does not add format or semantic details beyond the schema, so the baseline score of 3 applies.

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 and resource: query a Monero transaction by txid, and enumerates returned fields (mempool/on-chain status, block height, confirmations, input/output counts, output indices). It also explicitly excludes Bitcoin transactions, so an agent can distinguish it from the sibling btc_tx_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?

Gives explicit when-to-use guidance (determine whether an XMR transaction/atomic swap is on-chain or timed out unconfirmed) and when-not-to-use guidance (Bitcoin transactions -> btc_tx_lookup). The alternative is named, satisfying the highest bar.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does disclose the return contents (per-pool supply across 6 pools), which is the key behavioral trait for an info tool, but says nothing about read-only status, idempotency, rate limits, auth requirements, or response format. Reasonable but incomplete for a no-annotation tool.

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 purpose, then bracketed 【何时用】/【不要用】 markers that make routing scannable. Every clause earns its place and nothing is restated from the name or schema.

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-param read-only info tool with no annotations and no output schema, the description covers purpose, trigger, exclusion, and returned fields well. The only residual gap is response shape/format, which the absent output schema leaves unspecified.

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 takes zero parameters (schema coverage 100%, trivially), so there is no parameter semantics to convey. Per the baseline rule, 0 params scores 4 with no description-side compensation required.

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 and resource (查询 Zcash 主网信息) and enumerates the exact payload: 6 value pools (transparent/sprout/sapling/orchard/lockbox/ironwood). It explicitly frames this as 【屏蔽池状态】 and names the sibling chain_status as a different concern, so an agent can separate it from zec_recent_blocks and chain_status without opening a 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?

Provides explicit 【何时用】 with a concrete trigger ('shielded/sapling/orchard 池子里有多少 ZEC / 隐私池规模') and an explicit 【不要用】 that routes node-sync questions to chain_status(zec). This is the full when/when-not/alternative triad, not just implied usage.

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

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

No annotations are provided, so the description carries the full disclosure burden. It conveys the 20-block cap and the returned fields, implying a safe read, but never states read-only semantics, rate limits, or pagination behavior. Adequate but with clear gaps for a zero-annotation tool.

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 compact clauses: the core purpose first, then a bracketed when-to-use tag. Nothing is padding and the scope/limit is front-loaded. Slightly dense but well structured.

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 one-parameter, no-output-schema tool this is nearly complete: it names the returned fields, which compensates for the missing output schema, and clarifies the block count cap. Only the absence of any read-only/rate-limit note keeps it from a 5.

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 single parameter n is fully documented in the schema (default 5, min 1, max 20). The description only repeats the N max 20 constraint, adding no syntax or range meaning beyond the schema. Baseline 3 applies.

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 (查询/query) and resource (Zcash 最近 N 个区块) and enumerates the returned fields (高度、哈希、出块时间、难度), so the agent knows exactly what data comes back. It does not explicitly differentiate itself from the sibling zec_chain_info, so it falls 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?

The 【何时用】 section gives a concrete triggering scenario: checking whether ZEC recent block production is normal and the block interval. This is clear context, but it names no alternative (e.g. zec_chain_info for broader chain state) and states no exclusions, so it is a 4 rather than a 5.

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