THORChain MCP

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

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds useful context (a non-destructive pre-flight check that reports availability for registration) but does not explain the return shape or error behavior beyond the availability notion.

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

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

Two tight sentences with no waste, and the purpose (pre-flight check) is front-loaded ahead of the return-value detail.

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

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

There is no output schema, and the description does partially compensate by describing the two pieces of returned information. However, jargon like 'memoless transactions' and 'registration' is left undefined, leaving an agent without full grounding for a tool with 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 100%, so the schema documents both 'asset' and 'amount' fully. The description references 'the amount' but adds no format or syntactic detail beyond what the schema provides, so 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: a 'pre-flight check' that returns 'what reference would be extracted from the amount and whether it's available for registration.' This is clearer than a generic 'check', though it doesn't explicitly differentiate itself from siblings get_reference_memo / get_reference_memo_by_hash.

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?

'Pre-flight check for memoless transactions' implies when to use it (before performing a memoless transaction), but there is no explicit when-to-use/when-not or naming of alternatives such as get_reference_memo. Usage must be inferred from the phrase 'pre-flight.'

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds the content scope ('including fees collected by thorname'), which is useful, but says nothing about auth needs, aggregation window, or why the call is non-idempotent despite being a 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?

A single front-loaded sentence with no filler. It is appropriately sized, though its brevity comes at the cost of the routing information a zero-param tool with many siblings would benefit from.

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 explaining return values is not required, and the zero-param schema is trivial. Still, for a tool sitting among several near-identical affiliate endpoints, the description does not supply enough to confidently select it over its siblings.

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 the baseline is 4; there is no parameter semantics for the description to elaborate. The description does not misrepresent the (empty) input contract, though it also adds nothing about implicit scoping.

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 ('Returns') and resource ('affiliate earnings') plus a scope detail ('fees collected by thorname'), so the agent knows what the tool retrieves. However, it does not distinguish itself from the three sibling affiliate tools (get_affiliate_history, get_affiliate_stats, get_earnings_history), leaving ambiguity about which one to pick.

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 no when-to-use guidance, no prerequisites, and no explicit alternatives. With get_affiliate_history, get_affiliate_stats, and get_earnings_history as close siblings, the absence of any routing cue is a real gap.

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?

Annotations already declare readOnlyHint=true, so safety is covered; the description adds that results are time-series over an interval. However it does not disclose what happens with zero required params (default range/interval), pagination, or why idempotentHint=false despite being a read. Adds some value but leaves meaningful behavioral 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?

A single sentence with the resource and content front-loaded and zero filler. Nothing could be removed without losing 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 read-only history tool with full parameter documentation and no output schema, the description is minimally adequate: it says what is returned but not how defaults behave when no time window is supplied. It covers the essentials without filling the remaining ambiguity.

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 from/to/count/interval are fully documented in the schema itself. The description adds no syntax, unit, or default information beyond that, 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 ('Returns') and resource ('historical affiliate swap data'), plus the shape of the content (volumes and thorname breakdown over time). It is distinguishable from get_affiliate_stats and get_affiliate_earnings, though it never explicitly contrasts itself with those 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?

No when-to-use guidance, no conditions, and no mention of the obvious alternatives (get_affiliate_stats, get_affiliate_earnings, get_swap_history). The agent must infer from the name alone which of the several affiliate/history tools applies.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds the returned dimensions (volumes, counts, fees), which is useful context, but says nothing about auth requirements, scoping, or aggregation 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?

A single front-loaded sentence that names the resource and the returned fields with no filler or redundancy.

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

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

With no parameters and no output schema, the description carries the full descriptive burden, and while it names the returned dimensions it leaves the 'by thorname' scoping unexplained, which is the one thing an agent would need clarified 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 schema declares zero parameters, which normally sets a baseline of 4, but the phrase 'by thorname' implies a selectable/filtering key that no parameter actually supplies. That mismatch creates ambiguity about whether the tool is genuinely parameterless or implicitly scoped, so it falls just below baseline.

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 ('Returns affiliate statistics') and lists the returned content (volumes, counts, fees), which is more than a tautology. However it does not differentiate itself from sibling affiliate tools like get_affiliate_earnings and get_affiliate_history, so an agent cannot tell which affiliate endpoint to pick.

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?

There is no when-to-use guidance and no mention of alternatives, despite three closely related affiliate siblings (earnings, history). The agent is left to infer the distinction entirely on its own.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is conveyed. The description adds value by disclosing the shape of the result (status, block height, signers) since no output schema exists, but says nothing about how the idempotency flag or stale/absent ban records behave.

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 short sentences with the core purpose front-loaded. The closing sentence on why bans exist is mild domain color rather than a load-bearing instruction, but nothing is padded or repetitive.

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 with no output schema, the description compensates well by naming the fields an agent will receive. Only minor gaps remain around absent-ban responses and any permission or rate considerations.

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

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

Schema description coverage is 100%, so the single address parameter is fully documented in the schema, including the thor1... format. The description adds no syntax or constraint detail beyond that, making the baseline 3 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?

States a specific verb and resource ("Returns the ban status for a node address") and enumerates the returned fields (banned flag, block height, signers). It is clearly distinguishable in intent, though it never names or contrasts with sibling lookups like get_node or list_nodes.

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 explains what a ban is conceptually but never says when to reach for this tool versus related node lookups, nor any prerequisites. Usage must be inferred entirely from the name and domain knowledge.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds the 'verbose' nature and the latest-block default, but does not explain the non-idempotent behavior (likely because the latest block changes) or any response-size/rate considerations for a verbose payload.

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 sentences with the core purpose front-loaded and the default behavior following. Every sentence carries information; 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?

With no output schema, the description does carry the burden of describing return contents and does so reasonably (header, transactions, results, hash, chain ID, height, validator info). The main omission is sibling disambiguation against the other block tools.

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 description coverage, the schema already documents the optional height and its latest-block default. The description restates that default but adds no format, range, or edge-case semantics beyond the schema, 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 ('Returns verbose details of a THORChain block') and enumerates the contents (header info, transactions, block events, hash, chain ID, height, time, validator info). However, it never distinguishes itself from the many block-related siblings such as get_cometbft_block, get_cosmos_block, or get_lastblock, so an agent cannot tell which block tool to pick from the description alone.

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 one useful usage cue: 'If no height is specified, returns the latest block.' But there is no guidance on when to prefer this over get_cometbft_block, get_cosmos_block, or get_lastblock, and no exclusions or prerequisites. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered without the description. The description does add value by enumerating what comes back (associated nodes and total bonded amount), but it never explains why idempotentHint=false (i.e., that bond state mutates over time) nor whether the response is scoped to a single network.

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, front-loaded with the verb and resource, with the returned fields appended. Nothing is wasted, though it is close to the minimum viable length and leaves no room for scoping detail.

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

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

For a one-parameter read tool with annotations covering safety and no output schema, the description is adequate: it tells the agent what is returned. It leaves open the network/chain context, freshness of the bond data, and how 'associated nodes' is bounded.

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 parameter with 100% schema description coverage, so the schema already carries the semantics and the baseline is 3. The description adds nothing about the address format (e.g., THORChain vs other chain addresses) or any validation constraints.

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 ('Returns bond details for an address') plus the payload contents (associated nodes, total bonded amount), which is concrete rather than tautological. It does not, however, distinguish itself from adjacent node/account tools such as get_node or get_midgard_nodes that also surface bond-related data.

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

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

The description gives no indication of when to reach for this tool versus the many sibling lookup tools, and names no alternative. The only implied usage is 'you have an address and want bond info', which is inferred rather than 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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the agent knows this is a safe, non-idempotent read. The description adds return-content context ('with dates and block heights') but does not disclose behavioral traits such as pagination, ordering, rate limits, or authentication needs. With annotations covering the safety profile, this is adequate but minimal.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the action and the returned data. Nothing is superfluous.

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 low-complexity, zero-parameter, read-only endpoint with no output schema, the description gives enough to understand the return content: churn event history with dates and block heights. It does not cover ordering, pagination, or the exact shape of a churn event, but those omissions are minor given the tool's simplicity.

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 are no parameter semantics to document. Per the rubric, a zero-parameter schema earns a baseline of 4. The description does not need to compensate for missing parameter details.

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 ('Returns') and resource ('churn event history') and adds the key returned fields (dates and block heights). It is clear and not tautological. No sibling tool covers churn events, so explicit differentiation is unnecessary, but the description could still be more precise about what a churn event represents.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only says what it returns, leaving the agent to infer that it is the appropriate call whenever churn history is needed. For a simple getter this is somewhat obvious, but the definition provides no explicit usage context.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the non-idempotent hint is consistent with height=0 returning the latest block. The description adds the payload composition, but does not disclose anything about the 'canonical blockchain data' claim vs. siblings or about response size/pagination for blocks with many transactions.

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, no redundancy, with the core return contract front-loaded. The trailing sentence ('Provides canonical blockchain data') is mild filler that doesn't carry actionable 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?

With no output schema, the description does the minimum by naming the returned fields (header, transactions, commit signatures) and the caller can infer the height semantics from the schema. It is incomplete on the key differentiator for this tool set: how this differs from get_cometbft_block_results, get_cosmos_block, and get_block.

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 height parameter, including the 'omitted or 0 returns latest' default, is fully documented in the schema. The description repeats the height scoping but adds no format, range, or error semantics beyond it, so 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 gives a specific verb and resource ('Returns block data at the specified height') and enumerates the payload contents (header, transactions, commit signatures). It fails to distinguish itself from close siblings such as get_cometbft_block_results, get_cosmos_block, or get_block, which is a real ambiguity in this tool set.

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?

There is no when-to-use guidance and no mention of alternatives, despite the presence of several near-identical block retrieval siblings. The only routing hint is the parameter's own default behavior, which the schema already states.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds that results include ABCI events and validator updates, which is useful return-content context, but it does not explain why the operation is non-idempotent (e.g., latest-block behavior when height is omitted) or cover auth/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 concise sentences with zero waste. The core purpose and included data are front-loaded, followed by a brief 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?

Given the simple one-parameter schema, read-only annotation, and absence of an output schema, the description provides enough to call the tool and understand roughly what it returns. It could be improved by distinguishing it from related block/transaction tools, but it is nearly complete for this tool's 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?

Schema coverage is 100% and the single 'height' parameter is fully described in the schema. The description does not mention the parameter at all, so it adds no meaning beyond the schema; 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 clear verb ('Returns') and resource ('results of executing transactions in a block') and specifies included data (ABCI events, validator updates). It does not explicitly differentiate itself from sibling tools like get_cometbft_block or get_cometbft_tx, preventing 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 phrase 'Useful for inspecting transaction outcomes' implies a use case but gives no explicit guidance on when to prefer this over alternatives such as get_cometbft_block, get_cometbft_tx, or search_cometbft_tx. No exclusions or prerequisites are mentioned.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds only that it returns parameters at a height, without details on caching, permissions, or response shape; it is consistent with annotations but adds limited behavioral context.

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

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

A single front-loaded sentence with no filler. It efficiently states what is returned and at what 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 simple read-only getter with one optional parameter and no output schema, the description is nearly complete: it names the resource and key return fields, and annotations cover safety. The only minor gap is lack of explicit sibling differentiation.

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 description fully documents the height parameter, including the 0/omitted-for-latest behavior. The description mentions 'at a height' but adds no syntax or semantics beyond the schema, 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: returns CometBFT consensus parameters. It also names the key parameter groups (block size, evidence, validator params), which helps distinguish it from siblings like get_cometbft_consensus_state, but it does not explicitly contrast with that sibling.

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

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

The description gives no when-to-use guidance or alternative routing. It implies the tool is for inspecting consensus parameters at a given height, but an agent must infer when to choose it over get_cometbft_consensus_state or other CometBFT tools.

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 annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. The description adds useful behavioral context by naming the returned consensus fields and framing the tool around debugging, though it does not describe freshness or whether the snapshot is node-local versus network-wide. No contradiction with annotations.

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

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

Two sentences, zero waste, and the return content is front-loaded before the debugging-use sentence. It is appropriately sized for a zero-parameter read tool.

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 carry return-value explanation; it lists the key fields but leaves "vote information" somewhat vague and does not mention range or freshness. Still, for a zero-parameter read-only tool, it gives enough to call safely and interpret the core result.

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 are no parameter semantics to explain. Baseline is 4, and the description correctly does not introduce unnecessary parameter detail.

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 ("Returns") and resource ("current consensus round state") and enumerates the main fields it contains: height/round/step, proposal block hash, and vote information. It is clear, but it does not explicitly distinguish itself from nearby siblings such as get_cometbft_status or get_cometbft_consensus_params.

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 phrase "Useful for debugging consensus issues" gives an implied use case, but it provides no explicit when-not guidance and does not name alternatives such as get_cometbft_status. The agent must infer the selection criteria from sibling names.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds useful content detail about what the response includes, but it does not add behavioral context such as return format, freshness, or how peer details are represented.

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

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

It is two tight sentences with the return contents front-loaded and a brief usage note second. There is no filler and no repetition of the tool name.

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 no-parameter read with no output schema, the description gives sufficient context by naming the main fields returned. It could be more complete by specifying the response shape or whether peer details include addresses, but nothing critical is missing for 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 there are no parameter semantics for the description to explain. The baseline for a no-parameter tool is 4, and the description introduces no misleading parameter expectations.

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 specific verb and resource: 'Returns network information' and then names the key contents (listening status, connected peers, peer details). It is clear what the tool does, but it does not distinguish itself from closely named siblings such as get_cometbft_status or get_network_info.

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 phrase 'Useful for monitoring P2P network health' implies a usage context, but there is no explicit guidance on when to choose this tool over alternatives and no exclusions. The agent is left to infer when this is preferable to get_cometbft_status or get_network_info.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds that the response bundles node info, sync status, and validator data, which is useful behavioral context, but says nothing about freshness, latency, or why idempotentHint is false for a status 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?

Two sentences, front-loaded with the return content, and no filler. Every clause carries information an agent can use.

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 names the top-level sections returned (node info, sync status, validator information). That is adequate for a no-parameter read tool, though it stops short of describing the shape or any nested fields.

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 the baseline is 4. There is nothing for the description to document, and the schema is trivially complete at 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Returns') and resource ('CometBFT node status') and enumerates the payload (node info, sync status, validator information), so the purpose is legible. However, it offers no differentiation from close siblings like get_cometbft_net_info, get_cometbft_consensus_state, and get_cometbft_validators, whose content it partly overlaps.

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?

There is no when-to-use guidance, no stated conditions, and no pointer to an alternative tool. The clause 'canonical consensus-level data' faintly implies authority but never tells an agent when to pick this over the other cometbft endpoints.

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?

Annotations already establish readOnlyHint=true, so the safe-read profile is covered. The description usefully discloses the return contents (result, height, proof), which matters because there is no output schema, but it says nothing about errors, missing-hash behavior, or the odd idempotentHint=false setting. 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 sentences, front-loaded with the core action and no filler. It is efficient, though the second sentence ('canonical transaction data from the consensus layer') is largely a restatement of the 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 read-only lookup with no output schema, the description compensates by naming what is returned and noting the proof is optional. The remaining gap is routing context against the many sibling transaction tools, which the description does not address.

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 both parameters are already documented in the schema, including the 'without 0x prefix' constraint and the prove flag. The description only restates 'by its hash' and 'optional proof of inclusion,' adding no format or default 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 gives a specific verb and resource ('Returns a transaction by its hash') and enumerates the payload (tx result, height, optional proof), so the purpose is unambiguous. However, in a namespace that also exposes get_cosmos_tx, get_tx, get_tx_details, and search_cometbft_tx, it never states how it differs from those siblings, so sibling differentiation is only weakly implied by 'from the consensus layer.'

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?

There is no when-to-use, when-not-to-use, or alternative-selection guidance. With this many overlapping transaction tools available, the agent is left to guess why it should call get_cometbft_tx rather than get_cosmos_tx or search_cometbft_tx.

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 readOnlyHint annotation already establishes this as a safe read operation. The description adds useful semantic context by calling the data 'canonical consensus data about who can produce blocks,' but it does not mention pagination behavior or any response-shape details beyond the listed fields.

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 tightly written sentences with no wasted text. The core purpose is front-loaded, followed by a concise explanation of the data's significance.

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

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

For a read-only, three-parameter tool with fully described schema fields and annotations, the description is mostly complete. It explains the return content well enough despite no output schema, though it could mention pagination or default behavior when height is omitted.

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

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

Schema description coverage is 100%, so the schema fully documents page, height, and per_page. The description mentions the specified height and returned validator fields but adds no syntax or format details beyond what the schema already provides, making the baseline 3 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 verb and resource (returns the CometBFT validator set) and lists the returned fields (addresses, public keys, voting power). It is clear what the tool does, but it does not explicitly differentiate this from the sibling get_cosmos_validators tool.

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 no guidance on when to use this tool versus alternatives such as get_cosmos_validators or get_cometbft_consensus_state. It also does not state when a height should be supplied versus omitted, leaving usage 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?

Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description contributes the useful detail that values include int/bool/string configuration constants governing protocol behavior, but says nothing about caching, refresh cadence, or whether constants can change mid-epoch across an upgrade cycle.

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 with no filler or repetition of the tool name. It is efficient, though the trailing clause about value types could be tightened if brevity were the only goal.

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, no-output-schema read endpoint, the description carries the essential shape of the response (integer/boolean/string configuration values). Nothing critical is missing, though noting the absence of filtering or pagination would close the loop.

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 for the description to disambiguate; baseline 4 applies. The description correctly implies a single unfiltered snapshot of all constants rather than a targeted lookup.

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 ('Returns') and resource ('protocol constants') and enumerates the value types (integer, boolean, string), so the agent knows exactly what it gets back. It doesn't differentiate from nearby config-ish siblings like get_mimir or get_version, but the resource is concrete enough to be selectable.

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?

There is no when-to-use guidance, no statement of what this replaces, and no mention of the alternative config endpoints (get_mimir, get_network_info) in a very large sibling set. The agent must infer usage purely from the resource name.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds one behavioral nuance, that the public key is returned only 'if available', which is useful. It does not address return format, error behavior, or why a read would be non-idempotent.

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 efficient sentence with the resource and return contents front-loaded and zero filler. Slightly terse given it could carry more context, but nothing is wasted.

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 partly compensates by naming the returned fields (account number, sequence, public key). For a simple single-param read tool this is nearly complete, with only the conditional 'if available' nuance left underspecified.

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

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

Schema description coverage is 100%, so the single 'address' parameter and its format hint (thor1...) are already documented. The description repeats 'THORChain address' without adding format, validation, or edge-case detail 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+resource ('Returns account information for a THORChain address') and enumerates the key return fields (account number, sequence/nonce, public key). This distinguishes it in content from siblings like get_cosmos_balances or get_cosmos_tx, though it does not name any sibling explicitly.

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

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

No explicit when-to-use, when-not-to-use, or alternative routing is given. The usage is implied by the purpose (fetch on-chain account state for a given address), but an agent must infer when this is preferable to get_cosmos_balances, get_trade_account, or get_thorname_owner.

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?

Annotations already declare readOnlyHint=true, and the description adds useful return context ('all coin denominations held'). However, it does not address that idempotentHint=false, i.e. that repeated calls may yield different balances as the chain advances, nor any caching or freshness behavior. With annotations carrying the safety profile, this is an adequate but not rich 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?

Two tight sentences with the core action front-loaded and no padding. The second sentence slightly restates the first's scope, keeping it just short of a 5.

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 output schema, the description gives a minimal picture of the return (coin denominations) but omits return shape, whether balances are per-block, and how it differs from get_cosmos_account. Adequate but with clear gaps.

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

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

Schema coverage is 100% and the single 'address' parameter is already documented in the schema with the thor1... format hint. The description adds no syntax or format detail beyond the schema, so 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 ('Returns account balances for a THORChain address') and clarifies the scope ('all coin denominations held by the account'). It is clear what it does, but it does not distinguish itself from near siblings like get_cosmos_account or get_midgard_balance, so an agent cannot route between them from the text alone.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling balance/account tools. The agent must infer usage entirely from the name.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds useful payload context (header, transactions, commit data) — the only source of return-shape info since no output schema exists — but says nothing about error behavior for unknown heights or the potentially heavy response size.

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 the resource and return contents front-loaded and zero filler. Nothing could be removed without losing 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 simple single-parameter getter, the description covers purpose, input, and the composition of the returned block, and annotations cover the safety profile. The one meaningful gap is that it does not help the agent choose among the several block-related siblings.

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 schema description coverage is 100%, so the schema already explains 'height'. The description merely restates 'at the specified height' and adds no format, range, or validation detail. Baseline 3 applies when the schema does the work.

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 ('Returns a block at the specified height') and scopes it to the Cosmos SDK blockchain, which is clear enough to act on. However, it never distinguishes itself from the many block-reading siblings such as get_block, get_cometbft_block, or get_cosmos_latest_block, leaving the agent to guess which 'block' tool is the right one.

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?

There is no when-to-use guidance, no exclusions, and no named alternative. Given siblings like get_block, get_cometbft_block, and get_cosmos_latest_block, the absence of routing guidance is a real gap rather than a minor omission.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety is covered. With no output schema, the description does add some value by sketching the return shape (validator targets plus amounts) and that the result is unrestricted ('all delegations'), but it says nothing about pagination, ordering, or behavior for an address with no delegations.

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 action and resource, with the return summary immediately after. No filler and nothing repeated from the title 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 one-parameter read tool this is close to sufficient, and it partially compensates for the missing output schema by naming what is returned. However, it omits the denomination of amounts, the validator identifier format, and the empty-result case, leaving a real gap given there is no output schema to fall back on.

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 already documents itself as 'Delegator address (thor1...)'. The description implies the parameter is the delegator but adds no format, validation, or edge-case detail beyond the schema, so 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 ('Returns all delegations for a delegator address') and the second sentence clarifies the scope of what comes back (validators plus amounts), which helps separate it from balance/reward siblings. It stops short of naming an explicit alternative such as get_cosmos_rewards, so it is clear but not fully differentiated.

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?

There is no guidance on when to reach for this tool versus get_cosmos_rewards, get_cosmos_balances, or get_cosmos_validators, and no note that the input must be a thor1... address in the caller's expected form. The agent must infer usage from the name alone.

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?

Annotations already provide readOnlyHint=true and idempotentHint=false, and the description helpfully enumerates the returned payload (header, transactions, commit data). It does not, however, explain the non-idempotent behavior implied by 'latest' or any size/pagination considerations, so it adds only modest value beyond the annotations.

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

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

A single front-loaded sentence with no filler, stating what is returned and its constituent parts. 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?

There is no output schema, so the description carries the burden of describing return content, which it does by listing header, transactions, and commit data. It falls short only in not addressing divergence from siblings or output sizing, which for a zero-parameter read is minor.

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 the baseline is 4. The description correctly implies no inputs are required simply by describing a no-argument latest-block fetch.

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 (Returns) and resource (the latest block from the Cosmos SDK blockchain) plus the returned payload. However, it does not differentiate from the many sibling block-retrieval tools (get_block, get_cosmos_block, get_cometbft_block, get_lastblock), leaving the agent to infer that 'latest' is the distinguishing 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?

No when-to-use or when-not-to-use guidance is given. With siblings like get_cosmos_block, get_block, and get_lastblock all plausibly overlapping, the description never states whether to pick this one for the most recent block versus a height-parameterized alternative.

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 annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered by structured data. The description adds one piece of context beyond that — that data comes from the gRPC-gateway REST API and is 'canonical' — but it does not explain the odd non-idempotent hint for a pure info fetch, nor any latency, caching, or failure 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?

Two sentences, front-loaded with the core purpose; nothing is redundant or padded. The trailing sentence about the gRPC-gateway REST API is only marginally useful for tool selection, keeping it just short of a perfect score.

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 carries the burden of describing returns, and it does list the returned fields, which is adequate. But against a large sibling set with several near-duplicate node/network/version tools, it lacks the differentiation an agent needs to select 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 (schema coverage 100% by default), so per the rubric this is a baseline 4. There are no inputs whose semantics the description would need to clarify.

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 ('Returns Cosmos SDK node information') and enumerates the returned fields (network, version, protocol versions, application version), so the purpose is unambiguous. However, it makes no attempt to distinguish itself from close siblings such as get_node, get_network_info, get_version, or get_cometbft_status, which an agent could easily confuse it with.

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?

There is no guidance at all on when to call this tool versus the several sibling tools that return overlapping network/version/node data. No prerequisites, no exclusions, no alternatives are mentioned; the agent must infer usage entirely.

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?

Annotations already declare this is a read-only, non-idempotent operation, so the safety profile is covered. The description adds genuine value by disclosing the return structure (per-validator rewards plus a total), but says nothing about auth requirements, pagination, or why the result is non-idempotent (rewards accrue over time).

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 purpose and followed by the concrete return content. No filler, 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?

With no output schema, the description usefully compensates by summarizing the response shape (per-validator and total rewards). For a simple single-parameter read tool this is nearly complete; only guidance on downstream usage or edge cases (e.g. no delegations) is absent.

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

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

Schema coverage is 100% and the single parameter already carries its own description ('Delegator address (thor1...)'), including the address format. The description only restates the delegator concept, adding no syntax or format detail beyond the schema, so 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 gives a specific verb+resource: 'Returns delegation rewards for a delegator address,' and the second sentence clarifies the content (per-validator plus total). It is clearly distinct from siblings like get_cosmos_delegations or get_cosmos_balances, though it never names a sibling to reinforce the boundary.

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?

There is no when-to-use guidance, no prerequisites (e.g. the delegator must have an existing delegation), and no mention of alternatives such as get_cosmos_delegations. Usage is only implied by the single-parameter signature.

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 annotations already declare readOnlyHint=true, and the description adds no behavioral detail beyond saying it returns supply information. It does not clarify snapshot behavior, freshness, or why idempotentHint is false, so it adds little context beyond the structured safety hints.

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 definition is two concise sentences, front-loaded with the primary purpose and followed by output-oriented detail. There is no filler or redundant explanation.

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 explains that the response covers total supply across denominations and circulating supply for RUNE and other tokens. It is nearly complete for a simple read-only query, though the distinction between total and circulating supply could be sharper.

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 no parameters, so there is no parameter semantics to explain. A baseline score of 4 is appropriate for a zero-parameter tool whose schema is complete by omission.

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: it returns total token supply, including all coin denominations, and mentions circulating supply for RUNE and other tokens. This is clear enough to distinguish it from balance or holder queries, though it does not explicitly name a sibling alternative.

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

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

The description does not state when to use this tool versus alternatives such as get_cosmos_balances or get_holders. Usage is only implied by the stated return content, with no exclusions or routing 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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the warning that a syncing node returns stale data, which tells the agent how to interpret the result. It stops short of describing the return shape (boolean vs status object).

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 zero filler; the core action is front-loaded and the interpretive caveat follows immediately. 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 read-only status check with no output schema, the description supplies enough to call and interpret it: what it returns and why the result matters. Only the exact return representation (boolean vs. richer status) is left implicit, which is a minor gap given 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?

This tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. Per the rubric, 0 parameters sets a baseline of 4, and no meaningful parameter detail 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 ('Returns whether') and a precise resource/condition ('the node is currently syncing with the blockchain'), so the agent knows exactly what boolean question is being answered. It is distinguishable from siblings like get_cosmos_node_info, though it never explicitly contrasts itself with them.

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 second sentence ('A syncing node may have stale data') implies why an agent would call this before trusting other node data, which is useful implied usage. However, there is no explicit when-to-use rule, no named alternative, and no statement of when this check is unnecessary.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds what a caller gets back ('transaction body, auth info, and execution result'), which is real value since there is no output schema, but it omits failure behavior for an unknown hash and any response-size 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?

Two tight sentences with no filler, and the core operation is front-loaded. It could be marginally sharper by folding in the routing distinction, but nothing is wasted.

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 whose annotations carry the safety semantics, the description covers what is fetched and what comes back, which is the main gap left by the absent output schema. Only the not-found/error behavior is unaddressed.

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 description coverage, the schema already documents 'hash' fully. The description adds no syntax, format, or casing guidance beyond restating that lookup is by hash, so 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 ('Returns a transaction by hash') and identifies the source chain ('Cosmos SDK blockchain'), which partially separates it from get_cometbft_tx. However, it does not explicitly distinguish itself from the crowded tx siblings (get_tx, get_tx_details, search_cosmos_txs), leaving some differentiation to inference.

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 phrase 'by hash' implies a lookup requires a hash, but there is no stated when-to-use, when-not-to-use, or alternative routing among get_tx, get_cometbft_tx, get_tx_details, or search_cosmos_txs. In a sibling set this dense, that absence matters.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so safety and mutation behavior are partially covered. The description adds value by naming the returned fields, but it does not discuss ordering, pagination, state changes, or why a list operation is marked non-idempotent.

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 with no wasted words. The purpose is front-loaded, followed by a useful summary of returned fields.

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 helpfully names the main return fields. The single parameter is fully covered by the schema and annotations cover the read-only profile. Minor gaps remain around pagination, ordering, and total result size, but the definition is broadly complete for a simple list endpoint.

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 optional status parameter is fully documented in the schema, including allowed values and the empty/default behavior. The description does not add any parameter-specific meaning 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?

The description states a specific verb and resource: returns the list of staking validators. It also lists the main fields returned, making the purpose clear. However, it does not explicitly distinguish this from the sibling get_cometbft_validators tool, which an agent might otherwise confuse with staking validators.

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?

There is no explicit guidance on when to use this tool versus alternatives such as get_cometbft_validators. The usage is implied by the name and description, but no conditions, exclusions, or alternative routing are provided.

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 read-only framing is consistent with readOnlyHint=true, and the description usefully enumerates the returned data series, which matters since there is no output schema. It does not explain the implications of idempotentHint=false (results shift as new intervals accrue), nor pagination or interval defaults, so it adds only partial behavioral context.

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

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

A single front-loaded sentence with no filler, and the purpose plus the returned metrics lead the reader immediately. It could be slightly tighter, but nothing is wasted.

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?

Since no output schema exists, listing the returned data fields is genuinely useful and partly compensates. Still missing for a time-series tool: how from/to/count/interval interact, what happens when they are omitted, and how this differs from the sibling history tools.

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 all five parameters (asset, from, to, count, interval) are already documented in the schema, making the baseline 3. The description adds no syntax, default, or interaction detail beyond restating the returned data fields.

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 (historical depth data for a pool) and enumerates the metrics returned: asset depth, RUNE depth, asset price, liquidity units. However, it does not differentiate itself from closely named siblings like get_liquidity_history or get_rune_history, which an agent could easily confuse it with.

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

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

No when-to-use guidance, no exclusions, and no mention of the alternative history tools (get_liquidity_history, get_tvl_history, get_earnings_history) that overlap in scope. The agent must infer selection purely from the tool name.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context about what is returned ('depths and status'), which goes slightly beyond the annotations. It does not explain the curious idempotentHint=false on a read-only tool, nor any failure behavior for an unknown asset.

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 with no filler. It is appropriately sized; it earns its place, though it could add one clause about the identifier format without bloat.

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

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

For a simple one-parameter read tool with no output schema, the description gives enough to call it correctly. It states both the input target (one derived pool) and the returned data (depths and status). Minor gaps in routing guidance keep 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 coverage is 100% and the single 'asset' parameter is documented in the schema with an example (THOR.BTC). The description implies the identifier selects a specific derived pool but adds no format or validation detail beyond the schema, 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: 'Returns one derived (virtual) pool's depths and status.' The phrase 'one derived' implicitly distinguishes it from the sibling list_derived_pools, though it never names the alternative explicitly. An agent can identify the operation without opening the 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?

There is no explicit guidance on when to use this versus list_derived_pools or get_pool/get_pool_stats. Usage is only inferable from the singular 'one derived pool'. No prerequisites, exclusions, or alternatives are mentioned.

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 annotations provide safety hints (readOnlyHint), the description provides critical structural transparency by detailing every field returned (e.g., 'trading pair, current dynamic fee floor in basis points, whitelist state'). This compensates for the missing output schema and is highly useful for agent execution.

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 perfectly efficient. It front-loads the main function and then concisely lists all relevant data points returned in each entry, packing maximum information into minimal space.

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 that there is no defined output schema, the description is exceptionally complete. It thoroughly documents the structure, data types (basis points, TOR), and meaning of every piece of information the tool returns.

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 no input parameters, meaning the description cannot add parameter semantics. Since the baseline score for 0 parameters is high, and the description is clear in its purpose, a 4 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 is highly specific, stating it 'Returns per-THORName dynamic L1 minimum swap-fee floors (ADR-026).' This clearly identifies the verb, the resource, and the scope, immediately differentiating it from other financial retrieval 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 definition does not provide explicit guidance on when to use this tool versus alternatives. While its purpose is clear, the agent has no context on specific use cases or preconditions for invoking it.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description only restates the data content and adds no behavioral context such as defaults, pagination behavior, or why repeated calls are non-idempotent (e.g., time-window dependence).

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 that states the resource and its contents with no filler or redundancy. Nothing is wasted and the key 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?

There is no output schema and no required parameters, so the description should ideally explain return shape and default behavior (e.g., what a missing interval or range yields). It partially covers return content but leaves defaults and pagination unaddressed.

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 all four parameters (to, from, count, interval) are already documented in the schema. The description adds no syntax, default, or format detail beyond it, making the baseline 3 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?

Clear verb ("Returns") plus specific resource ("historical earnings data") and an enumeration of what it covers (liquidity fees, block rewards, bonding/liquidity earnings). However, it does not distinguish itself from nearby siblings such as get_liquidity_history, get_affiliate_earnings, or get_rune_history.

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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. With several overlapping history/earnings siblings present, an agent gets nothing to help it choose this tool over them.

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 annotations already establish that this is a safe read operation, so the safety burden is covered. The description adds nothing about how many holders constitute 'top', the ordering, whether results are truncated or cached, or the balance units — all relevant for interpreting the output of an unparameterized endpoint.

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 with no filler — appropriately sized for a no-argument endpoint. It is arguably too terse rather than wasteful, which caps it at 4.

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 and no parameters, the description carries the full burden of explaining what comes back, yet 'top' and 'balances' remain unquantified and the record shape is unspecified. An agent cannot predict result size, ordering, or fields before calling.

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 no parameter syntax the description could meaningfully 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 and resource ('Returns top RUNE holders with their balances'), so an agent knows this is a holder-listing read. It does not, however, differentiate itself from adjacent holder/provider tools such as list_rune_providers or get_runepool_member, and 'top' is left undefined.

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?

There is no guidance on when to call this versus the many other RUNE-holder or provider endpoints in the sibling list, and no stated preconditions. The agent must infer usage from the name alone.

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?

Annotations already mark it read-only; the description adds that the response includes per-chain gas rates and halted status, which explains the dynamic/non-idempotent nature hinted by idempotentHint=false. It does not cover auth or rate limits, but for a no-param read endpoint this is useful added context.

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

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

Two sentences, front-loaded with the core purpose and followed by the per-chain return detail. Every clause earns its place; no boilerplate 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?

With no output schema, the description must carry return-value information; it identifies the main return categories (vault addresses per chain, gas rates, halted status) but does not describe structure or format. Given the tool's low complexity and zero parameters, this is nearly 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?

There are no parameters, so per the rubric the baseline is 4; schema coverage is 100% and there is nothing for the description to compensate for. No additional 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 ('Returns') and resource ('vault addresses' / 'inbound address') and ties it to the concrete use case of depositing assets into THORChain. The per-chain scope and inclusion of gas rates/halted status distinguishes it from generic vault-listing 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?

The phrase 'for depositing assets into THORChain' implies the usage context, but the description does not explicitly state when to choose this over siblings like get_vault or list_asgard_vaults, nor does it list prerequisites or exclusions. Usage is only implied.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, covering the safety profile. The description adds genuinely useful behavioral context: it explains that the tool returns a result showing whether the invariant is broken plus informative messages. That output disclosure is valuable, particularly since no output schema exists. It stops short of 5 because it does not discuss how results may vary across calls or any execution constraints.

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

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

The description is three short sentences and is front-loaded with the core action. Each sentence contributes something, though the final usage sentence is fairly generic. It is appropriately sized for a simple one-parameter tool with no wasted exposition.

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

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

For a read-only, single-parameter tool with full schema coverage and existing annotations, the description covers purpose, output semantics, and a usage rationale. The absence of an output schema is mitigated by the description explaining what the result contains. It is nearly complete, with only minor nuance about non-idempotent behavior left to annotations.

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

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

Schema description coverage is 100%, so the schema fully documents the single 'invariant' parameter, including example names. The description adds no additional syntax, format, or semantic detail beyond what the schema already provides. A baseline 3 is correct when the schema does all the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Runs a specific protocol invariant check and returns the result.' This is clear and actionable, but it does not name or differentiate itself from the sibling list_invariants tool, which is the closest alternative. A 4 is appropriate for a clear purpose that lacks explicit sibling routing.

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 sentence 'Use this to verify protocol consistency and detect potential issues' provides an implied use case, but there is no guidance on when to prefer this over list_invariants or when it is inappropriate. This is the minimum viable level: a generic when-to-use statement without alternatives or exclusions.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, covering the safety profile. The description adds what data is returned (keygen block, member nodes, signature), which is output semantics rather than behavioral traits like permissions or 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?

Three sentences with no wasted words, front-loading the purpose and then giving usage context. Every sentence is relevant and 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 simple two-parameter read tool with no output schema, the description adequately explains what is returned and when to use it. It could mention edge cases like missing ceremonies, but it is complete enough 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?

Schema description coverage is 100%, so the schema fully documents both parameters. The description mentions the parameters but adds no additional format or syntax details 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?

State a specific verb (returns) and resource (keygen information) with the identifying parameters (block height and pubkey). It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools like get_keygen_metric or get_keysign.

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 a clear usage context: 'Use this to investigate vault creation events.' This gives a concrete scenario, but no exclusions or alternatives are mentioned.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds that it returns timing metrics for a vault key, but does not explain what those metrics include or why idempotency is marked false for a read. That is a modest addition beyond structured fields.

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?

It is a single front-loaded sentence with no filler. It is efficient, though it could have used one clause to differentiate from sibling keygen tools.

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 full schema coverage and readOnlyHint annotations, the description carries enough to call it correctly. The only gap is sibling differentiation and what the timing metrics contain, which are minor given the simple interface.

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 the single pubkey parameter documented as a 'thorpub...' vault public key. The description matches the schema's meaning but adds no format examples or lookup caveats beyond it, so 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 states a specific verb ('Returns') and resource ('keygen timing metrics'), and scopes it to a vault public key. It does not distinguish itself from nearby siblings like get_keygen, get_keysign, or get_tss_metrics, which also concern keygen/key operations.

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?

There is no guidance on when to use this versus get_keygen or get_tss_metrics, nor any prerequisites or exclusions. The only usage signal is the implicit 'for a specific vault public key', which is just the parameter requirement.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description usefully adds that the result is a per-height signing view containing outbound transaction details. It does not explain the non-idempotent hint, whether the view is historical/immutable, or how unpaginated the response may be.

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 short sentences, front-loaded with purpose before usage. The second sentence's content and the third sentence's 'at a particular block' partially restate the opening, so there is minor 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?

There is no output schema, so the description must describe returns, and it does name the core payload (scheduled signing transactions with outbound details). For a one-parameter, read-only tool this is nearly enough; only edge cases like empty heights or response shape remain unaddressed.

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% for the single 'height' parameter, so the schema already documents it. The description only repeats 'for a specific block height' without adding format, range, or whether the height may be a tip/pending height.

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 ('Returns keysign information') and scopes it to a block height, then elaborates on the payload ('transactions scheduled to be signed at that height, including outbound transaction details'). It distinguishes itself implicitly from neighbors like get_keygen and get_scheduled_queue by being height-keyed, but it never names a sibling to sharpen the boundary.

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?

'Use this to investigate signing operations at a particular block' gives an implied investigative context, but there is no when-not guidance and no named alternative (e.g., get_keysign_pubkey or get_scheduled_queue) for agents that actually want the queue rather than historical signing at a height.

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?

Annotations already declare this a read-only operation, so the safety profile is covered. The description adds useful content context (it surfaces the transactions a vault signed at that height), but says nothing about result shape, pagination, or why idempotentHint is false for what looks like a pure query.

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 short sentences with the core purpose front-loaded. The third sentence marginally restates the second but still earns its place as a usage cue, so the text is close to optimal size.

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 read-only query with full schema coverage and no output schema, the description is largely sufficient. The one material omission is disambiguation from the sibling `get_keysign`, which an agent needs in order to pick the right 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% and both parameters are documented in the schema, so the baseline applies. The description restates 'block height and vault pubkey' but adds no format, range, or validation 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?

States a specific verb and resource ('Returns keysign information') plus the exact scoping keys (block height and vault pubkey), which is more precise than the bare name. However, it never distinguishes itself from the close sibling `get_keysign`, which appears to be the unfiltered variant, so an agent must infer the distinction.

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?

'Use this to investigate a specific vault's signing activity' implies a use case but gives no explicit when/when-not rules and names no alternative. The natural alternative (`get_keysign`) is left unmentioned, so routing depends on the agent noticing the pubkey parameter.

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?

Annotations already establish that this is a read-only operation. The description adds useful behavioral context by naming the possible status values, but it does not describe the return shape, ordering, or why the tool is not idempotent.

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 efficient sentence with no wasted text. It is front-loaded with the verb and resource.

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 tool with no output schema, the description could say more about the returned pool structure beyond the status values. It also leaves ambiguity about how this differs from closely related pool-listing tools.

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 schema is empty, and the description correctly does not invent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns known pools with status values. Clear enough to understand the operation, but it does not distinguish itself from siblings such as list_pools or get_pool.

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 no explicit when-to-use guidance or comparison with alternatives. An agent must infer whether this tool is preferable to list_pools or get_pool based only on the phrase "known pools."

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?

Annotations already establish readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description usefully explains the 'observed vs signed' distinction as a halt-detection signal, but does not note that results change over time (the non-idempotent behavior) or the response shape.

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

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

Two tight sentences, front-loaded with what is returned before the use case. 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 parameterless read tool with no output schema, the description adequately conveys what comes back and why it matters. It could go slightly further on return structure across multiple chains, but nothing essential to invoking it correctly is absent.

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

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

The tool takes zero parameters, so per the rubric this is a baseline 4. No parameter documentation is needed or 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: 'Returns the last observed and signed block heights for all chains.' The 'for all chains' scope implicitly distinguishes it from the sibling get_lastblock_chain, though the sibling is never named, so differentiation is left to inference.

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 supplies an intended context ('monitoring chain sync status and detecting chain halts') but gives no explicit when-to-use versus alternatives or prerequisites. An agent can infer the use case but must guess why it would pick this over get_lastblock_chain.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds one piece of behavioral context — that it returns both 'observed' and 'signed' heights, two distinct values — which is meaningful beyond the annotations, but it says nothing about freshness, caching, or what happens for an unknown chain.

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, no filler, and the core behavior is front-loaded before the usage hint. 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 one-parameter read-only lookup with no output schema, the description plus annotations plus full schema coverage give an agent enough to call it correctly. The only real gap is the missing contrast with the sibling get_lastblock.

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 chain parameter is fully documented in the schema with examples (BTC, ETH, THOR). The description adds no syntax, format, or cardinality detail beyond that, so 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 with scope: 'Returns the last observed and signed block heights for a specific chain.' An agent can tell what it does. It does not, however, explicitly differentiate itself from the sibling get_lastblock, which likely returns the same data without per-chain scoping.

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?

'Useful for monitoring a particular chain's sync status' implies a usage context but gives no explicit when-to-use vs. alternatives (e.g. get_lastblock for all chains) and no exclusions or prerequisites.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds non-obvious operational context the annotations cannot carry: the AdvSwapQueueEnabled feature-flag prerequisite and the shape of returned entries. It does not explain pagination behavior, error/empty responses when the flag is off, or ordering 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, each carrying distinct information: what is returned, what can be filtered, and the runtime precondition. No repetition of parameter syntax or annotation content, and purpose is front-loaded.

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

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

Seven optional parameters are fully covered by the schema and safety is covered by annotations, so the description's job is mostly to convey the return shape, which it does at a high level since no output schema exists. The main gap is that it doesn't say what an agent sees when AdvSwapQueueEnabled is false or how the queue is ordered by default.

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 all seven parameters (limit, offset, sender, sort_by, sort_order, source_asset, target_asset) are already documented with defaults and allowed values. The description only loosely gestures at 'source/target asset, sender, and pagination' and omits the sort parameters entirely, adding no syntax or 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 and resource ('Returns the limit swaps queue containing pending limit orders') and enumerates the entry contents (swap details, ratio, age, expiry). However, it never distinguishes itself from the closely named sibling get_limit_swaps_summary or get_swap_queue, so an agent must guess which returns the raw queue versus a 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?

Gives usable context: it supports filtering by source/target asset and sender, plus pagination, and it discloses a real gating precondition ('Limit orders only work when AdvSwapQueueEnabled is true'). It stops short of naming alternatives (e.g. the summary tool) or stating when not to use it, so it clears the 'clear context' bar without reaching explicit 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?

While annotations cover safety (readOnlyHint), the description provides critical behavioral information about the data structure returned. It enumerates the specific aggregate metrics provided (e.g., 'breakdown by asset pair,' 'average age'), which is valuable context beyond simple read/write status.

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 highly efficient. The first sentence is packed with specific output details, and the second sentence provides a concise, functional use case, ensuring zero wasted language.

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 that the output schema is missing, the description successfully compensates by exhaustively listing every piece of information the agent should expect in the summary (count, USD value, ages, breakdown). This makes the tool definition fully actionable.

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?

Since the schema description coverage is 100%, the parameters are well-documented structurally. The description reinforces the filtering logic by mentioning 'breakdown by asset pair,' which aligns with the `source_asset` and `target_asset` filters.

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 specifies the resource ('limit swaps queue') and the specific output provided ('a summary... including total count, total USD value, breakdown by asset pair, oldest swap age, and average age'). It also clearly distinguishes itself from retrieving individual swaps.

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 explicit context on *when* to use the tool: 'Useful for getting an overview of pending limit orders without retrieving all individual swaps.' This directly advises the agent on its scope versus other potential queue/swap tools.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds which historical metrics are returned, but does not explain default time behavior, pagination, or why idempotentHint is false; no contradiction is present.

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 with zero filler. It communicates the resource and returned metrics efficiently.

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 historical query, the description gives enough return-value detail and the schema fully covers parameters. Minor gaps remain around defaults and response structure, but these are small for a 4-parameter read-only 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 description coverage is 100%, with to/from/count/interval all documented in the schema. The description only restates the idea of time intervals and does not add syntax, defaults, or constraints 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?

States a specific verb and resource: returns historical liquidity change data with concrete metrics like add/withdraw counts, volumes, and net liquidity. It is clear, but does not distinguish itself from sibling history tools such as get_tvl_history or get_depth_history.

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 no explicit when-to-use guidance, no conditions for choosing this over alternative history tools, and no prerequisites or exclusions. The agent must infer usage from the name and description alone.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds what the response contains (units, pending asset/rune, last add/withdraw heights), which is useful given there is no output schema, but it says nothing about error behavior for unknown addresses/pools 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 sentences, zero filler, and the core purpose is front-loaded ahead of the return-content detail.

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

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

With no output schema, the description usefully enumerates the key returned fields, and the schema fully covers inputs. Only gap is behavior on missing/invalid positions, which would round out an otherwise complete definition.

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 both parameters are documented in the schema with examples ('BTC.BTC'), so the baseline of 3 applies. The description adds no format, validation, or case-sensitivity detail beyond what the schema already 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?

States a specific verb and resource ('Returns liquidity provider position information') plus the scope ('for a specific address in a pool'), which is enough to separate it from the plural list_liquidity_providers. It never names a sibling explicitly, so differentiation is inferable rather than stated.

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

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

Usage is only implied: the agent can infer you call this when you already know the asset and LP address, and that listing many LPs is a different tool. There is no explicit when-to-use, when-not-to-use, or prerequisite guidance (e.g. what happens if the address has no position in that pool).

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 readOnlyHint annotation already establishes this is a safe read, so the description's value-add is limited to the scope word 'all'. It says nothing about ordering, snapshot consistency, whether the set changes over time (notable given idempotentHint=false), or how large the list may be.

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 with zero padding and no filler. It is efficient, though the extreme brevity is closer to under-specification than to well-judged concision.

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 with no output schema, the description does carry the burden of conveying the return shape, and 'list of addresses' partially does so. But ordering, pagination, and freshness of the address set are all unaddressed, leaving an agent unable to predict the response.

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 the baseline is 4 by rule. There is nothing for the description to clarify, and schema coverage is trivially 100%.

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 ('Returns list of all liquidity provider addresses'), and the word 'addresses' usefully distinguishes it from the sibling list_liquidity_providers, which presumably returns richer LP objects. However, it never explicitly contrasts itself with that near-identical sibling, so an agent must infer the difference.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_liquidity_providers or get_midgard_member. The one sentence describes output content only; an agent gets no routing signal.

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?

Annotations already state readOnlyHint=true and idempotentHint=false, so safety and idempotency are covered structurally. The description adds the Midgard analytics data source, which is useful, but it does not describe return behavior, freshness, authentication, or why the operation is non-idempotent.

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

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

The description is a single front-loaded sentence with no redundant or filler content. Every phrase contributes to the stated purpose.

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

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

For a simple one-parameter read-only tool, the description is minimally adequate. However, without an output schema it does not clarify what kind of balance is returned, such as which asset or aggregate scope, leaving return semantics underspecified.

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

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

Schema description coverage is 100%, so the single address parameter is already fully documented in the schema. The description merely restates that the address is used to get a balance and adds no format or domain constraints 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 uses a specific verb and resource: returns an address balance from Midgard analytics. It is clear what the tool does, but it does not explicitly differentiate itself from similar siblings such as get_cosmos_balances or get_midgard_member.

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

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

The description gives no guidance on when to use this tool versus alternatives. With many sibling balance/account tools available, an agent must infer the selection criteria from the name alone.

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?

Annotations already declare readOnlyHint=true (safe read) and idempotentHint=false, so the safety profile is covered. The description adds value by disclosing the returned content categories, including historical deposit/withdraw data, but says nothing about data freshness, history depth, or address-resolution behavior for external chains.

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

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

One sentence, front-loaded with the verb and resource, and the content list is compact. It could arguably be trimmed further, but there is no wasted preamble 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?

With no output schema, the description carries the burden of describing returns, and it does list the main returned fields at a high level. For a single-parameter read tool that is largely sufficient, though the absence of routing guidance versus siblings keeps it from being fully 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 100% and the single 'address' parameter is fully documented in the schema (thor1... or external chain address). The description only echoes 'for an address' without adding format, validation, or multi-chain semantics, so 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 ('Returns') and resource ('liquidity provider positions for an address') and enumerates the payload contents (pool participation, units, deposit/withdraw history). It does not distinguish itself from close siblings such as get_lp_position, get_members, or get_runepool_member, so an agent cannot tell which to prefer without opening the other 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?

There is no when-to-use guidance, no mention of when not to use it, and no reference to any alternative tool. Given the dense cluster of LP/member siblings, this omission is significant; the agent gets no routing signal beyond the tool name.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds useful detail about returned fields (addresses and public keys) and the Midgard source, but it does not explain why the operation is non-idempotent or what form the returned node data takes.

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 definition is a single front-loaded sentence with no filler. It communicates the tool's action and data source efficiently.

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 parameters, no output schema, and annotations covering core safety hints, the description is nearly complete. It explains the Midgard source and key returned fields, though it could do more to distinguish this tool from sibling node-information tools.

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. The description does not need to explain parameter meanings and appropriately focuses on the returned data instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns node information, including addresses and public keys, from Midgard analytics. This is clear enough to understand the tool, but it does not differentiate the tool from siblings such as list_nodes, get_node, or get_cosmos_node_info.

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 phrase 'from Midgard analytics' implies that this tool should be used when Midgard-sourced node data is desired, but there is no explicit guidance on when to use it instead of related node or analytics tools. The usage context is only implied.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered externally. The description adds no behavioral context beyond the content list: it says nothing about data freshness or snapshot semantics (notably absent given idempotentHint=false implies changing values over time), caching, or 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?

A single front-loaded sentence with no filler; the verb and the returned metric categories come first. Every clause earns its place and nothing is padded.

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 carries the return-value burden and does list representative fields (swap counts, volumes, liquidity metrics, RUNE price), which is enough for an agent to call it correctly. It falls short of complete because it does not signal whether the list is exhaustive or clarify its relationship to the similarly-named network summary tools.

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 for the description to disambiguate and the baseline is 4. The enumerated metric categories partially compensate for the absent output schema, though they are return semantics rather than parameter semantics.

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 specific verb+resource ('Returns global network statistics') and enumerates the payload categories (swap counts, volumes, liquidity metrics, RUNE price), so an agent knows exactly what this tool yields. It does not, however, distinguish itself from near-name siblings like get_network_info, get_network_summary, or get_pool_stats, which also sound like network-level aggregates.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. Given a sibling set containing get_network_summary, get_network_info, get_tvl_history and get_rune_price_history, the description never explains why an agent would pick this Midgard aggregate over those.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered; the description adds useful semantic context about what Mimir values actually are. It does not disclose scope (global protocol vs node-scoped), whether the full key set or a filtered subset is returned, or how it relates to the node/admin variants.

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

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

Two tight sentences, front-loaded with the return value and followed by an explanation of the values' role. No filler, though the second sentence could have been spent on sibling differentiation instead of defining Mimir.

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 adequately covers what is returned, but it leaves the most consequential open question unanswered: how this differs from get_mimir_node, get_mimir_admin, and get_mimir_key. That ambiguity is material given how many near-identical Mimir siblings exist.

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 and the schema is trivially complete at 100% coverage, so the baseline of 4 applies. The description correctly implies no inputs are needed to fetch the configuration set.

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 (Returns) and resource (THORChain protocol configuration parameters / Mimir values), and even explains what the values are semantically (key-value pairs controlling fees, limits, feature flags). However, it gives no signal distinguishing it from the closely-named siblings get_mimir_admin, get_mimir_key, and get_mimir_node, which an agent must disambiguate before choosing.

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 offers no when-to-use guidance, no exclusions, and never mentions the alternatives (get_mimir_admin, get_mimir_node, get_mimir_key) that return overlapping Mimir data. An agent has to infer that this is the global/default view from the name alone.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered, and the description doesn't contradict it. It adds useful domain context (admin overrides take precedence over node votes), but says nothing about return format, pagination, or freshness of the values.

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 tight sentences that front-load the resource and then add the one piece of context (admin vs node-voted) that matters. 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 no-parameter read tool with no output schema, the description covers what is returned and why it differs from other mimir data. Only the absence of any return-shape hint keeps it from being fully 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?

The tool takes zero parameters, so the baseline of 4 applies; there are no parameter semantics to clarify. Nothing in the description is needed to compensate for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Returns the admin mimir configuration') and clarifies the distinguishing trait versus other mimir data: these are admin-set protocol parameters rather than node-voted ones. It doesn't name the sibling get_mimir explicitly, but the admin-vs-vote distinction gives an agent a basis for differentiation.

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

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

The description explains what admin mimir is but gives no explicit when-to-use guidance or naming of alternatives. An agent must infer from the sibling list whether to call get_mimir, get_mimir_key, or this tool; nothing states the selection condition.

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 annotations already declare readOnlyHint=true, and the description goes beyond that by explaining the resolution semantics: the value is 'final resolved' after 'admin overrides and node voting consensus.' That tells the agent what the returned number actually represents, which is genuine behavioral context not present in the annotations.

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

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

Three short sentences, zero filler, with the core behavior front-loaded and the resolution detail immediately after. Nothing is padded.

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 output schema, the description covers what the value means and when to reach for it. It is nearly complete; only the missing sibling differentiation and the behavior on an unknown key keep 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 coverage is 100% and the schema itself supplies example keys (CHURNINTERVAL, HALTTRADING), so the description's reference to 'a specific mimir key' adds little beyond it. Baseline 3 is appropriate when the schema does the documentation work.

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: 'Returns the effective value for a specific mimir key.' An agent knows exactly what it fetches. However, it never distinguishes itself from the very similar siblings get_mimir, get_mimir_admin, and get_mimir_node, so it falls short of full differentiation.

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

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

'Use this to check the current value of any individual protocol parameter' implies the usage context, but there is no when-not guidance and no naming of the alternatives (get_mimir for bulk, get_mimir_admin for overrides). The agent must infer which of the four mimir tools to call.

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?

Annotations already establish readOnlyHint=true, so safety is covered by structured data. The description adds the return shape (a map of mimir keys to voted values), which is useful, but says nothing about why idempotentHint=false (votes change over time), whether non-voting nodes return an empty map, or how large the result can be.

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 short sentences with no filler, front-loaded with the core action and followed by the return shape. It could be trimmed slightly since the third sentence partly restates the first, but nothing is wasted.

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 lookup with no output schema, the description covers what is fetched, for whom, and in what shape. The main remaining gap is disambiguation from the sibling mimir-vote tools, which would make it fully self-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 description coverage is 100% and the single address parameter is fully documented in the schema, including the thor1... format. The description only restates that the address identifies the node, adding no syntax or format detail 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 gives a specific verb and resource ("Returns the mimir settings voted by a specific node") and scopes it to one node address, which separates it from get_mimir and get_mimir_key. It does not, however, distinguish itself from the very close sibling list_mimir_node_votes, which an agent could easily confuse it with.

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?

"Use this to see what protocol parameters a specific node operator is voting for" supplies a clear use case, but there is no when-not guidance and no named alternative, despite list_mimir_node_votes and get_mimir_key being near neighbors. Usage is implied rather than routed.

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?

Annotations already declare readOnlyHint=true, so the safe-read nature is known without the description. The description usefully enumerates what data is bundled (bond metrics, pool data, node counts), but it does not address the odd idempotentHint=false for a parameterless read, nor return format or freshness/staleness of the data.

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 tight sentence that front-loads the verb and resource and then lists the payload categories. Nothing is wasted, though the phrase 'network statistics and health information' is slightly broad relative to the specific items that follow.

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 parameters and no output schema, the description must carry the full burden of what an agent gets back, and it partially does by naming data categories. However, it gives no way to distinguish this aggregate from the several sibling aggregate/stats tools, leaving a real selection 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 takes zero parameters, so there is nothing for the description to clarify; the baseline for a 0-param schema is 4.

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 (Returns) and resource (THORChain network statistics and health information) with concrete content categories: bond metrics, pool data, node counts. It is clear on its own, but it does not differentiate itself from close siblings like get_network_summary, get_midgard_stats, or get_bonds, which appear to cover overlapping ground.

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?

There is no guidance on when to use this tool versus the many overlapping siblings (get_network_summary, get_midgard_stats, get_bonds, list_nodes). The agent is left to infer selection from the description alone, with no exclusions or 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the 'compact' framing and implicitly the trade-off versus the bulky alternative, but says nothing about rate limits, auth, or caching. The idempotentHint=false is consistent with a changing churn height, so no contradiction.

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, zero waste: the first enumerates the return contents, the second handles routing. Both are front-loaded and information-dense.

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 compensates by listing what the summary contains (node counts, APY, reserve, pooled RUNE, churn height, vault flag), which is exactly what an agent needs to decide relevance. 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; there is nothing for the description to disambiguate, and 100% schema coverage applies trivially. Baseline 4 for a parameterless tool.

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 (network status summary) and enumerates the exact contents returned: node counts, bonding/liquidity APY, reserve, pooled RUNE, churn height, vault migration flag. It also explicitly distinguishes itself from the sibling get_network_info.

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 routing rule: 'Prefer this over get_network_info, which returns large per-node bond arrays.' Names the alternative and the condition (verbosity/size) that selects this tool instead.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered by structured data. The description contributes genuine extra context by explaining that bond providers include Bond Yield configuration (bps share and payout_target), but says nothing about permissions, error cases, or whether idempotentHint=false matters here.

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 front-loaded sentences with no filler; the core purpose leads and the Bond Yield detail follows as a qualifier. Slightly dense in the second sentence but every clause 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-parameter read tool with no output schema and no nested objects, the description covers both what it returns and a notable conditional case (Bond Yield when set) – including the payout_target terminology an agent cannot derive from the schema. Missing only the rare edge/permission context.

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 one parameter and 100% schema description coverage, the schema fully documents the address argument (including its thor1... format). The description adds no syntax or format detail beyond the schema, 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 (returns) and resource (a specific validator node) and enumerates the returned fields (bond, status, version, performance metrics). It implicitly distinguishes itself from the list-oriented siblings like list_nodes and get_midgard_nodes via 'a specific node', but never names them, so differentiation is inferable rather than explicit.

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

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

Usage is only implied: an agent can infer this is the lookup when it already has a node address, versus list_nodes for enumeration. No explicit when-to-use, prerequisites, or named alternatives are given, and with many node-related siblings (get_midgard_nodes, get_cosmos_validators, get_cometbft_validators) this is a real gap.

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?

Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds that the result is in USD and what it is used for, but does not disclose freshness, volatility, or why idempotentHint=false despite returning a price.

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 the primary behavior front-loaded. The second sentence carries useful context about USD denomination and common uses, though it could be tightened.

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?

Adequate for a simple one-parameter getter with rich schema coverage and no output schema. However, it omits the key sibling distinction from get_oracle_prices and does not mention price freshness, which matters for a non-idempotent oracle 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?

The only parameter is fully documented in the schema, including examples (BTC, ETH, RUNE), so schema coverage is 100%. The description adds no syntax or format detail beyond restating that the symbol selects the asset.

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: returns the oracle price for a specific asset symbol. Clear on its own, but it does not distinguish itself from the sibling tool get_oracle_prices, so an agent must infer singular vs. plural behavior.

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 domain context (protocol calculations and limit order pricing) but gives no explicit when-to-use guidance, no prerequisites, and no comparison to the obvious alternative get_oracle_prices. The choice between this tool and its plural sibling 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. With no output schema, the description usefully discloses the return shape (array of objects with symbol and USD price), which is genuine added context, though it says nothing about the idempotentHint=false flag or refresh/latency 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?

Three short sentences, front-loaded with the core action. Mild redundancy from repeating 'Returns ... Returns ...' but 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 no-param read tool with no output schema, the description adequately covers purpose and return structure. It could be more complete by naming the singular sibling it differs from.

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, so the baseline of 4 applies; there are no arguments whose semantics need explaining.

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: 'Returns all oracle prices for supported assets.' The word 'all' implicitly distinguishes it from the singular sibling get_oracle_price, though that sibling is never named explicitly.

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 context for what oracle prices are used for (asset valuation, limit-order pricing) but never states when to call this plural tool versus get_oracle_price or any other alternative. Usage is only implied.

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 annotations already declare readOnlyHint=true, so safety is covered. The description adds value by naming the returned fields (fee amount, surplus/deficit, multiplier), which is useful because there is no output schema. It does not describe edge cases, error behavior, or whether values are live versus cached, so it remains moderate.

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

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

The description is a single, front-loaded sentence that directly states what the tool returns. There is no redundant or filler text.

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 getter with one fully documented parameter and no output schema, the description is mostly complete because it names the key returned fields. The main missing context is how this tool relates to the sibling get_outbound_fees, but the core invocation information is 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 description coverage is 100%, and the single asset parameter is documented in the schema with an example format (e.g. BTC.BTC). The description does not add syntax or format details beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: returns outbound fee information for a specific asset. It also names the returned data fields (fee amount, surplus/deficit tracking, dynamic multiplier), making the tool's scope clear. It does not explicitly distinguish this per-asset tool from the sibling get_outbound_fees, 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 phrase 'for a specific asset' implies the tool should be used when an asset-specific outbound fee is needed, which gives some usage context. However, it does not explicitly say when to use this tool versus get_outbound_fees or get_outbound_queue, leaving the agent to infer the difference.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It adds content scope (all assets, surplus/deficit, dynamic multiplier) but says nothing about freshness or volatility despite idempotentHint=false implying the data changes between calls, nor about the shape of the return. Adequate but with a clear gap.

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, zero padding, with the resource and its scope front-loaded ahead of the usage hint. Every clause carries 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?

With no parameters and no output schema, the description usefully enumerates the returned fields, which covers the main gap left by the absent output schema. It is nearly complete; only freshness/volatility and the all-assets vs. single-asset relationship are left implicit.

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 for the description to disambiguate; the baseline of 4 applies. No parameter-related information is required or 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 (returns outbound fee information) and names the scope ('for all assets'), which implicitly distinguishes it from the singular sibling get_outbound_fee_asset. It also enumerates the payload contents (fee amount, surplus/deficit, dynamic multiplier), so an agent knows what it gets 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?

'Use this to estimate transaction costs' gives a clear motivating context, but there is no when-not guidance and the obvious alternative, get_outbound_fee_asset for a single asset, is never named. Usage is implied rather than routed.

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?

Annotations already declare readOnlyHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: these are already-signed transactions in a pre-broadcast state, which tells the agent the queue is a staging area rather than a history. Auth and rate-limit behavior are still unstated.

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 short sentences, front-loaded with the core purpose. The third sentence largely restates the first ('signed' / 'awaiting confirmation' repeats 'signed transactions waiting to be broadcast'), which is minor redundancy rather than 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 enumerates the entry fields (destination chain, address, coin amount, gas), which is exactly the return-value detail an agent would otherwise lack. For a zero-param read tool this is close to complete; it only lacks positioning against sibling queues.

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. Nothing in the description is needed to clarify parameter meaning, and nothing misleads.

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 ('Returns the outbound queue') and pins down scope with 'signed transactions waiting to be broadcast to external chains.' However, it never distinguishes itself from the many sibling queue tools (get_queue, get_scheduled_queue, get_swap_queue), so an agent must infer which queue to pick.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named despite several closely related queue siblings. The agent gets no routing help beyond the tool name.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description confirms it is a retrieval operation and adds no contradictory behavior, but it provides no additional context about return detail, formatting, or edge cases beyond what the annotations already establish.

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

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

The description is a single efficient sentence with the core action and scoping condition front-loaded. There is no wasted text.

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

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

For a simple one-parameter read tool this is minimally adequate, but it does not differentiate from closely named siblings and does not describe what 'detailed information' includes despite there being no output schema. Some gaps remain for an agent deciding whether this is the right pool-detail 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 description coverage is 100%, and the single parameter is already well documented with examples. The description mentions 'asset identifier' but adds no syntax or format detail beyond the schema, 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 clear verb and resource: returns detailed information for a specific liquidity pool, scoped by asset identifier. It does not explicitly distinguish itself from siblings like get_pool_stats or list_pools, 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 phrase 'by asset identifier' implies when the tool applies, but there is no explicit guidance on when to use it versus alternatives such as get_pool_stats, get_derived_pool, or list_pools. Usage is implied rather than 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that it returns current slip and rollup statistics, which helps explain the kind of data returned, but it does not discuss time sensitivity, pagination, or other behavioral details, and it does not contradict the annotations.

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

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

The description is a single, front-loaded sentence with no wasted language. It states the operation and the returned data immediately.

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

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

For a simple one-parameter read-only tool, the description provides adequate context: it says what resource is queried and what kind of data is returned. There is no output schema, and while the description could elaborate on the shape of the slip data, it is sufficient for an agent to call the tool correctly.

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

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

Schema description coverage is 100% and the single required parameter 'asset' is fully documented in the schema, including an example. The description only says 'for one pool' and adds no meaningful parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it returns slip data for one pool. It also names the returned content, current slip and rollup statistics, but it does not explicitly distinguish itself from the sibling list_pool_slips beyond the implied single-pool 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?

Usage is implied by 'for one pool,' suggesting this tool is appropriate when the agent needs slip data for a specific asset rather than a list. However, it does not explicitly name when to choose this over list_pool_slips or state any prerequisites or exclusions.

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