Skip to main content
Glama

Gambit

by trading.gambit
OverviewDiscussionsAdmin

Scan Hyperliquid markets

scan_markets
Read-onlyIdempotent

Scan all Hyperliquid perp markets ranked by funding, volume, open interest, or 24h price change. The best first call for finding opportunities. Includes HIP-3 builder-DEX assets (equities/commodities, symbols like xyz:TSLA) unless disabled. Returned symbol values are the instrument ids the other tools accept.

Funding as a positioning read applies to NATIVE perps (BTC, ETH, HYPE — no dex field), where extreme funding does mean crowded positioning. It does NOT transfer to HIP-3 rows: each builder DEX applies its own deployer-set funding_multiplier to funding, which differs between dexes, differs between assets inside one dex, is ~0 on some (funding effectively switched off), and can be changed by the deployer at any time. A HIP-3 market's funding therefore measures crowding TIMES that multiplier, so raw HIP-3 funding says nothing about positioning on its own and is not comparable with native funding or across dexes.

With sort=funding, data.top ranks native perps only; HIP-3 rows are ranked separately in data.hip3.top_by_scaled_funding on funding_apr_pct_scaled (the multiplier removed — that is the number to compare and to reason about crowding with). data.hip3.funding_not_comparable lists symbols with no usable funding signal, split into data.hip3.funding_disabled (the deployer set the multiplier to ~0 — funding is switched off) and data.hip3.funding_scale_unknown (the multiplier has not been observed yet, so the rate cannot be interpreted). Report either as having no funding signal — never as neutral or balanced positioning — and do not describe an unknown scale as disabled. Every row carries funding_multiplier; funding_apr_pct stays the real cost of carry a holder pays and is correct for every row. (Requires api:read.)

Input Schema

NameRequiredDescriptionDefault
topNo
reverseNoSort direction override: false = ascending (lowest/most negative first, e.g. top 24h losers with sort_by=price_change), true = descending (highest first). Omit for the sort field's default direction.
sort_byNo
min_volumeNo
include_hip3No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / reverse / description
      Added value: +"Sort direction override: false = ascending (lowest/most negative first, e.g. top 24h losers with sort_by=price_change), true = descending (highest first). Omit for the sort field's default direction."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

The annotations already cover read-only and safety traits, but the description adds substantial behavioral context beyond them: HIP-3 inclusion behavior, funding multiplier semantics, non-comparability of HIP-3 funding, special output buckets such as data.hip3.top_by_scaled_funding, and the api:read requirement. It also warns how to interpret ambiguous funding data rather than treating it as neutral.

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?

The description is front-loaded with a clear purpose statement and then grouped logically into HIP-3 inclusion and funding interpretation guidance. It is lengthy and dense, but most sentences carry specific operational meaning rather than filler, though some funding caveat wording could be tightened.

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

Completeness4/5

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

There is no output schema, so the description must carry return-value semantics; it does this well for symbols, funding buckets, and HIP-3 edge cases. It still leaves some input parameters unmentioned and does not fully describe the general row shape, but the key correctness-critical context is present.

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 description coverage is only 20%, and the description compensates for some parameters by mapping the ranking choices to sort_by and by explaining include_hip3 behavior. However, it does not explain top, min_volume, or the default behavior for omitted parameters, and reverse is already covered by the schema.

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?

The first sentence states a specific verb and resource: scanning all Hyperliquid perp markets, ranked by funding, volume, open interest, or 24h price change. It also identifies itself as the best first call for finding opportunities and explains that returned symbol values feed other tools, which distinguishes it from sibling lookup or price tools.

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 description gives clear usage context by calling itself 'the best first call for finding opportunities' and by explaining HIP-3 inclusion and ranking behavior. It does not explicitly name alternatives or when not to use this tool, but the intended entry-point role is clear.

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

All Gambit toolsInspect
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