BTC Decision Terminal for AI Agents — live vault-backed signals, on-chain proof, cross-chain swap. Verify in real time.
Start here (free, compact): 3 tools + prices + cluster do_not + honest usage. Pass detail=full for quota/pass/onboarding. Then get_liq_radar.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Default compact. full = quota/pass/onboarding. | |
| locale | No | Not a translation switch. Ignored. Catalog is English only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is free, compact by default, and that passing detail=full provides additional quota/pass/onboarding info. However, terms like 'cluster do_not' and 'honest usage' are undefined, and no mention is made of side effects, permissions, or rate limits. It adds some context but leaves significant 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?
The description is concise at three sentences and front-loaded with 'Start here'. Each sentence serves a purpose: what it does, how to get more, and what to do next. However, the first sentence is dense and cryptic, using jargon that may confuse.
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 tool with two optional parameters and no output schema, the description gives a high-level summary of contents but leaves key terms ('cluster do_not', 'honest usage') undefined. It also doesn't clarify how this relates to swap_via_nattswap. It's adequate but not comprehensive.
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's parameter guidance ('Pass detail=full for quota/pass/onboarding') restates the schema's detail description without adding new semantics. The locale param is already well explained in the schema as ignored.
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 indicates the tool is a starting point that provides a catalog of 3 tools, prices, a cluster do-not list, and honest usage info. The verb is implicit ('Start here') and phrasing is cryptic, but it clearly positions itself as an entry point and differentiates from the sibling get_liq_radar by ordering the workflow.
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' and 'Then get_liq_radar', establishing a clear usage sequence. It also advises using detail=full for quota/pass/onboarding, giving concrete parameter guidance. While it doesn't mention swap_via_nattswap, the primary alternative is addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
If cluster_grammar is present, read it before liq_radar. class=noise (<3%) is high-leverage bait — ignore. class=true (~7%+) is the low-leverage stack. Terrain, not a signal. Also magnet, OI, L/S, clusters, real liqs. Whitelist BTC ETH SOL BNB XRP HYPE ZEC (omit=BTC). USE WHEN: terrain / timing / sizing. NOT a trade signal. RETURNS: hypernatt_liq_radar_v2. COST: $0.001 x402 (Base or Solana). Side effects: none.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Optional crypto symbol (BTC ETH SOL BNB XRP HYPE ZEC). Default BTC when omitted. | |
| x_payment | No | Base64 x402 USDC payment. Rails: Base eip155:8453 (EIP-3009) OR Solana SVM exact (@x402/svm; not an EVM signature). Omit on first call to receive 402 accepts[]; retry after paying $0.001/call. | |
| agent_wallet | No | Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses cost ($0.001 x402), payment rails (Base or Solana), return object type, and explicitly 'Side effects: none'. It also tells the agent how to interpret the data class, which is useful behavioral context beyond what annotations would cover. It does not describe the 402-retry flow, but that is covered in the x_payment parameter description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-labeled with USE WHEN, NOT, RETURNS, COST, and Side effects, making key decision points easy to locate. The sequencing instruction is front-loaded, and no sentence is wasted even though the tone is terse and jargon-heavy.
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-parameter, read-only style tool with no output schema, the description gives enough: return type, cost, payment rails, context records, and side effects. It does not fully define the structure of hypernatt_liq_radar_v2 or clarify what happens on payment denial, but those are partially inferred from x_payment 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 description coverage is 100%, so the schema already documents all three parameters. The description adds minimal new parameter semantics: it repeats the strong whitelist and default BTC behavior already stated in the symbol schema, and mentions x402 rails already covered. It argues domain interpretation of output data, but doesn't materially enrich parameter 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 clearly positions the tool as a liquidity-radar data reader: it returns hypernatt_liq_radar_v2, focuses on magnet, OI, L/S, clusters, real liqs, and frames its role as terrain/timing/sizing rather than trade execution. This distinct from the sibling swap_via_nattswap and get_agent_manifest. However, the purpose is never stated in a plain 'Gets liquidity data' style and relies on domain jargon, so it is not 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 description gives explicit when-to-use ('USE WHEN: terrain / timing / sizing') and when-not-to-use ('NOT a trade signal') guidance, and even prescribes a sequence ('If cluster_grammar is present, read it before liq_radar'). It does not name a specific alternative tool for trade execution, so it stops short of fully explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-chain token swap powered by Li.Fi across 70+ chains incl. Hyperliquid. USE WHEN: bridge, fund gas, treasury routing, or rebalance. RETURNS: Li.Fi route + execution_readiness + swap_actions_v1. Prefer signing swap_actions_v1 in order. MCP free; on-chain swap costs gas + HyperNatt 0.5% integrator fee (Li.Fi may add its own cut — read quote.estimate.feeCosts). Side effects: MCP read-only until wallet signs.
| Name | Required | Description | Default |
|---|---|---|---|
| toChain | Yes | Destination Li.Fi chain id | |
| toToken | Yes | Destination token contract address on toChain | |
| slippage | No | Max slippage percent (e.g. 0.5 for 0.5%) | |
| fromChain | Yes | Source Li.Fi chain id (e.g. 1 Ethereum, 8453 Base, 42161 Arbitrum) | |
| fromToken | Yes | Source token contract address on fromChain | |
| toAddress | Yes | Recipient wallet 0x + 40 hex chars | |
| fromAmount | Yes | Amount in token smallest units (wei for 18-decimal tokens) | |
| fromAddress | Yes | Sender wallet 0x + 40 hex chars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses that the MCP call is read-only until the wallet signs, details on-chain gas costs and the 0.5% HyperNatt fee, and notes that Li.Fi may add its own cut, instructing the user to read quote.estimate.feeCosts. It also recommends signing swap_actions_v1 in order, providing clear operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear 'USE WHEN:', 'RETURNS:', and 'Side effects:' labels. The opening sentence immediately establishes purpose, and every clause adds relevant information (fees, signing order). 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?
Given a complex swap tool with 8 parameters and no output schema, the description covers purpose, usage, return values, fees, and side effects. It could elaborate slightly on what 'execution_readiness' means, but the provided instruction to sign swap_actions_v1 in order gives sufficient operational guidance. Overall, it is highly comprehensive for the 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?
The input schema already provides 100% description coverage for all 8 parameters, so the baseline is 3. The description does not add parameter-level details beyond the schema; it focuses on fees and execution flow. It meets the baseline but does not exceed it.
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 explicitly states 'Cross-chain token swap powered by Li.Fi across 70+ chains', providing a specific verb and resource. It also lists concrete use cases (bridge, fund gas, treasury routing, rebalance), clearly differentiating it from sibling tools like get_agent_manifest and get_liq_radar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'USE WHEN:' section with concrete scenarios (bridge, fund gas, treasury routing, rebalance). This gives clear context for when to invoke the tool, and while it doesn't name alternative tools, the listed use cases are actionable and sufficient for decision-making.
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. Dates show when Glama detected each change.
get_liq_radar1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"Base64 x402 USDC payment on Base (eip155:8453). Omit on first call to receive 402 payment instructions; retry with header after paying $0.001/call."New value: +"Base64 x402 USDC payment. Rails: Base eip155:8453 (EIP-3009) OR Solana SVM exact (@x402/svm; not an EVM signature). Omit on first call to receive 402 accepts[]; retry after paying $0.001/call."get_agent_manifest2 fields changedInput schema / properties / detailAdded value: +{
+ "description": "Default compact. full = quota/pass/onboarding.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / locale / descriptionPrevious value: -"en or fr (default en)"New value: +"Not a translation switch. Ignored. Catalog is English only."get_btc_usdc_signalget_entry_qualityget_ignitionget_liq_radar2 fields changedInput schema / properties / agent_wallet / descriptionPrevious value: -"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight (1 credit per Decision Core tool)."New value: +"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight."Input schema / properties / symbolAdded value: +{
+ "description": "Optional crypto symbol (BTC ETH SOL BNB XRP HYPE ZEC). Default BTC when omitted.",
+ "type": "string"
+}get_mm_hunt_scoreget_mm_trap_stateget_orderflowget_regimeget_similarity_matchget_ta_snapshotget_trading_hubget_vault_proofswap_quoteget_entry_qualityget_ignitionget_orderflowget_regimeget_ta_snapshotget_trading_hubget_liq_radar1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"Base64 x402 USDC payment on Base (eip155:8453). Omit on first call to receive 402 payment instructions; retry with header after paying $0.01/credit."New value: +"Base64 x402 USDC payment on Base (eip155:8453). Omit on first call to receive 402 payment instructions; retry with header after paying $0.001/call."get_mm_trap_state1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"Base64 x402 USDC payment on Base (eip155:8453). Omit on first call to receive 402 payment instructions; retry with header after paying $0.01/credit."New value: +"Base64 x402 USDC payment on Base (eip155:8453). Omit on first call to receive 402 payment instructions; retry with header after paying $0.001/call."get_liq_radar1 field changedInput schema / properties / agent_wallet / descriptionPrevious value: -"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight (2 for liq_radar/mm_trap_state)."New value: +"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight (1 credit per Decision Core tool)."get_mm_trap_state1 field changedInput schema / properties / agent_wallet / descriptionPrevious value: -"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight (2 for liq_radar/mm_trap_state)."New value: +"Optional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight (1 credit per Decision Core tool)."get_natt_performanceclaim_ndatget_agent_balanceget_referral_linkregister_nattswap_rewardClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
The three tools are cleanly separated: one handles manifest/onboarding, one delivers liquidity radar data, and one executes swaps. The descriptions explicitly guide the intended order, so an agent is unlikely to choose the wrong tool.
The get_ prefix is used for the two read-oriented tools, and swap_via_nattswap is clearly an action tool. Everything uses snake_case and predictable verbs; the only minor deviation is the longer via_nattswap suffix on the swap tool.
Three tools is a tightly scoped set and each one earns its place: understand the server, read market terrain, act with a swap. The manifest even confirms the intentional three-tool design.
The tools form a coherent manifest-to-radar-to-swap workflow with no hard dead end. There are minor gaps such as no separate balance/status check or swap-history tool, but these feel outside the core scope rather than blocking.