Read-only THORChain swap quotes, liquidity pools, and network status.
Scored across 3 tools
Each tool returns a distinct kind of data: network-level parameters, an asset-pair swap quote, and pool listings. There is no functional overlap or ambiguous boundary between them.
All tool names follow a verb_noun read-operation pattern. get_ is used for singular resources and list_ for the collection, which is a standard and internally consistent convention.
Three tools form a well-scoped, minimal surface for retrieving THORChain swap-related data. Each tool earns its place, and the count is not too thin for the narrow purpose.
The set covers network status, swap quotes, and pool data, which covers the core informational needs of a swap workflow. It lacks a direct tool for executing or broadcasting a swap, but that is likely intentionally outside scope.
Return current THORChain network parameters, including outbound fees, bond and reserve totals, and halt-related gas information. Pass fields to return only the keys you need.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Subset of top-level keys to return, e.g. ["native_outbound_fee_rune", "outbound_fee_multiplier"]. Omit for the full object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds content context but no significant behavioral traits beyond what the schema already states about omitting fields for the full 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 concise sentences. The main purpose is front-loaded, followed by a succinct usage hint for the optional parameter. 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?
The tool is simple with no required parameters, a single optional field, and annotations covering safety. The description specifies the return domain (network parameters with concrete categories) and how to limit results, which is adequate for an agent to invoke 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% for the single 'fields' parameter, including examples and default behavior. The description merely paraphrases this ('Pass fields to return only the keys you need'), adding no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and a specific resource ('current THORChain network parameters') with concrete examples (outbound fees, bond/reserve totals, halt-related gas info). This distinguishes it from siblings get_swap_quote and list_pools, which serve different purposes.
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 implies this tool is for network parameters but does not explicitly state when to use it versus the listed siblings or mention any exclusions. The only usage guidance is about the 'fields' parameter, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a THORChain swap quote for an asset pair. Assets use CHAIN.SYMBOL notation (e.g. BTC.BTC, ETH.ETH, ETH.USDC-0XA0B86991C6218B36C1D19D4A2E9EB0CE3606EB48). Amount is in 1e8 base units (1 BTC = 100000000). Quotes are indicative and expire quickly; the returned memo and inbound address must not be reused after expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to swap in 1e8 base units | |
| to_asset | Yes | Destination asset, e.g. ETH.ETH | |
| from_asset | Yes | Source asset, e.g. BTC.BTC | |
| destination | No | Optional destination address; required for a quote with a usable memo | |
| streaming_interval | No | Optional streaming swap interval in blocks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds valuable behavioral context: quotes are indicative, expire quickly, and the returned memo and inbound address must not be reused after expiry. This goes beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core purpose is front-loaded, and each sentence contributes necessary operational detail: asset format, amount units, and quote expiry behavior.
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?
Even without an output schema, the description reveals the key returned elements (memo and inbound address) and their expiration constraint, which is essential for correct use. A fuller enumeration of the quote response fields would be helpful, but the annotations and parameter schema cover the rest adequately.
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 baseline is 3. The description adds value by explaining CHAIN.SYMBOL notation globally and giving a concrete 1e8 base units example, reducing unit ambiguity beyond the schema's brief descriptions.
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: 'Fetch a THORChain swap quote for an asset pair.' It also clarifies asset notation and units, making the tool's job unmistakable and clearly distinct from siblings like get_network_status and list_pools.
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 provides clear context for when to use the tool: whenever a THORChain swap quote is needed. It also gives important timing guidance by warning that quotes expire quickly, though it does not explicitly discuss alternatives or exclusions—siblings are unrelated enough that this is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List THORChain liquidity pools with status, depths (1e8 base units), and USD asset price. Filter by pool status or by chain/asset to avoid pulling the full list.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Case-insensitive filter on the pool asset. A bare chain returns that chain only (ETH matches every ETH.* pool, not BASE.ETH); a CHAIN.SYMBOL value matches by prefix, so BTC.BTC returns one pool and ETH.USDC finds the contract-suffixed pool. | |
| limit | No | Maximum number of pools to return, largest RUNE depth first. Omit to return every match. | |
| status | No | Only return pools in this state. Available pools are the tradable ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by specifying depth units (1e8 base units), USD price inclusion, and the default behavior of returning the full list unless filters are applied.
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 focused sentences: the first states what the tool returns, the second provides filter guidance. Every phrase adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with zero required parameters and a fully descriptive schema, the description covers return contents, units, and filtering rationale. The annotations handle safety, and the schema handles parameter details, so 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 the input schema fully documents all three parameters. The description adds only a general mapping of filters to status and chain/asset, and does not need to go deeper because the schema already provides precise 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 begins with a specific verb and resource: 'List THORChain liquidity pools', and states the key returned data (status, depths, USD asset price). This clearly differentiates it from the siblings get_network_status and get_swap_quote, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use filters: 'Filter by pool status or by chain/asset to avoid pulling the full list.' It does not name alternative tools or exclusion conditions, but the purpose and sibling names make the appropriate contexts clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_network_statusget_swap_quotelist_poolsRead-only Bitcoin blockchain, mempool, mining, market, and on-chain analytics; no API key.
Read-only MCP for Rialto quotes and swap preflight on Robinhood Chain. No signing or broadcast.
Quote, create and track cross-chain crypto swaps. Non-custodial exchange, no account, no KYC.
Cross-network DeFi API data, AMM analytics, and SDK docs for 17+ networks.
Add one secure layer between your agents and this server.
