LiquidVision — Crypto Derivatives Data

get_hip3_markets

Read-onlyIdempotent

[measured] The HIP-3 board: Hyperliquid's builder-deployed perp markets (equity indices, stocks, commodities, pre-IPO names; coins named dex:COIN such as xyz:SP500) with what the live list alone cannot tell you. Per dex: OI, share, 24h/7d OI change, 24h volume, liquidations. Per market: mark, 24h change, OI and its 24h/7d change, 24h volume and turnover (volume/OI), hourly funding and APR, liquidations 24h/7d (count, USD, long share), and gap_bps = HIP-3 mark vs the mean mark of other venues listing the same underlying (Lighter, Ostium, gTrade). leaders lists OI growth/decline, funding extremes, most liquidated, widest gap. dex filters to one builder (xyz, io, para...); sort = oi | volume | funding | liq | gap | oi_change; limit caps the markets list. OI changes are null until the archive is that old (started 2026-10-31). No key needed.

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_hip3_markets"
  }
}

Input Schema

Name	Required	Description	Default
`dex`	No	HIP-3 builder dex id. Omit for all builder markets.
`sort`	No	Sort order of the result, as listed in the description.	oi
`limit`	No	Maximum number of rows to return.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / dex / description

Added value: +"HIP-3 builder dex id. Omit for all builder markets."

addedInput schema / properties / limit / description

Added value: +"Maximum number of rows to return."

addedInput schema / properties / sort / description

Added value: +"Sort order of the result, as listed in the description."

AddedOct 31, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description still contributes real operational context: no API key required, and OI change fields are null until the archive is old enough (started 2026-10-31), which prevents an agent misreading nulls as zero. It does not discuss rate limits or result truncation beyond the limit cap.

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 identity of the board, then the per-dex and per-market field inventory, then the parameters. Dense and jargon-heavy with fragment sentences, but essentially every clause carries information; a compact field list would be easier to scan than the flowing prose.

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?

With no output schema, the description carries the full burden and meets it: it enumerates per-dex and per-market metrics, defines derived fields (turnover = volume/OI, gap_bps as HIP-3 mark vs mean mark of Lighter/Ostium/gTrade), and describes the `leaders` block. The archive-age caveat closes the main remaining ambiguity about null values.

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%, so the schema is the baseline documentation. The description does add value by enumerating the sort enum values (oi | volume | funding | liq | gap | oi_change) that the schema only defers to, and by giving concrete dex ids (xyz, io, para), but limit is only restated as 'caps the markets list'.

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

Purpose4/5

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

Names a specific resource and scope: the HIP-3 board of Hyperliquid builder-deployed perps, enumerating the asset classes (equity indices, stocks, commodities, pre-IPO) and the coin naming convention (dex:COIN, e.g. xyz:SP500). It also states what it adds over a plain market list. It never distinguishes itself from the close-sounding sibling get_hl_builder_markets or from get_oi_board, so an agent cannot fully rule out overlap without reading schemas.

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?

The phrase 'with what the live list alone cannot tell you' implicitly routes the agent here instead of list_markets when it needs OI change, funding, liquidation, or cross-venue gap data, and the dex/sort/limit notes show how to narrow the call. There is no explicit when-not-to-use statement and no mention of the sibling builder-markets or OI-board tools.

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

All LiquidVision — Crypto Derivatives Data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?