THORChain MCP

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description's added value is that it returns the would-be reference plus a registration availability verdict, but it does not say what an unavailable verdict looks like, whether an error is raised, or any rate/state 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?

Two short sentences, front-loaded with the purpose and followed by the return semantics, with no filler. Slightly compressed to the point that the jargon is left unexpanded.

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 names the two things returned but not their shape or failure modes. For a small two-parameter read-only check this is adequate but leaves an agent guessing about output format.

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 with examples and units, so the schema carries the load. The description only obliquely notes that the reference is derived 'from the amount', adding no format 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 ('pre-flight check' returning an extracted 'reference' and its availability), which is more than a restatement of the title 'Check Reference Memo'. It is distinguishable from the sibling tools, none of which deal with references. It falls short of 5 because the domain terms 'memoless' and 'reference' are never defined, so the exact operation is only inferable.

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 the moment to call it (before registering a memoless transaction), but no alternative tool is named and there is no explicit when-not guidance. The agent must infer the workflow position 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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by disclosing what the response contains per chain (inbound address, gas rates, halted status), which annotations cannot convey. It stops short of explaining how halt status should affect agent 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 short sentences with zero filler, and the return content is front-loaded right after the purpose. Nothing in the text is redundant with the title.

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

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

With no parameters and no output schema, the description must carry the return-value burden, and it names the three payload elements an agent needs (address, gas rate, halted flag). It omits how results are keyed by chain and whether halts are per-chain or global, a minor residual gap for a simple read tool.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly says nothing about inputs, avoiding confusion.

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

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

The description opens with a specific verb and resource ("Returns vault addresses") and states the concrete use case, depositing assets into THORChain, which separates it from siblings like get_pool or get_outbound_fees. It doesn't explicitly name an alternative tool, but the purpose is unambiguous.

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 through the phrase "for depositing assets" — an agent can infer this is the lookup to perform before a deposit. There is no explicit when-to-use guidance, no mention of pairing with prepare_swap or check_reference_memo, and no 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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful detail beyond that by explaining that the result covers observed and signed heights across all chains and is useful for halt detection. It does not specify freshness or response structure, but the annotations lower the disclosure burden.

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 followed by the use case. Every sentence adds useful information with no filler or repetition.

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

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

For a zero-parameter read tool with rich annotations but no output schema, the description gives a sufficient high-level account of what is returned and why it matters. It could optionally describe the response shape or update freshness, but nothing critical for invocation 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 no parameters, so there is no parameter semantics to document. The baseline for zero parameters is 4, and the description appropriately avoids inventing input 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 and resource: returns last observed and signed block heights for all chains. This is clearly distinct from sibling tools, which focus on swaps, pools, transactions, and network summaries. An agent can identify the tool's purpose 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?

The description gives clear usage context: monitoring chain sync status and detecting chain halts. It does not name alternatives or exclusions, but for this simple zero-parameter read tool the intended use is unambiguous.

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 safe, read-only, idempotent, open-world read, so the description needn't restate safety. It adds value by disclosing the compact shape and size tradeoff versus get_network_info, which is the main behavioral risk here (payload bloat). It says nothing about data freshness or caching of churn/reserve 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?

Two tight sentences: the returned-field list comes first, then the alternative-tool guidance. Every clause carries information; 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 so by naming each field. It is nearly complete for a zero-parameter read call; only freshness/caching semantics for volatile fields like reserve and next churn height are 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?

The tool takes no parameters, so the baseline is 4; there is no parameter meaning the description could add or omit.

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?

Uses a specific verb+resource ('Get ... network status') and enumerates the exact payload: node counts, bonding/liquidity APY, reserve, pooled RUNE, next churn height, vault migration flag. It also explicitly separates itself from get_network_info, so an agent can choose between them 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?

Explicitly recommends this tool over get_network_info and gives the reason (the other returns large per-node bond arrays and is available in the full toolset only). It does not address how this relates to the narrower pool-oriented siblings such as get_pool_stats or list_pools, so a small gap remains.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds value by disclosing the kind of data returned, but says nothing about freshness/caching of fee values or whether the dynamic multiplier changes over time — context that matters for a cost-estimation tool.

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

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

Two sentences, front-loaded with what is returned and followed by the intended use. No filler, no restatement of the title, and 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 input parameters and no output schema, the description carries the burden of describing return values, and it does list the main components. A minor gap remains: it does not indicate the shape of the per-asset result (keyed by asset symbol, ordering) or whether all assets are always 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?

The tool takes no parameters, so there is no parameter semantics to explain; baseline applies. The description instead spends its words on output content, which is the relevant information for a zero-arg getter.

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 outbound fee information") and scopes it to "all assets," then enumerates the payload fields (fee amount, surplus/deficit tracking, dynamic multiplier). No sibling tool in the list deals with fees, so it is distinguishable in practice, though the description never names a sibling to contrast against.

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, concrete application context for when to call it. There are no explicit exclusions or named alternatives, but with zero parameters and no overlapping sibling, the use case is effectively unambiguous.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds value beyond them by naming the return fields (depths, units, status, price), which matters because there is no output schema. It doesn't say what happens for an unknown asset or whether results are live vs cached, so it falls short of full disclosure.

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

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

Two compact sentences with zero filler: the first front-loads what is returned, the second delivers the sibling routing. 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 one-parameter read tool with full annotation coverage and no output schema, the description covers purpose, returns, and alternatives adequately. The only omission is failure/edge behavior for invalid asset identifiers, which is a minor gap rather than a blocking one.

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 already carries the format example (BTC.BTC or ETH.ETH). The description repeats that example but adds no new semantics such as case sensitivity, accepted chains, or resolution rules, so the schema does the heavy lifting.

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

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

States a specific verb and resource ("Returns one liquidity pool by asset") and enumerates the payload (depths, units, status, price). It is immediately distinguishable from list_pools (enumeration) and get_pool_stats (aggregate metrics), both of which it names.

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

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

Explicitly routes the agent: use list_pools to obtain asset identifiers, and get_pool_stats for volume/fees/APY. This covers both the precondition (discovering the asset string) and the nearest alternative tool with the condition that selects 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description's help. The description adds value by naming the returned metric categories (volume, fees, APY, historical metrics), which is useful since there is no output schema, but it says nothing about the time window, granularity, or 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 wasted preamble; the only mild redundancy is the near-synonym pairing 'analytics and statistics'. It could be tightened but is well within an appropriate length for a one-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?

With one fully described parameter and complete safety annotations, the definition is nearly sufficient, but the absence of an output schema means the description should say more about the shape of the response — period covered, units, or whether history is a time series. Naming the metric categories is a partial substitute, not a full one.

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 with format examples (BTC.BTC, ETH.ETH), so the schema carries the burden. The description adds only the framing that the asset selects a pool, not any syntax, case-sensitivity, or validity rules beyond the schema's example.

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 detailed analytics and statistics for a specific liquidity pool') and enumerates the metric families (volume, fees, APY, historical metrics). It is clear what the tool does, but it never contrasts itself with the closely related siblings get_pool and list_pools, so an agent must infer 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?

Usage is only implied: 'for a specific liquidity pool' suggests it is the per-pool analytics lookup, as opposed to list_pools (enumeration) or get_pool (pool metadata). There is no explicit when-to-use, no exclusion, and no statement of prerequisites such as the pool needing to exist or be indexed.

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 cover readOnly/idempotent/non-destructive, so the description's value is in disclosing the response shape: the six possible status values, the done flag, streaming progress, estimated wait, and refund reason. The edge-case rule "refund=true with status sent means part was refunded" is genuinely clarifying. It does not say what happens for a hash that isn't a swap deposit, which is the main remaining behavioral 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?

Front-loads the purpose question, then the return contents, then the sibling routing. The dense enumeration of return fields is information-bearing rather than filler, and no sentence 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?

With one required parameter and no output schema, the description takes on the job of describing returns and does so completely: status values, done flag, summary line, progress, wait estimate, and refund reason. Nothing needed to call or interpret the tool is missing.

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

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

Schema coverage is 100% and the schema already spells out that the hash is the inbound deposit transaction and that a 0x prefix is acceptable. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

Opens with the user-facing question it answers ("did my swap go through?") and then names the concrete resource: a swap status with an explicit status enum. It distinguishes itself from the sibling get_tx_status by naming it directly.

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

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

Explicitly says "Start here for swap tracking" and routes the agent to get_tx_status only for raw stage detail, which is the one plausible alternative among the siblings. The selection condition is stated, not inferred.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that by naming the returned fields (chain, addresses, coins, memo, observed heights) and framing the result as what 'THORChain saw', which signals an observational rather than authoritative record. It does not say what happens when the hash is unknown or unobserved, a meaningful gap for an open-world lookup.

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, both front-loaded: the capability and its return contents come first, the alternative routing second. No filler, no repetition of the title or annotations.

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 correctly compensates by enumerating the returned fields, and it names an alternative for the common swap-checking case. It is slightly incomplete for a lookup tool in not addressing unknown/unobserved hashes and not differentiating from get_tx_status.

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

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

Schema description coverage is 100% and the single parameter is fully documented as 'The transaction hash (inbound or outbound)'. The description's 'inbound or outbound' phrasing merely restates the schema rather than adding format or normalization guidance, 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 the observed transaction for a hash') and enumerates the returned data: chain, addresses, coins, memo, observed heights. It distinguishes itself from get_swap_status but never mentions the closest sibling, get_tx_status, leaving an ambiguity an agent must resolve elsewhere.

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

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

Gives an explicit routing rule with a concrete user intent ('did my swap go through?' -> get_swap_status), which is exactly the kind of when-to-use guidance that helps selection. It stops short of saying when NOT to use this tool, notably when get_tx_status would be the better pick.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real value by disclosing the response shape (per-stage data plus planned and sent outbounds), which is otherwise unavailable since there is no output schema. It stops short of noting behavior for an unknown or not-yet-indexed hash.

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, with the primary capability front-loaded and the disambiguation trailing. 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 one-parameter read tool with full annotation coverage, the definition supplies purpose, alternative routing, and a sketch of the return contents. Minor gap: no note on what happens when the hash is unknown or the transaction is unindexed.

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 'hash' parameter is documented as the inbound transaction hash, so the schema carries the burden. The description adds the qualifier 'inbound', but no format or validation details beyond that.

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 THORNode's raw status for an inbound transaction') and enumerates what the payload contains: processing stages, planned outbounds, sent outbounds. The sibling contrast with get_swap_status makes the boundary unmistakable.

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

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

Explicitly routes the agent: use get_swap_status for a plain answer (pending/streaming/sent/refunded), use this for stage-level detail. Both the when and the alternative are named directly.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's job is to add operational detail. It does: it discloses that only 'active' pools are returned and names the per-record fields, which matters because there is no output schema. It does not state ordering, totals, or whether inactive pools are retrievable elsewhere.

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 what is returned, then the pagination note. Nothing is wasted, though the second sentence largely echoes parameters the schema already fully documents.

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 list tool with no output schema, the description carries the important missing piece by enumerating the returned fields and the active-only filter. Ordering and page-size default behavior are left to the schema and are acceptable omissions.

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 there, including the default 100 and max 1000. The description only restates that pagination is supported via limit and offset, adding no format or interaction 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 all active liquidity pools on THORChain') plus the content of each record (balances, units, status). The word 'all' distinguishes it in spirit from sibling get_pool, but no sibling is named explicitly, so the differentiation is implied 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 implied by 'all active ... pools' versus the singular get_pool and the aggregate get_pool_stats, but the description never says when to choose this over those siblings, nor any prerequisites or exclusions. An agent can infer the routing, but must do the work itself.

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, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds value by disclosing the return contents (chain addresses, expiry, owner), which matters since there is no output schema, but it says nothing about behavior for unregistered or expired names.

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, leading with the action and following with the payload. It is efficient, though it stops short of the length that would let it carry usage or edge-case context.

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

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

For a one-parameter read-only lookup, the definition covers purpose, the input, and the shape of the result, while annotations cover safety and idempotency. The only real gap is not-found or expired-name behavior, which is minor 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 description coverage is 100% for the single parameter, so the schema already documents 'name' as the THORName to look up. The description adds no format, casing, or resolution detail 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 and resource (returns THORName details) and enumerates the returned fields: chain addresses, expiry, owner. No sibling tool overlaps with this function, so no explicit differentiation is needed, but the description does not say what a THORName is or what the lookup is keyed on beyond the name parameter.

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 alternatives, and no stated prerequisites or name format. An agent must infer that this is the tool for resolving a registered THORName to its addresses and metadata.

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 read-only, idempotent, open-world, non-destructive behavior. The description adds useful behavioral context by stating the expected 'pong' response when the node is responding, though it does not describe failure or timeout 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 with no wasted wording, and the core purpose is front-loaded. The return value and usage guidance follow in a natural order.

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 health-check tool, the description is complete: it states purpose, expected output, and usage. Since there is no output schema, explaining the 'pong' return is especially valuable.

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 correctly adds no parameter detail because none exist.

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 endpoint type and resource: a health check for THORNode that returns 'pong'. It is distinguishable from sibling data-retrieval tools by being a connectivity check, though it does not explicitly name any 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?

Explicitly says to use this tool to verify connectivity to the node. It gives clear usage context but does not state when not to use it or mention alternatives.

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?

Goes beyond the annotations by describing the return payload (vault address, memo, source chain, expected output, guaranteed minimum, estimated time, expiry) and by clarifying the safety model: the tool only produces an instruction a wallet signs and broadcasts and never moves funds, which is consistent with readOnlyHint=true. It does not address expiry duration semantics, affiliate fee behavior, or failure modes, which keeps it short of a 5.

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

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

Three sentences, each earning its place: what it does and returns, when to use it versus the alternative, and the safety boundary. The most decision-relevant information (execute vs. price) is placed early.

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 explaining return values, and it does so by naming every field the agent needs to act on. For a 7-parameter, fully documented read-style tool, 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?

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including base units, affiliate bps, and slippage range. The description adds only indirect context by mentioning that the returned instruction includes a guaranteed minimum and an expiry, which are the downstream effects of max_slippage_bps. 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?

States a specific verb and resource ('Build a ready-to-execute THORChain swap') and immediately enumerates what the artifact contains. It explicitly distinguishes itself from the sibling quote_swap, so an agent can separate the two 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?

Gives an explicit when-to-use rule ('when the user wants to actually perform a swap, not just price it') and names the alternative tool plus the condition that selects it ('for pricing only, use quote_swap'). Nothing 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavior beyond that: the quote is non-executing by itself, includes an expiry time, and produces a memo the agent needs in order to actually place the limit order. It stops short of describing how long quotes stay valid or any rate limits, so not a 5.

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

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

Three short sentences, front-loaded with the core action and return values, followed by the execution semantics and the sibling hand-off. No filler or repetition of the title.

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

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

With ten parameters but full schema documentation and annotations covering the safety profile, the description needs only to frame purpose and the quote-to-memo workflow, which it does. Minor gap: it doesn't say whether the generated memo has an expiry that must be respected or where the memo is used, which matters for a quote-then-execute flow.

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 ten parameters, including the nuanced target_out limit price and custom_ttl, are already documented in the schema. The description adds no parameter-level detail beyond loosely implying that target_out drives execution and custom_ttl drives expiry. Baseline 3 applies since the schema does the heavy lifting.

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

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

The description opens with a specific verb+resource ("Get a limit order quote") and enumerates what comes back: expected output, expiry time, and a generated memo. It explicitly distinguishes itself from the sibling quote_swap, so an agent can route correctly 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?

It names the alternative tool (quote_swap) and the condition that selects it ("immediate market swap"), plus states the execution condition for this tool (order fills when target price is reached). When-to-use and when-not-to-use are both covered explicitly.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond that by enumerating the return payload (output amount, fees, slippage, estimated time, memo) and by noting the memo is for executing the swap, implying a follow-up action. It does not say whether the quote expires or is a firm commitment, which is the notable remaining 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 sentences, front-loaded with the core action and followed by a use-case example and a return summary. Every sentence carries information and there is no filler.

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

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

With no output schema, the description usefully compensates by listing the fields returned, and the annotations cover the read-only nature. For a quoting tool it omits quote validity/expiry semantics and any indication of how fresh the estimate is, which an agent answering a user's swap question would want.

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 each of the six parameters documented, including base-unit conventions for amount and the 1000 bps affiliate cap. The description adds no parameter-level meaning 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 ('Calculate how much output you would receive when swapping one asset for another') and reinforces it with a concrete example question. It never names a sibling, so an agent must infer on its own why this differs from prepare_swap or quote_limit.

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 clear context for use ('Use this tool to answer questions like how much ETH would I get for 100 RUNE?'), which squarely frames it as a read-only estimation step. It stops short of stating exclusions or pointing to alternatives such as prepare_swap for actually executing, so the boundary with siblings is left implicit.

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