Skip to main content
Glama

SiteCheck Crypto & Finance

Hyperliquid L1 perpetual market snapshot for one coin: best

crypto_hyperliquid_perps_depth
Read-only

Hyperliquid L1 perpetual market snapshot for one coin: best bid and ask, spread, USD depth within 1% of mid (from the 20 returned levels per side), mark and oracle prices, hourly funding rate, open interest in USD and 24h notional volume. Public market data only; vault PnL is not included. Related tools on this server, for a different need: finance_hyperliquid_perp_funding when you need Hyperliquid perpetual futures snapshot for one coin: mark; crypto_binance_orderbook_depth when you need Binance spot order book snapshot for one pair: best bid. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": "crypto_hyperliquid_perps_depth"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinNoHyperliquid perp name, e.g. BTC, ETH, SOL

Output Schema

NameRequiredDescriptionDefault
coinNo
sourceNo
bestAskNo
bestBidNo
midPriceNo
checkedAtNo
markPriceNo
spreadPctNo
maxLeverageNo
oraclePriceNo
change24hPctNo
levelsPerSideNo
depthWithin1pctNo
openInterestUsdNo
openInterestCoinsNo
dayNotionalVolumeUsdNo
fundingRatePerHourPctNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds materially more: depth is computed from the 20 returned levels per side, data is public-only with vault PnL excluded, and each successful call costs $0.002 USDC via x402 on Base/Solana/Arc with failures uncharged. The cost and payment path is exactly the kind of behavior an agent must know before invoking.

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 resource and its contents, then exclusions, then alternatives, then price — a logical order with no filler. The sibling-tool sentence is somewhat verbose because each alternative is restated with its own truncated field list, but every clause still carries routing or cost information.

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?

The tool has one optional parameter, full schema coverage, an output schema, and read-only annotations, so the remaining burden is scope, exclusions, and cost — all covered. It even clarifies what is excluded (vault PnL) and the billing behavior on failure, which is more than a single-coin market snapshot strictly requires.

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 the single `coin` property already documents 'Hyperliquid perp name, e.g. BTC, ETH, SOL'. The description adds only the constraint that the snapshot is for one coin, without extra syntax, casing, or fallback rules, so it neither compensates nor detracts. Baseline 3 applies when the schema carries the parameter semantics.

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?

Names a specific resource (Hyperliquid L1 perpetual market snapshot) and an explicit scope (one coin), then enumerates exactly what is returned: best bid/ask, spread, USD depth within 1% of mid, mark/oracle prices, hourly funding, open interest and 24h volume. An agent can distinguish this from finance_hyperliquid_perp_funding and crypto_binance_orderbook_depth from the description alone.

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

Usage Guidelines4/5

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

Explicitly routes away two siblings: finance_hyperliquid_perp_funding 'when you need Hyperliquid perpetual futures snapshot for one coin: mark' and crypto_binance_orderbook_depth for Binance spot books. That gives clear context for selecting this tool, though it does not state the negative case (e.g., when not to use a Hyperliquid snapshot at all, such as non-perp or non-Hyperliquid venues).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources