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 that the tool is non-custodial, validates with testmempoolaccept before relaying, never relays rejected transactions, and is disabled by default unless RB_ENABLE_BROADCAST=1 is set. This is substantial, useful behavioral context for a mutating action.

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 every sentence earns its place: purpose, validation behavior, deployment flag, and usage context are all covered without repetition or fluff. It is front-loaded with the core action before supporting 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?

For a two-parameter tool with no output schema and no annotations, the description covers the key operational concerns: what the tool does, how it validates, when it should be used, and its deployment availability. The main missing piece is what the tool returns (e.g., txid or error), which would be useful given there is no output schema.

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 50%: signed_raw_tx_hex has a terse description and chain is just an enum. The description confirms the transaction is already-signed but does not add meaningful parameter-level detail beyond the schema, such as hex format expectations or what chain values mean. It is adequate but not compensating.

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 action ('Relay an already-signed raw transaction to the network') and clearly identifies the resource and delivery mechanism ('through our own full node'). It also distinguishes this tool from the read-only sibling tools by emphasizing that it is a broadcast/write action, so an agent can immediately tell what it does.

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 an explicit use case: 'an agent signed locally and wants a high-availability broadcast path.' This provides clear context for when to use the tool, though it does not explicitly name alternatives or state when not to use it, so it falls just 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?

The description discloses a behavioral nuance: that ultra-active addresses may return degraded responses under index load newsletter, which is helpful. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention any safety or read-only hints, but the nature of the tool implies a read-only operation, and the absence of annotations is compensated by the detailed functional description.

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 concise and well-structured: it front-loads the core output (balance, activity), then lists supported address types, and ends with usage guidelines and a note. Every sentence serves a purpose, providing valuable details without unnecessary verbosity.

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 description is complete for a single-parameter query tool. It covers the output fields, address formats, and usage guidance. Since there is no output schema, the description adequately explains what the agent can expect. The only minor gap is the lack of explicit mention of error conditions or rate limits, but overall it is sufficiently comprehensive for correct use.

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 address parameter in the schema is minimally described as 'Bitcoin mainnet address', but the description enriches it by listing supported address types (P2PKH, P2SH, bech32, bech32m). Since schema coverage is 100% for the parameter's existence, the description adds value by clarifying the expected format, which is not fully covered in 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?

The description clearly states the tool's purpose: it provides balance and activity information for a Bitcoin address, listing specific data points like confirmed/unconfirmed balance, UTXO count, and transaction count. It distinguishes itself from sibling tools by focusing on address-specific data, whereas siblings like btc_block_summary and btc_tx_lookup cover blocks and transactions.

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 includes a 'When to use' section that explains the scenarios for using this tool, such as checking balance, fund receipt, or activity level. It does not explicitly mention alternatives or when not to use it, but for a single-address summary tool, the usage context is clear and sufficient.

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 present, the description takes on the burden. It discloses the important behavior that omitting parameters returns the current chain tip and that the result is a summary with specific fields. It does not cover edge cases such as invalid heights or both parameters being provided, so behavioral transparency is adequate 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?

The description is two sentences, front-loaded with the tool's output contents and immediately followed by usage guidance. Every phrase — fields returned, current-tip default, and when-to-use — carries meaning with no filler or repetition.

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 tool with two optional parameters and no output schema, the description covers the key facts: what fields are returned, how to get the latest block, and how to target a specific height or hash. It lacks an explicit indication of the exact JSON shape or error behavior, but the listed fields give an agent sufficient understanding to invoke it.

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 each parameter (height, blockhash) is already documented in the schema with types and optionality. The description reinforces that parameters are optional and that height or block hash can select a block, but adds no new semantic details 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?

The description identifies the resource as Bitcoin block summaries and explicitly lists the returned fields (tx count, size, weight, block time, confirmations), making the tool's purpose clear. It is distinct from sibling tools like btc_tx_lookup and btc_mempool_summary by focusing on block-level summary data. However, it lacks an explicit action verb, so it stops short of a top score.

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 includes a dedicated 'When to use' clause: querying how many transactions the latest block holds, or getting an overview at a given height or block hash. This gives clear contexts for invocation, though it does not specify when not to use the tool or name alternatives, so it earns 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.

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 does convey that this is a read-style lookup returning fee rates, but it does not explicitly state side-effect-free behavior, data freshness, or how the result is returned. For a zero-parameter read tool this is acceptable but not rich.

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 two sentences with no filler. The core output is front-loaded first, and the usage guidance with the alternative is compactly placed in the second sentence.

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 no parameters and no output schema, so the description must explain the returned information; it does list the target intervals and the minimum fee, though it does not specify the exact response shape (e.g., JSON key names). That is a minor gap for such a simple no-arg lookup.

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 are zero parameters, so the baseline is 4; there is nothing the description needs to add about arguments. The description focuses on what the tool returns rather than parameters, which is appropriate here.

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 ('Recommended Bitcoin fees') and specifies exact confirmation targets (1/2/3/6/12/24-block) plus the mempool minimum fee. It clearly distinguishes this tool from btc_mempool_summary by stating the non-overlap, so an agent can tell them apart.

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 says when to use the tool ('how much fee to pay, or what gets a fast confirmation') and explicitly says when not to use it ('overall congestion level'), naming the alternative btc_mempool_summary. This is ideal guidance.

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 provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns (counts, fees, capacity) and implies it is a read-only operation. It does not detail the output format or whether the data is real-time or cached, but for an overview tool, this is acceptable. The description adds value beyond the schema by listing the exact metrics.

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 concise and well-structured. It front-loads the tool's purpose, lists the key data points, and then provides a usage guideline. Every sentence serves a purpose with no fluff or repetition.

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 tool has no parameters and no output schema, the description needs to cover what data is returned and when to use it. It does both effectively. It could mention the return format or data freshness, but for a simple overview tool, that is not critical. The description is complete for an agent to decide when to call it.

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 has 0 parameters)Skip, so there is no parameter documentation to cover. The description adequately explains what the tool reports, effectively serving as the semantic content for the 'empty' parameter set. Since there are no parameters, the description's role is to clarify the output, which it does.

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 provides a mempool overview with specific data points (pending tx count, bytes used, minimum fee, etc.). It distinguishes itself from related tools like btc_fee_estimates by focusing on the mempool's state rather than fee recommendations. However, it could more explicitly name sibling tools it is not, but the verb 'overview' and the resource 'mempool' are clear enough.

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 includes a 'When to use' clause that gives clear context: assessing network congestion and backlog size. It provides examples of the kind of questions it answers. However, it does not explicitly state when NOT to use it or mention alternatives like btc_fee_estimates for fee-specific queries, leaving some ambiguity for edge cases.

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 burden. It discloses that the tool handles both confirmed and unconfirmed transactions and returns a summary, which is useful. However, it does not disclose behavior like whether the txid must be lowercase, whether it queries a local node or external API, rate limits, or error behavior for unknown txids. The description is honest but not deeply transparent.

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, front-loaded with the core purpose and return fields, followed by a crisp usage rule and exclusion. Every sentence earns its place; no filler or repetition of schema 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?

For a single-parameter lookup tool with no output schema, the description covers the input format, the use case, and the sibling distinction. It could mention what happens for an unknown or invalid txid, but the schema pattern already enforces format, and the tool's scope is narrow. Slightly more behavioral detail would make it complete, but it is largely sufficient.

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%: the txid parameter is fully described in the schema with pattern and description. The description adds the context that the txid is a 64-hex BTC txid, but that's already in the schema. No additional parameter semantics are needed beyond what the schema provides, so 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 ('Look up') and resource ('Bitcoin transaction by txid'), and enumerates the exact data points returned (confirmation status, block height, confirmations, size, input/output summary). It also distinguishes itself from sibling tools by naming chain_status as the alternative for 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?

The description explicitly says when to use this tool: when the user gives a 64-hex BTC txid and asks whether it confirmed or which block it is in. It also gives a clear exclusion: do not use for other chains, use chain_status instead. This is explicit when/when-not guidance.

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 does disclose the shape of the returned telemetry (height, sync progress, peers, mempool count, version), which is valuable given there is no output schema, but it says nothing about freshness/latency characteristics, rate limits, or that the call is a side-effect-free read.

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 compact clauses: what it returns, when to use it, when not to use it and what to use instead. Front-loaded with the resource, zero filler, 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 single-enum read-only status tool with no output schema, the description supplies the missing return-field context and clean routing to alternatives. Its one gap is not clarifying how it relates to the per-chain eth_node_status and xmr_node_status tools that appear to overlap in scope.

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?

Only one parameter and the schema covers it at 100%, including the btc/eth/xmr/zec enum with its own description. The description adds no syntax or constraint detail beyond the schema, so the baseline 3 for fully-covered parameters 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 gives a precise verb+resource ('run-time status of one chain's node') and enumerates the returned signals (block height, sync progress, peers, mempool tx count, client version), making the purpose concrete. It differentiates against btc_fee_estimates, btc_address_summary and xmr_pool_status, but never mentions the overlapping eth_node_status and xmr_node_status siblings, which is the most likely source of mis-selection.

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 'When to use' (checking whether a chain's node is synced, healthy or lagging) and explicit 'Do not use' exclusions that route the agent to named alternatives for fees, address balance and Monero pool detail. Nothing about the selection decision is left to inference.

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 must carry the behavioral burden. It discloses data provenance (own Reth + Lighthouse nodes), the fact that provisioning status is a distinct transient state, and the returned fields. It stops short of explicitly stating this is a read-only, non-mutating call or noting any auth/rate-limit considerations, but the status-reporting semantics make safety unambiguous.

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?

Well front-loaded: the resource and returned fields come first, then clean 'When to use' / 'Do not use' clauses. Slightly dense due to the mid-sentence aside about provisioning, but every clause carries information and nothing is redundant.

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 must describe what is returned — and it does, listing sync state, height/head slot, peers, clients, and provisioning status. Combined with the explicit routing guidance, an agent has everything needed to call and interpret 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 no parameter semantics to document and the baseline is 4. The description correctly adds no unnecessary 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 resource (Ethereum node state) and enumerates exactly what it reports: sync state, height/head slot, peers, clients, and provisioning status. It also names the underlying implementations (Reth execution + Lighthouse consensus), making it clearly distinguishable from siblings like xmr_node_status or btc-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?

Explicitly provides a 'When to use' section (whether the ETH node is up/synced or what provisioning stage it is in) and a 'Do not use' section that routes PoW hashrate questions to the named alternative pow_network_mining_intel. Both the selection condition and the exclusion are stated outright.

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?

Although no annotations are provided, the description discloses key behavioral traits: BTC uses a node fee estimator, ZEC returns a protocol rule (ZIP-317 conventional fee), and chains without an estimator explicitly say so instead of guessing. This adds valuable transparency about the tool's behavior and limitations, which is beyond a simple read-only operation hint.

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 concise, front-loaded with the core purpose, and every sentence adds value. It efficiently covers the different chain behaviors and the usage trigger without redundancy. No wasted words.

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 tool with a single parameter and no output schema, the description is complete. It provides enough information for an agent to call it correctly: it knows the input chain, the expected output (fast/medium/slow plus mempool minimum), and how different chains behave. No critical gaps remain.

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 the 'chain' parameter with an enum and a description. The description adds value by explaining the meaning of the parameter in context: it determines the chain's fee estimation method (e.g., BTC's estimator vs. ZEC's protocol rule). With 100% schema coverage, the baseline is 3, but the description goes slightly beyond by clarifying chain-specific behavior.

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: providing fee recommendation tiers (fast/medium/slow plus mempool minimum) for a chain. It specifies the resource (fee rates) and the action (get/recommend), and distinguishes itself from siblings by noting the per-chain computation methods. It is clear what the tool does and how it differs from other fee-related tools like btc_fee_estimates.

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 the tool: when an autonomous agent is about to send a transaction and must pick a fee. It provides clear context but does not explicitly name alternative tools or state when not to use it, though the context is enough to guide selection among siblings like btc_fee_estimates.

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 discloses the payload shape (per-chain availability plus block height), which signals a read-only aggregate, but says nothing about freshness/latency, rate limits, or whether availability is cached — gaps that matter for a 'live' status 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 resource and scope, then usage, then the exclusion. Three tight sentences with zero filler, and the most decision-relevant information (what it lists and when not to use it) appears 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?

With no output schema, the description must convey the return shape, and it does so concisely (chains, availability, block height). It stops short of describing ordering, field naming, or how many chains appear if some are offline, which is a minor but real gap for a discovery 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, so there is nothing to document and the schema is trivially complete. Per the rubric baseline for a 0-param tool, 4 is appropriate; no parameter knowledge is missing.

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 ('Every chain this service supports') and enumerates the exact scope (BTC/ETH/XMR/ZEC) with the returned attributes (live availability, block height). It explicitly distinguishes itself from the sibling chain_status, so an agent can route without inspecting either schema.

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

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

Provides explicit when-to-use triggers (user asks which chains are supported, which nodes are online, chain heights) and an explicit when-not with the named alternative ('for detail on one chain, use chain_status'). No inference required.

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 must carry the behavioral load. It partially does so by revealing the returned dimensions (txs, bytes, usage vs capacity, min fee, total fees) and that a 'busy/normal verdict' is computed, which implies a read-only informational tool. It says nothing about permissions, freshness/refresh cadence, or failure modes.

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, front-loaded with the resource and followed by the usage trigger; the parenthetical metric list is dense but information-bearing. Minimal waste, though the parenthetical could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description is the only guidance available. It usefully enumerates the reported metrics, but omits the multi-chain behavior the schema supports and any indication of response shape or units, leaving gaps for a status 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?

Schema coverage is 100%, so the enum for 'chain' is already fully documented. The description actively narrows that scope by saying 'for BTC', which conflicts with the btc/ltc/doge enum and could lead an agent to believe non-BTC chains are unsupported, so it adds negative rather than neutral value here.

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?

It names a specific resource (mempool congestion) and lists the metrics it reports, so the general purpose is legible. However, it claims the tool is 'for BTC' while the schema accepts btc/ltc/doge, and it never distinguishes itself from the overlapping sibling btc_mempool_summary or btc_fee_estimates, leaving real ambiguity about scope.

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 'When to use: decide whether now is a good moment for an on-chain settlement' gives a concrete decision context, which is better than most definitions. It stops short of naming alternatives (btc_fee_estimates, get_recommended_fee_rate) or when-not to use it, so it does not reach the top band.

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 transparency burden. It discloses that heights are read live from own nodes, that schedules are protocol constants, and flags the DOGE flat-subsidy exception. It doesn't explicitly say 'read-only', but 'read live' and the nature of the data imply no side effects.

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, front-loaded with the main purpose and output fields, followed by use case and operational notes. Every sentence adds unique value; there is 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?

For a zero-parameter read-only tool with no output schema, the description covers the essential ground: output fields, live data source, protocol constants, and the DOGE edge case. An agent has enough to decide when to call it and what to 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 has zero parameters and the schema confirms an empty object. With no parameters to document, the description doesn't need to add parameter semantics; the baseline of 4 applies. The 'every chain' phrasing clarifies the result scope.

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 function: a halving countdown for every chain, with a list of returned fields (height, next halving height, blocks remaining, ETA, rewards). It is clearly distinct from sibling status/intel tools, though it lacks an explicit verb like 'gets' or 'returns'.

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 an explicit 'When to use' section: when an agent needs a precise schedule anchor for emissions, mining economics, or long-horizon planning. It gives clear context but does not name alternatives or exclusions, 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?

With no annotations, the description must carry the behavioral load, and it does disclose the key nuance: values are node-reported or difficulty-derived depending on chain, stated per chain, plus an explicit PoS caveat for ETH. It does not cover freshness, caching, or failure modes, so it falls short of fully transparent.

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 payload, then two clearly labeled routing clauses. Every sentence adds distinguishing information; there is 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 must signal what comes back; it names the metrics, the per-chain sourcing, and the ETH PoS note. It stops short of specifying units, formatting, or per-chain coverage limits, but the essential shape of the response is conveyed.

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 argument semantics to explain and the baseline is 4. Nothing in the description conflicts with or undermines the empty 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?

States specific metrics (network hashrate and difficulty) for three named chains, plus an ETH PoS caveat. It also explicitly distinguishes itself from pool-level siblings, so an agent can pick it out without inspecting schemas.

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?

Contains an explicit 'When to use' clause (mining economics, security budget, chain weight comparison) and a 'Do not use' clause routing pool-level queries to xmr_pool_status or robotbase_pool_worker_query. Both the positive and negative routing conditions are spelled out.

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 provided, the description carries the full behavioral burden. It discloses meaningful behavior beyond the schema: the address is masked in replies, only exact wallet/worker matches return data, and no listings are returned. It could mention error/empty behavior or prerequisites, but the privacy and match semantics are genuinely useful and specific.

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 deliver purpose, usage context, and privacy behavior with no filler. The most important action is front-loaded, and each 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?

There is no output schema, but the description lists the key return fields, so an agent understands what to expect. It covers required chain, optional lookup identifiers, exact-match behavior, and privacy. It could add detail about what happens when no match is found, but the overall call context is sufficiently complete.

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 67%, with chain, wallet, and worker already described. The description adds valuable semantic nuance: the lookup is performed 'by wallet address or worker name' and requires an exact match, which clarifies how the optional parameters are interpreted. It does not fully specify formatting requirements but compensates well beyond the raw 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?

The description uses a specific verb and resource ('Look up one miner on our own hashports') and enumerates the returned data (hashrate, shares, stale/invalid, difficulty, last-seen). It clearly identifies the lookup key (wallet address or worker name), making the tool's purpose unambiguous and distinct from generic pool or blockchain status 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 includes an explicit usage trigger: 'a miner asks their agent how is my rig doing on robotbase?'. It also clarifies the exact-match/no-listing constraint, which prevents misuse for enumeration. It does not name alternative tools explicitly, but no direct sibling appears to compete with this specific 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 supplied, the description carries the full burden. It discloses the scope ('every service') and the live/availability nature, but does not describe the return shape, how 'down' is reported, or any aggregation behavior. For a simple read-only status tool this is adequate but not rich.

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 with no filler. The primary purpose is front-loaded, followed by a scoped list of what's covered and then the usage guidance. 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 zero-parameter health-check tool with no output schema, the description covers what it does and when to use it. The only missing element is a note about return format, but the 'which services are down' phrasing implies a status list, so this is a minor gap.

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 baseline is 4. No parameter documentation is needed, and the description does not need to compensate for any schema gaps because there are none.

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-resource pair ('Live availability of every service behind the RobotBase gateway') and enumerates the covered services (chain nodes, hashport engines, Web3 Agent Hub, AITOKENS, MCP itself). This clearly distinguishes it from sibling per-chain status tools like kas_node_status or 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 explicitly states 'When to use: an overall health check, or which services are down,' giving the agent clear selection criteria. It doesn't explicitly name alternatives or say when not to use it, but the use-case framing is sufficient for a zero-parameter global health check.

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 burden — and it does disclose the returned signals (sync flag, height vs target, peer counts, versions), which is the key behavioral information for a read-only status probe with no output schema. It omits any note on auth, rate limits, or caching, so it is not fully complete.

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 resource and reported fields, then two labelled clauses ('When to use', 'Do not use'). Dense but every clause earns its place, and the escalation path is stated in a single sentence.

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 parameterless read-only status tool with no output schema and no annotations, the description supplies both the content of the return (the enumerated fields) and the selection guidance against its nearest sibling. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; baseline is 4. The description correctly implies a no-argument call.

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 resource (Monero node state) and enumerates exactly what it reports: height vs target, sync flag, difficulty, txpool size, database size, monerod version, peer counts. It also names the sibling it is not (xmr_pool_status), so an agent can distinguish it from adjacent tools 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?

Explicit 'When to use' (checking whether the XMR node is synced/healthy, or how large chain/txpool is) and an explicit 'Do not use' routing the mining/p2pool case to xmr_pool_status. Both the positive and negative conditions are stated.

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 discloses the scope of the returned dataset (both sidechains, node workers, fee, non-custodial flag) which is the key behavioral trait. 'Status' implies a read-only, non-mutating call, but it never states this explicitly nor mentions latency, data freshness, or auth needs, so it falls just short of full disclosure.

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 resource and its scope, then the use/avoid routing, so the agent gets the decision-relevant information first. The field enumeration is dense but each item is informative; the only minor cost is the long single clause listing returned values.

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, so the description must communicate what comes back, and it does so by enumerating the per-sidechain metrics, node workers, fee, and flag. Combined with the sibling routing, an agent has everything needed to 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, which is the baseline-4 case; there is nothing to document and the description correctly implies a no-argument status call rather than listing any options.

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 resource (Monero p2pool mini+nano sidechains plus network state) and enumerates exactly what it exposes: per-sidechain hashrate, miners, height/difficulty, blocks found, last block age, workers, fee, and the non-custodial flag. It also names the sibling it is not (xmr_node_status), so an agent can distinguish them without opening schemas.

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' triggers (solo/p2pool mining economics, sidechain health, picking a stratum endpoint) and an explicit 'Do not use' routing plain node RPC state to xmr_node_status. Both the positive and negative conditions are stated, leaving nothing to inference.

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 does well: it discloses that the tool applies no third-party pool label list, states the block range, and clarifies the output categories. It does not mention failure modes, data freshness, or exact units, but for a read-only chain-intel tool the disclosed scope is sufficient.

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 dense but well-organized: the core output is front-loaded, followed by a clear 'When to use' section and a 'Scope' close. Splitting the long first sentence would improve readability, but there is no wasted or redundant content.

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 tool with one parameter, no output schema, and no annotations, the description covers what the tool returns, when to use it, and its self-imposed scope. It is complete enough for an agent to select and invoke it correctly; only a small gap remains around how values are represented (e.g., percentages vs raw ZEC).

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 only one parameter and the schema already describes it fully ('How many recent blocks to classify (default 200)' with min/max). The description's 'last 10-500 blocks' only reinforces the schema, adding no new semantic information, 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 names a specific resource ('Zcash coinbase attribution') and precisely lists the outputs: shielded-pool share, consensus funding vs miner payout split, and miner-embedded pool tags including the /RobotBase/ tag. The scope line distinguishes it from any third-party-label tool and from sibling tools like zec_shielded_pools_metrics.

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 includes an explicit 'When to use' clause naming three concrete scenarios: privacy-pool mining trends, shielded adoption, and checking whether our own pool found blocks. It does not name alternative sibling tools or exclusion conditions, so it falls just 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?

With no annotations, the description carries the burden of behavioral disclosure. It clarifies the network scope (mainnet), the data category (six value pools), and the conceptual domain (shielded-pool state). However, it does not mention output shape, freshness, units, or any operational caveats.

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 front-loaded with the core purpose and then provides concise usage guidance. The parenthetical list of six pools is somewhat dense but directly helps an agent understand the exact scope.

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 info tool with no output schema, the description covers the key facts: network, data scope, and when to choose this tool over siblings. It falls just short of a 5 because it omits any indication of what the returned data structure looks like, though the supply listing implies the main content.

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 and the schema is empty, so there is nothing to document. Description-based parameter semantics are not needed; the baseline of 4 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?

The description names a specific verb/resource ('Zcash mainnet info including the supply of all six value pools') and clearly identifies the subject as shielded-pool state. It also distinguishes itself from a related sibling (chain_status) by explicitly saying what it is not for.

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 explicitly states when to use this tool ('how much ZEC sits in the shielded/sapling/orchard pools') and when not to use it ('whether the ZEC node is synced'), routing the agent to chain_status(zec) as the alternative. This leaves no ambiguity about selection.

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 provided, the description carries the behavioral burden. It discloses the data scope (most recent N blocks, N ≤ 20) and the diagnostic purpose. It does not mention response ordering or error behavior, but this is a simple read-only query with minimal risk.

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 with no filler. The first sentence front-loads the returned fields and cap, and the second provides a relevant use case.

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 no output schema, the description names the return fields and the intended use case. It does not explicitly state the response shape as a list of block objects, but 'most recent N blocks' strongly implies it.

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 schema already documents n with default, minimum, maximum, and a description. The tool description restates the N ≤ 20 cap but adds no meaningful semantic detail beyond 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?

The description clearly identifies the resource (recent Zcash blocks) and the returned fields (height, hash, block time, difficulty). It is unambiguous and distinguishable from the Zcash chain info sibling, though it lacks an explicit action verb like 'returns' or 'lists'.

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?

An explicit 'When to use' clause states the use case: checking whether ZEC is producing blocks normally and at what interval. It does not mention alternatives or when not to use it, but the 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?

No annotations are provided, so the description carries the full disclosure burden. It transparently describes the data scope and metric shape, making it clear this is a read-only metrics snapshot. It doesn't mention data freshness, computation basis, or response formatting, which prevents a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences: the first front-loads the resource and metrics, the second gives concise when-to-use and when-not-to-use guidance. Every clause 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 tool with no output schema and no annotations, the description adequately covers pool scope, metric names, use cases, and an exclusion. Minor details such as units or return structure are absent, but they are not necessary 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?

The tool has zero parameters and the schema coverage is 100%, so there is no parameter burden for the description. The zero-parameter baseline applies here, and the description correctly focuses on the returned data rather than inputs.

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—all six Zcash value pools by name—and the exact metrics returned: balances, share of supply, and 1h/24h deltas. This differentiates it from generic chain or block tools and leaves no ambiguity about what the tool covers.

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 explicitly provides when-to-use contexts (privacy-pool capital allocation, shielded-supply trends, ZEC macro flows) and a direct do-not-use case with a named alternative, chain_status(zec). This gives an agent clear routing logic without needing to inspect siblings.

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