No-KYC crypto swaps, no account or email. Read-only quotes, coins, swap links, order status.
Scored across 4 tools
Each tool has a clearly different focus: coin search, pair availability, pricing estimate, and order status. The only mild overlap is between get_pair_info and get_quote, since both can mention limits and estimates, but their descriptions make the distinction workable.
All tool names follow a consistent lowercase snake_case verb_noun pattern: get_order_status, get_pair_info, get_quote, and search_coins. The one semantic difference, search_coins vs get_*, is still predictable and matches the action being performed.
Four tools is well-scoped for a read-only informational server. Each tool covers a necessary part of the pre-swap and tracking workflow without padding or unnecessary duplication.
The server covers coin discovery, pair availability, quotes, and order tracking, which forms a complete read-only user journey. The main gap is that no tool creates or executes a swap, but the prefilled swap links intentionally direct users to hiddenswap.com for that step.
Check the stage of a HiddenSwap order by its order ID, for example awaiting deposit, confirming, swapping, sending, complete, needs support, refunded or expired. The order ID is private: anyone who has it can open the order page, which shows the addresses and amounts. Only use an order ID the person gave you, and never repeat it anywhere else. Returns the stage, a short label, whether it is final, when it last changed, and links to the order page and support. It never returns addresses, amounts or transaction hashes. Read-only. No account, no email and no ID needed to swap.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID the person saved when they started the swap. Private: only use one the person gave you. |
| Name | Required | Description |
|---|---|---|
| final | Yes | |
| label | Yes | |
| notes | Yes | |
| stage | Yes | |
| orderId | Yes | |
| orderUrl | Yes | |
| updatedAt | Yes | When the stage last changed (ISO 8601). |
| supportUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, it discloses the sensitive nature of the order ID, that the order page shows addresses and amounts, that the response never includes those fields, and that no account or credentials are required. This is rich behavioral context directly useful to an agent.
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?
Although longer than some tool descriptions, every sentence adds distinct value: purpose, privacy warning, usage rule, return contents, explicitly excluded data, and read-only/no-auth nature. The most important purpose and privacy constraints are 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?
Given the single-parameter schema, abundant annotations, and available output schema, this description is complete. It explains what the tool returns, what it deliberately does not return, and how to handle the sensitive order ID, leaving no significant gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents orderId, so this dimension starts at baseline 3. The description adds meaningful guidance: the order ID is private, must be one the person gave you, and should never be repeated elsewhere. That extra semantic layer justifies above 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?
The description clearly states the tool checks the stage of a HiddenSwap order by order ID, with a concrete verb and resource. It enumerates possible stages, which distinguishes it from sibling tools like get_quote and search_coins that 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 gives clear context: use it only when checking an order's stage using an order ID the person provided. It does not explicitly name sibling alternatives or state when not to use them, but the distinct domain makes the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether two coins can be swapped on HiddenSwap, a no-KYC crypto exchange, without asking for a live quote. Returns both coins with their networks, whether the pair can be swapped, fixed-rate support, the recorded limits and estimate when there are any, memo notes, the pair page and a prefilled swap link the person opens to finish on hiddenswap.com. Read-only. No account, no email and no ID needed to swap.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The coin received. Coin id from search_coins, for example btc, xmr or usdttrc20 (USDT on Tron). | |
| from | Yes | The coin sent. Coin id from search_coins, for example btc, xmr or usdttrc20 (USDT on Tron). | |
| amount | No | Optional. Amount of the coin sent, as a decimal string with a dot, for example "0.05". |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| from | Yes | |
| notes | Yes | |
| canSwap | Yes | |
| swapUrl | No | |
| recorded | No | |
| fixedRate | Yes | |
| pairPageUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive; the description reinforces this and adds useful context: no account/email/ID needed, returns recorded limits and estimates rather than live quotes, and includes a prefilled swap link. This shapes expectations about side effects and response nature. 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?
The first sentence carries the main purpose and key limitation; the following sentence is a dense but purposeful list of return fields. The no-KYC/read-only coda is useful context, not padding. Slightly long but efficient.
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 output schema exists and annotations cover safety, the description adds the missing behavioral and access context (no live quote, no KYC, returned elements). It is complete for an agent to decide when to call and what to expect, though it could be more explicit about sibling routing.
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%: from/to include examples and amount includes decimal-string format. The tool description does not add parameter semantics beyond that, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check whether two coins can be swapped') and resource (a HiddenSwap pair), and explicitly notes it does not provide a live quote, distinguishing it from get_quote. The title reinforces the action. Clear and non-tautological.
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 'without asking for a live quote' tells agents this is the pre-trade feasibility check, implying get_quote is the alternative for live pricing. It does not explicitly name get_quote or search_coins as alternatives, so guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate a crypto-to-crypto swap on HiddenSwap, a no-KYC crypto exchange. Returns the amount the person would receive after all fees, the rate, the minimum and maximum, the payout fee, the usual duration and a prefilled swap link. Uses a quote recorded in the last two hours when one matches the exact amount (floating rate only, labelled with its time), otherwise a live quote. Read-only: it creates no order and moves no funds. Coin ids come from search_coins (for example btc, xmr, usdttrc20). No account, no email and no ID needed to swap.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | The coin received. Coin id from search_coins, for example btc, xmr or usdttrc20 (USDT on Tron). | |
| from | Yes | The coin sent. Coin id from search_coins, for example btc, xmr or usdttrc20 (USDT on Tron). | |
| amount | Yes | Amount of the coin sent, as a decimal string with a dot, for example "0.05". | |
| rateType | No | float (default): the rate is set when the deposit is confirmed. fixed: a rate held once the swap is started on the site, when the pair offers one. | float |
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| max | No | |
| min | No | |
| from | Yes | |
| rate | Yes | How much of the received coin one unit of the sent coin buys, before the payout fee. |
| notes | Yes | |
| source | Yes | |
| swapUrl | Yes | Prefilled swap page. The person reviews and starts the swap there. |
| amountTo | Yes | Estimated amount received, after all fees. |
| quotedAt | Yes | When the quote was made (ISO 8601). |
| rateType | Yes | |
| payoutFee | No | Fee for sending the new coins, in the received coin. Already taken off amountTo. |
| amountFrom | Yes | |
| etaMinutes | No | Usual duration in minutes: low and high. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly, idempotent, and non-destructive, and the description reinforces this with concrete language ('creates no order and moves no funds'). It adds valuable behavior beyond annotations: cached quotes up to two hours for floating rates only, live quotes otherwise, and the fact that no account/email/ID is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and return value, then covers behavioral caveats, read-only safety, and prerequisites. Every sentence contributes meaningful information, and it remains compact despite covering several non-obvious behaviors.
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 output schema and annotations, the description is complete: it explains what is returned, when stale quotes are reused, that the operation is safe, how to source coin IDs, and that no auth is required. An agent has everything needed to invoke the tool correctly and interpret its behavior.
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 baseline is 3. The description repeats the coin-id relationship with search_coins and examples already present in the schema, but adds little genuinely new parameter-level meaning. The rateType parameter is covered well in the schema, so no penalty is needed, but the description does not elevate it above 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?
The description opens with a specific verb and resource: 'Estimate a crypto-to-crypto swap' on HiddenSwap. It clearly separates this from siblings like get_order_status, get_pair_info, and search_coins by emphasizing that it returns a quote with fees, rate, limits, payout fee, duration, and a prefilled link.
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 context for when to call the tool: when an estimate is needed, and it explicitly routes users to search_coins for valid coin IDs. It does not explicitly contrast against get_order_status or get_pair_info, but the purpose and prerequisite are clear enough for an agent choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the coin ids HiddenSwap uses, by ticker, name or network, for example "usdt tron", "monero" or "eth base". Each result gives the id to pass to the other tools, the network, whether the coin can be sent or received in a swap, whether a memo is usually needed, and the coin page when there is one. HiddenSwap is a no-KYC crypto exchange for crypto-to-crypto swaps. Read-only. No account, no email and no ID needed to swap.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | Only coins that can be sent (send) or received (receive) in a swap. | |
| limit | No | Most results to return (1 to 25). | |
| query | Yes | Ticker, name or network words, for example "usdt tron" or "monero". |
| Name | Required | Description |
|---|---|---|
| side | No | |
| coins | Yes | |
| notes | Yes | |
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive; the description reinforces this with 'Read-only' and adds behavioral details about the result: network, send/receive capability, memo requirement, and coin page. It also adds service context about no-KYC/no-account, which is slightly tangential but not contradictory.
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 tool purpose and query examples are front-loaded, and the description is reasonably compact. However, the no-KYC/no-account/no-ID sentence is largely product marketing rather than invocation guidance, and 'Read-only' duplicates the annotation, so not 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?
Given the low parameter count, full schema coverage, output schema, and annotations, the description is complete enough for correct invocation. It explains what the results contain and that the id is meant for other tools, leaving little ambiguity for an agent.
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 query, side, and limit are already documented. The description adds helpful example queries and clarifies that query covers ticker/name/network, but it does not materially expand on the side or limit parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Find the coin ids HiddenSwap uses, by ticker, name or network'. It also explains the results feed 'other tools', clearly distinguishing this lookup tool from siblings like get_quote, get_pair_info, and get_order_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever an agent needs a HiddenSwap coin id to pass to other tools. It does not explicitly name sibling alternatives or state when not to use it, but the id-passing framing implies the intended workflow and is sufficient for selection.
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_order_statusget_pair_infoget_quotesearch_coinsQuote, create and track cross-chain crypto swaps. Non-custodial exchange, no account, no KYC.
Native cross-chain swaps: Bitcoin, Ethereum, Solana, Polkadot, Tron, Arbitrum. Quote, swap, track.
Read-only THORChain swap quotes, liquidity pools, and network status.
Cross-chain swap aggregator across 16+ chains, incl. native Bitcoin/Solana. 0% fees, non-custodial.
Add one secure layer between your agents and this server.
