This server provides nine read-only tools for querying public Hyperliquid and cross-exchange market data, requiring no API keys or wallets.
Analyze Hyperliquid wallets: Retrieve positions, balances, orders, leverage, PnL, and fees for a public address.
Get HYPE market snapshots: Fetch live HYPE spot/perpetual prices, basis, 24h change, notional, and convert between HYPE and USD.
List active Hyperliquid TWAPs: View active TWAP schedules with estimated notional, filterable by side, market, and size.
Calculate Hyperliquid fees: Estimate trading fees based on notional, role, tier, and discounts, all locally.
Summarize large trader positions: Aggregate long/short exposure across a monitored cohort, sortable by notional, holders, or PnL.
List top position holders: Rank the largest positions in a market within the cohort, filterable by side and sortable by notional, PnL, or leverage.
List Hyperliquid funding rates: View current funding rates, open interest, 24h notional, and optional trailing 24h sums.
Scan cross-exchange funding spreads: Compare funding rates across Binance, OKX, and Hyperliquid; estimate net carry and break-even time.
Scan cross-exchange perpetual price spreads: Compare best bid/ask quotes with taker fee estimates and capacity checks, identifying price divergences.
Provides cross-exchange funding rate and perpetual price spread comparisons with other venues, including top-of-book quotes and fee estimates for Binance USD-M markets.
Provides cross-exchange funding rate and perpetual price spread comparisons with other venues, including top-of-book quotes and fee estimates for OKX markets.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@market-depth-lab-mcp Compare BTC funding across Binance, OKX, and Hyperliquid."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only Hyperliquid and cross-exchange market research for AI agents.
🌐 Project website and live dashboards: marketdepthlab.com
Every MCP result points back to Market Depth Lab, where the public dashboards, methodology and related research live.
Market Depth Lab MCP gives Claude, Codex, Cursor and other MCP clients nine structured tools for public Hyperliquid and cross-exchange market data. It does not request a private key, wallet signature, exchange login or permission to trade.
Independent open-source software. Not affiliated with or endorsed by Hyperliquid. Research information only; not financial advice.
Useful on the first call: live HYPE, funding, wallet, TWAP and cross-exchange spread queries.
Read-only by design: no order placement, signing or wallet mutation.
Honest coverage: monitored-address rankings are labeled as a cohort, not a protocol-wide holder census.
Agent-friendly output: each tool returns concise text and stable
structuredContent.
Traceable: results include source, time/coverage boundaries and one stateful link to the corresponding Market Depth Lab tool.
Related MCP server: Alpha Arena MCP
Tool | What it answers |
| Which public TWAP schedules are active, and what is their estimated current notional? |
| What positions, balances, orders, leverage and PnL are visible for this public address? |
| What would the estimated fee be for this notional, role and fee tier? |
| What is HYPE worth now, and how do spot and perps compare? |
| How is the monitored large-trader cohort positioned by market? |
| Which monitored addresses have the largest positions in one market? |
| Who pays funding now, and what is the exact trailing-24h sum for the returned markets? |
| Where is the largest normalized funding difference across Binance USD-M, OKX and Hyperliquid, after a user-supplied cost estimate? |
| Where do current perpetual best bids and asks diverge across venues, after fee estimates and a visible top-of-book capacity check? |
The three concepts are deliberately separate:
hyperliquid_list_funding_rates describes the current Hyperliquid main
and HIP-3 funding universe, including exact trailing-24h sums for the
returned page.
scan_cross_exchange_funding_spreads normalizes one-hour and eight-hour
settlement intervals, then compares a lower-funding long leg with a
higher-funding short leg. Its annualized number is a comparison, not a
forecast.
scan_cross_exchange_perp_price_spreads compares public top-of-book
quotes. It reports both entry-fee and round-trip-fee views, plus the
smaller visible notional on the selected bid/ask levels. OKX contract
counts are converted with the public instrument ctVal before notional
is calculated.
The scanners are original TypeScript implementations informed by the read-only monitoring workflow used in Market Depth Lab's local research. They do not vendor or modify the reference Python projects.
Neither scanner places orders. A row is a screening candidate, not proof of executable or risk-free arbitrage. Funding can change; REST snapshots are not simultaneous; Binance/OKX normally settle in USDT while Hyperliquid main perps settle in USDC; and deeper-book slippage, transfers, margin, liquidation, venue access and close-out prices remain outside the estimate.
Node.js 20 or newer
Internet access for public Hyperliquid/HypurrScan data
No API key
The public package is
market-depth-lab-mcp-server.
Use this configuration in an MCP client that supports local stdio servers:
{
"mcpServers": {
"market-depth-lab": {
"command": "npx",
"args": ["-y", "market-depth-lab-mcp-server"]
}
}
}npx downloads the published package and starts the local read-only MCP
process. No exchange login, wallet connection or API key is required.
git clone https://github.com/derkcc/market-depth-lab-mcp.git
cd market-depth-lab-mcp
npm ci
npm run buildUse the absolute path to dist/index.js in your MCP client:
{
"mcpServers": {
"market-depth-lab": {
"command": "node",
"args": ["/absolute/path/to/market-depth-lab-mcp/dist/index.js"]
}
}
}Use the source checkout when you want to review or modify the implementation; use the npm configuration above for the shortest installation path.
Show the five Hyperliquid markets with the highest absolute current funding.
Include trailing 24h funding and explain who pays whom.Compare BTC, ETH, SOL and HYPE funding on Binance, OKX and Hyperliquid.
Assume a 24-hour holding period and 12 bps of total round-trip costs. Show
the current annualized spread, projected net carry and break-even hours.Scan BTC, ETH and SOL perpetual top-of-book spreads across Binance, OKX and
Hyperliquid. Use round-trip taker fees, require at least $5,000 visible at
the selected levels, and explain every non-execution boundary.Analyze 0x... on Hyperliquid. Summarize gross exposure, effective leverage,
largest position and recent realized PnL. Do not give trading advice.Within the monitored cohort, list the top BTC positions and separate longs
from shorts. State the cohort boundary before the ranking.Estimate round-trip taker fees for a $25,000 tier-zero perpetual position.Capability | Data path |
HYPE, wallet and Hyperliquid funding | Your local MCP process → public Hyperliquid |
Cross-exchange funding spreads | Your local MCP process → public Binance USD-M, OKX and Hyperliquid market-data APIs |
Cross-exchange price spreads | Your local MCP process → public Binance USD-M and OKX book-ticker APIs plus Hyperliquid |
Active TWAPs | Your local MCP process → public HypurrScan endpoint, plus Hyperliquid price references |
Large positions and top holders | Your local MCP process → Market Depth Lab's rolling read-only position index |
Fee calculator | Runs locally; no network request |
The server has no analytics or telemetry. A wallet address submitted to
analyze_hyperliquid_wallet is sent directly from your machine to the public
Hyperliquid API. Position-index calls use
https://data.marketdepthlab.com/v1/positions/latest.
Public exchange endpoints can be unavailable in some regions. Both
cross-exchange tools expose per-venue available, partial or unavailable
coverage and their error messages. They never silently claim that a
two-venue or three-venue comparison was complete.
Market Depth Lab rotates through a monitored pool of public addresses. The index is useful for cohort-level market structure, but it is:
not a list of every Hyperliquid account;
not a simultaneous snapshot of all monitored addresses;
not proof of who controls an address;
not a recommendation to copy any address.
Every position tool reports the snapshot time, age, monitored-address count, staleness state and coverage boundary.
All variables are optional.
Variable | Default | Purpose |
|
| Remote read-only position index |
| unset | Load a local JSON snapshot instead of the remote index |
|
| Mark a position snapshot stale after this age |
|
| Return an error instead of labeled stale data |
|
| Per-request network timeout |
When MDL_POSITION_INDEX_PATH is set, the two position tools do not make a
network request. Other live-data tools still use public upstream APIs.
npm ci
npm run check
npm test
npm pack --dry-runThe test suite performs an in-memory MCP handshake, verifies the nine tool definitions and calls the local fee tool through the protocol. Live upstream smoke tests should be run before each release, but are intentionally excluded from deterministic CI.
Website: https://marketdepthlab.com
Live tools: https://marketdepthlab.com
Issues: GitHub Issues
Security: SECURITY.md
Contributing: CONTRIBUTING.md
Read the public main-account state for one Hyperliquid address: perpetual positions, spot balances, open orders, recent fills, exposure, leverage, PnL and fee totals. No private key, signature or wallet connection is requested.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Public EVM wallet address. | |
| recent_fill_limit | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations by specifying that no authentication is needed and that the tool reads public data. This reinforces the non-destructive, public nature of the operation.
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 a single, well-structured sentence that front-loads the key purpose and then lists what data is included. No extraneous words.
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 existence of an output schema (not shown), the description effectively covers purpose, parameters, and data scope. It does not mention rate limits or pagination, but these are minor gaps for a read-only wallet state tool.
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?
With schema description coverage at 50% (only 'address' has a schema description), the tool's description compensates by explaining the purpose of the 'recent_fill_limit' parameter implicitly (through listing 'recent fills' in the output) and clarifying that the 'address' must be public and on Hyperliquid. This adds meaning beyond the schema.
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 uses a specific verb ('Read') and clearly identifies the resource (public main-account state for a Hyperliquid address). It lists the exact data components (perpetual positions, spot balances, etc.) and distinguishes from sibling tools that focus on market snapshots, fees, or top holders.
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 explicitly states this is a read-only operation requiring no private key or wallet connection, which guides appropriate use. However, it does not explicitly mention when not to use this tool (e.g., for historical data) or suggest alternative sibling tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate Hyperliquid spot or perpetual trading fees from notional, maker/taker role, fee tier, discounts, asset multiplier, maker rebate, and builder fee. This is a transparent estimate, not an exchange quote.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | taker | |
| tier | No | Hyperliquid fee tier, 0 through 6. | |
| sides | No | 1 for entry only, 2 for entry plus exit. | |
| market | No | perps | |
| notional_usd | Yes | One-side trade notional. | |
| builder_fee_bps | No | ||
| asset_fee_multiplier | No | ||
| maker_rebate_percent | No | ||
| staking_discount_percent | No | ||
| referral_discount_percent | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, and non-destructive. The description adds that this is a transparent estimate, not an exchange quote, providing important behavioral context beyond the annotations. 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?
Two concise sentences with all essential information front-loaded. No extraneous 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 the tool's complexity (10 params, output schema exists), the description provides a high-level overview but lacks details on edge cases, rounding, or assumptions. It is mostly complete for a simple estimate tool.
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 description lists categories of parameters (notional, role, tier, discounts, etc.) but does not detail their meanings or constraints. Schema coverage is only 30%, so the description partially compensates but falls short of fully explaining the 10 parameters.
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 estimates Hyperliquid spot or perpetual trading fees, listing the inputs and distinguishing it from an exchange quote. The verb 'estimate' and resource 'Hyperliquid trading fees' are specific and unambiguous.
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 mentions the tool provides a transparent estimate, not a quote, but does not specify when to use this tool versus alternatives or when not to use it. Sibling tools are unrelated, so no explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a live HYPE spot/perpetual snapshot from Hyperliquid and convert either HYPE to USD or USD to HYPE. Reports spot-perp basis, 24h spot change, and 24h spot notional when available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds 'live' and specific return fields but lacks additional behavioral context like data freshness or rate limits.
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?
Two sentences, no unnecessary words, front-loaded with purpose, and no fluff.
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 zero-parameter tool with output schema and rich annotations, the description covers essential functionality and edge cases (e.g., 'when available') completely.
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?
No parameters exist, so baseline 4 applies. The description mentions conversion direction implicitly, but with zero parameters, no further semantic addition is needed.
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 fetches a live HYPE snapshot from Hyperliquid and converts between HYPE and USD, reporting specific metrics. It distinguishes itself from sibling tools which focus on fees, wallets, positions, etc.
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 implies usage for quick market snapshots and conversions, and the sibling context makes differentiation easy. However, no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List current main-perpetual and HIP-3 funding, open interest, 24h notional and basis. Optionally computes exact trailing-24h funding for only the returned page to limit upstream requests.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| payer | No | all | |
| query | No | ||
| offset | No | ||
| sort_by | No | absolute_rate | |
| market_type | No | all | |
| include_trailing_24h | No | ||
| min_open_interest_usd | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, open world, idempotent, and non-destructive. The description adds valuable context about optionally computing exact trailing-24h funding only for the returned page, which involves upstream requests, thus enhancing transparency beyond annotations.
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 consists of two concise sentences: the first clearly states the main purpose, and the second adds an important optional behavior. No redundancy or filler content.
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?
While the description covers the primary data returned and the optional trailing-24h feature, it omits details on sorting, filtering, pagination, and market type filtering. Given the 8-parameter complexity and availability of an output schema, the description is adequate but leaves gaps in parameter semantics.
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 has 8 parameters with 0% description coverage. The description only vaguely implies the 'include_trailing_24h' parameter but does not explain 'limit', 'offset', 'sort_by', 'market_type', or other key parameters, leaving the agent to infer from default values and enums alone.
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 it lists current funding rates, open interest, 24h notional, and basis for main-perpetual and HIP-3 markets. It distinguishes itself by mentioning optional trailing-24h computation, setting it apart from siblings which focus on other aspects.
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 implies usage for listing funding data with optional trailing-24h calculation but does not explicitly state when to use this tool versus alternatives like hyperliquid_summarize_large_trader_positions or scan_cross_exchange_funding_spreads. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the largest current positions for one canonical market inside Market Depth Lab's monitored public-address cohort. Rankings are cohort-relative and the index retains only the published top positions per market.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | all | |
| limit | No | ||
| market | Yes | Canonical market, for example BTC or xyz:NVDA. | |
| offset | No | ||
| sort_by | No | position_notional | |
| address_query | No | ||
| min_position_notional_usd | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint): it notes that rankings are 'cohort-relative' and that the index 'retains only the published top positions per market'. This helps the agent understand limitations.
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?
Two sentences, front-loaded with the core purpose, no fluff or redundant information.
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 tool with 7 parameters and limited schema descriptions, the description covers the core function adequately but lacks details on filtering and sorting options. The presence of an output schema reduces the need to explain return values, but more parameter context would improve completeness.
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 only 14% (only 'market' has a description). The description does not describe any parameters, failing to compensate for the low coverage. Parameters like side, limit, offset, and sort_by are left to be inferred from their names.
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 uses a specific verb ('List') and resource ('largest current positions'), scoped to 'one canonical market inside Market Depth Lab's monitored public-address cohort'. This clearly distinguishes it from sibling tools like list_active_hyperliquid_twaps or hyperliquid_list_funding_rates.
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?
No explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description, but no exclusions or comparative advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate current long and short exposure by market within Market Depth Lab's rolling monitored-address cohort. This is not a protocol-wide holder census or a simultaneous snapshot of every address.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| sort_by | No | gross_notional | |
| direction | No | all | |
| market_type | No | all | |
| min_gross_notional_usd | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false) already disclose safety and idempotence. The description adds behavioral insight beyond annotations by revealing the data source is a subset cohort, not a full snapshot, and that positions are aggregated. This provides meaningful context about output limitations not captured in annotations.
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?
Two sentences, no filler, front-loaded with the core action and scope. Every word serves a purpose. The structure is optimal for quick scanning by an AI agent.
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 complexity of 7 parameters (several with enums) and zero schema descriptions, the description is insufficient for the agent to use the tool correctly. It covers purpose but fails to explain parameter selection, defaults, or how to filter results. The output schema exists but does not offset the lack of input guidance. A 2 reflects the significant missing context for a tool with this many parameters.
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 0%, and the description provides no parameter explanations whatsoever. Parameters like sort_by, direction, market_type have enums but no textual hints about their effect. The agent must infer meaning purely from names and enum values, which is insufficient for seven parameters, especially with no defaults described for behavior. This is a critical gap.
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 aggregates long and short exposure by market within a specific cohort (Market Depth Lab's rolling monitored-address cohort). It uses a specific verb ('aggregate') and resource ('exposure by market'), and explicitly distinguishes itself from a protocol-wide holder census, leaving no ambiguity about its scope.
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 provides clear negative guidance by stating what the tool does not do (not a protocol-wide census or simultaneous snapshot), helping the agent avoid misuse. However, it does not explicitly recommend when to use this tool over siblings like hyperliquid_list_top_position_holders or provide positive usage context. The clarity of exclusion earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List publicly visible active Hyperliquid TWAP schedules and estimate current notional using live market references. Schedule time is known; execution progress and unfilled quantity are not inferred.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | all | |
| limit | No | ||
| query | No | ||
| offset | No | ||
| sort_by | No | estimated_notional | |
| market_type | No | all | |
| min_estimated_notional_usd | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint. The description adds that notional is estimated using live market references and clarifies that execution progress and unfilled quantity are not inferred, providing useful behavioral context.
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?
Two sentences, front-loaded with the core purpose, and a second sentence clarifying limitations. No unnecessary words.
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?
While output schema exists, the lack of parameter documentation makes the tool difficult to use effectively. The agent cannot infer key details like what 'query' filters on or what 'hip3' market type means. Significant gaps for a tool with 7 parameters.
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 0%, yet the description provides no explanation of any of the 7 parameters (side, limit, query, offset, sort_by, market_type, min_estimated_notional_usd). The agent has no insight into parameter meanings beyond their names and default values.
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 lists active Hyperliquid TWAP schedules and estimates notional, distinct from sibling tools which cover snapshots, fees, positions, etc.
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 specifies the tool is for listing publicly visible active TWAPs, implying its use case. It does not explicitly mention when not to use or alternatives, but sibling tools are clearly different in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare current perpetual funding on Binance USD-M, OKX and Hyperliquid. For each symbol, the scanner pairs a long on the lower hourly funding rate with a short on the higher rate, normalizes different settlement intervals, and estimates gross carry, user-supplied costs and break-even time. It does not place orders or describe the result as risk-free arbitrage.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| venues | No | Two or three venues to compare. | |
| symbols | No | Base symbols to scan, for example BTC, ETH, SOL or HYPE. Maximum 12 per call. | |
| holding_hours | No | ||
| round_trip_cost_bps | No | User estimate for all entry, exit, fee and slippage costs across both legs. Zero means gross carry only. | |
| minimum_annualized_spread_percent | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not conflict. It adds value by disclosing that the tool does not place orders and that its output is not risk-free arbitrage, and it explains the pairing and normalization logic. No contradictions found.
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, containing two well-structured sentences that convey essential information without redundancy or unnecessary detail.
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 tool's moderate complexity (6 parameters, output schema exists) and the presence of sibling tools, the description covers the main workflow and outputs (gross carry, costs, break-even time). However, it does not detail output structure or data freshness, but the output schema presumably fills that gap.
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 50% (some parameters have descriptions, some do not). The description clarifies the overall computation (e.g., holding hours relates to break-even time, round_trip_cost_bps is 'user-supplied costs'), but it does not explicitly map to parameters like limit or minimum_annualized_spread_percent. This adds some context but is not fully compensatory.
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 uses a specific verb ('compare') and clearly identifies the resource ('perpetual funding on Binance USD-M, OKX and Hyperliquid'). It distinguishes from sibling tools like 'scan_cross_exchange_perp_price_spreads' by focusing on funding spreads rather than price spreads.
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 states what the tool does (compare funding spreads for carry estimation) and explicitly notes what it does not do (place orders, describe as risk-free arbitrage). However, it does not provide explicit when-to-use or when-not-to-use guidance relative to alternative tools, though the sibling list implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare best bid and ask quotes for selected perpetual symbols on Binance USD-M, OKX and Hyperliquid. The engine ranks the cheapest cross-venue buy against the richest cross-venue sell, reports top-of-book capacity and subtracts configurable taker-fee estimates. It is a persistent-divergence screen, not a latency-arbitrage or order-execution tool.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| venues | No | Two or three venues to compare. | |
| symbols | No | Base symbols to scan, for example BTC, ETH, SOL or HYPE. Maximum 12 per call. | |
| cost_basis | No | round_trip_fees | |
| minimum_net_bps | No | ||
| okx_taker_fee_bps | No | ||
| binance_taker_fee_bps | No | ||
| hyperliquid_taker_fee_bps | No | ||
| minimum_top_of_book_notional_usd | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | Structured tool result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: it is a screening tool that subtracts configurable fees and reports top-of-book capacity, reinforcing its nondestructive, stable nature.
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?
Three sentences, no redundant information. The purpose is stated in the first sentence; additional clarification follows efficiently.
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 tool with 9 parameters and output schema, the description covers core functionality and usage boundaries. It doesn't explain every parameter in depth, but the schema and annotations fill many gaps. Overall adequate for the 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?
Schema coverage is 22%, so description must compensate. Description mentions 'selected symbols', 'taker-fee estimates', 'top-of-book capacity', and 'cross-venue' which maps to some parameters (symbols, fees, limit, venues). However, details like cost_basis, minimum_net_bps, and minimum_top_of_book_notional_usd are not elaborated, leaving gaps.
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?
Description uses specific verbs ('Compare', 'ranks') and resources ('best bid and ask quotes for perpetual symbols on Binance USD-M, OKX and Hyperliquid'). It clearly states the tool's output (ranked cross-venue spreads with fees) and explicitly distinguishes itself from latency-arbitrage or execution tools.
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?
Description defines the tool as a 'persistent-divergence screen' and explicitly states what it is not ('not a latency-arbitrage or order-execution tool'). This gives clear guidance on when to use it. It doesn't mention alternatives but sibling tools (e.g., scan_cross_exchange_funding_spreads) provide context.
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.
v0.2.0analyze_hyperliquid_walletcalculate_hyperliquid_feesget_hype_market_snapshothyperliquid_list_funding_rateshyperliquid_list_top_position_holdershyperliquid_summarize_large_trader_positionslist_active_hyperliquid_twapsscan_cross_exchange_funding_spreadsscan_cross_exchange_perp_price_spreadsEach tool has a clearly distinct purpose: snapshot, fee estimation, wallet analysis, positions, top holders, TWAPs, funding rates, and cross-exchange spreads. No overlapping functionality.
Most tools follow a verb_noun pattern (e.g., get_hype_market_snapshot, calculate_hyperliquid_fees), but some include the server name as prefix (e.g., hyperliquid_summarize_large_trader_positions), causing minor inconsistency.
9 tools is well-scoped for a market depth lab covering Hyperliquid and cross-exchange analysis. Each tool serves a distinct function without redundancy.
The tool set covers major operations: snapshots, fees, wallet, positions, funding, and spreads. Minor gaps like historical data or order book depth are absent but not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hyperliquid perp market data for LLMs: OHLCV, funding, open interest, positioning & forecasts.
Hyperliquid - 2 tools for perpetuals, options, and position data
Read-only Hyperliquid vault search, risk, drawdown, rankings, TVL, alerts, and comparisons.
Polymarket + Hyperliquid + macro for AI agents. 38 tools, signal backtest, SSE streaming. Free tier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/derkcc/market-depth-lab-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
