Skip to main content
Glama
Sign In
hypernatt-terminal

hypernatt-terminal

by DIALLOUBE-RESEARCH
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

get_liq_radar

Read-only

Returns modeled liquidation clusters, open interest and long/short context for a coin so agents can time entries and size positions, distinguishing noise from true liquidation zones.

Instructions

Returns the liquidation map of one coin (BTC, ETH, SOL, BNB, XRP, HYPE or ZEC; default BTC). If cluster_grammar is present, read it first: class=noise (distance <3%) is high-leverage bait to ignore; class=true (~7%+) is the low-leverage stack. The liq_radar block (hypernatt_liq_radar_v2) holds modeled liquidation clusters (zones where leveraged positions may liquidate), observed real_liquidations, open interest (OI) and long/short (L/S) context, and magnet.score (directional density bias from OI, L/S and funding; not a hit probability). USE WHEN an agent needs liquidation terrain for timing or sizing. NOT WHEN it needs order-book depth for a BTC/ETH size (use get_native_depth) or a swap (use swap_via_nattswap). Read-only; terrain, not a trade signal. Price: 0.001 USDC/call via x402 (Base or Solana) or eligible credits.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_liq_radar"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolNoOptional crypto symbol (BTC ETH SOL BNB XRP HYPE ZEC). Default BTC when omitted.
x_paymentNoBase64 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_walletNoOptional EVM wallet (0x + 40 hex). Skips x402 when swap-earned quota balance covers this tool's credit weight.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.11
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv1.0.10
    • addedInput schema / properties / symbol / enum
      Added value: +[
+  "BTC",
+  "ETH",
+  "SOL",
+  "BNB",
+  "XRP",
+  "HYPE",
+  "ZEC"
+]
    • changedInput schema / properties / x_payment / description
      Previous 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."
  3. Changed3 schema fields changedv1.0.3
    • changedInput schema / properties / agent_wallet / description
      Previous 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."
    • addedInput schema / properties / symbol
      Added value: +{
+  "description": "Optional crypto symbol (BTC ETH SOL BNB XRP HYPE ZEC). Default BTC when omitted.",
+  "type": "string"
+}
    • changedInput schema / properties / x_payment / description
      Previous 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."
  4. Changed2 schema fields changedv1.0.2
    • changedInput schema / properties / agent_wallet / description
      Previous value: -"Optional EVM wallet (0x…). Beta-grandfathered wallets skip x402."New 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)."
    • changedInput schema / properties / x_payment / description
      Previous value: -"Optional x402 payment payload (base64 JSON). Omit to receive 402 payment instructions."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.01/credit."
  5. Addedv1.0.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, non-destructive, open-world behavior, yet the description adds substantial context: the cluster_grammar interpretation rules (noise <3% vs true ~7%+), the caveat that magnet.score is a density bias rather than a hit probability, and the framing "terrain, not a trade signal." It also discloses the x402 pricing model at 0.001 USDC/call, which is real behavioral information the annotations do not carry; only the per-call cost/retry flow lacks detail.

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

Conciseness4/5

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

Front-loaded with the core purpose, then usage conditions, then return-content and pricing, which is a sensible order. It is dense and fairly long, but nearly every clause (grammar classes, NOT WHEN routing, magnet.score caveat) carries decision-relevant information rather than filler.

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

Completeness5/5

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

No output schema exists, so the description must describe the return shape, and it does: the hypernatt_liq_radar_v2 block, modeled clusters, real_liquidations, OI, L/S context, and magnet.score. Combined with usage routing and payment terms, an agent has everything needed to call it correctly.

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

Parameters3/5

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

Schema coverage is 100% and each property already documents itself, including the x402 rails and the first-call 402 handshake, so the schema handles the heavy lifting. The description restates the symbol set and default and echoes the price, which confirms but does not extend the parameter meanings.

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

Purpose5/5

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

States a specific verb and resource ("Returns the liquidation map of one coin") and enumerates the accepted symbols plus the BTC default, then immediately names the siblings it is not (get_native_depth, swap_via_nattswap). An agent can distinguish it from every listed alternative 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.

Usage Guidelines5/5

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

Has explicit USE WHEN ("needs liquidation terrain for timing or sizing") and NOT WHEN clauses that route to two named alternatives for order-book depth and swaps. Positive and negative conditions are both spelled out, leaving nothing to inference.

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

Deploy Server

Other Tools