Skip to main content
Glama
Sign In

Hyperliquid

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Hyperliquid Funding History

hyperliquid_funding_history
Read-onlyIdempotent

Historical funding-rate payments for one Hyperliquid perp — timestamped funding rate and premium at each funding interval (hourly on Hyperliquid), from Hyperliquid's public info API ({"type":"fundingHistory"}). Use this to see how funding has trended (e.g. persistently positive BTC funding = longs paying shorts = crowded long), or to reconstruct realized funding cost over a window. For the CURRENT funding rate only, hyperliquid_asset_context is cheaper (one call, no window math).

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "coin": "BTC",
      "lookback_hours": 6
    },
    "name": "hyperliquid_funding_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesPerp symbol, e.g. "BTC", "ETH", "SOL".
end_timeNoWindow END — same formats as start_time. Defaults to now.
start_timeNoWindow START — ISO date/datetime or unix seconds/milliseconds. Use with end_time for a window that does not end now.
lookback_hoursNoWindow length ending now, in hours (default 24, funding pays hourly so this returns ~1 row/hour). Ignored when start_time is given.

Output Schema

NameRequiredDescriptionDefault
coinNo
countNo
foundNo
sourceNo
fundingNo
end_timeNo
start_timeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), and the description adds real value on top: the upstream API and type parameter, the hourly funding cadence, and a relative cost signal versus a sibling. It does not discuss pagination, row caps, or rate limits on long windows, which is the main remaining gap.

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

Conciseness5/5

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

Three sentences, each doing distinct work: what it returns, why you'd want it, and the cheaper alternative. The core purpose is front-loaded in the first clause.

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?

For a read-only time-window query tool with a full output schema, annotation coverage, and complete parameter documentation, nothing an agent needs to select or invoke it correctly is missing. The description's only omissions are operational trivia (limits, pagination) already implied by the output schema.

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 100%, so the schema already defines coin, start_time, end_time, and lookback_hours including the 'ignored when start_time is given' rule and the ~1 row/hour density note. The description adds only the framing that a 'window' is what the parameters describe; it contributes no additional format or precedence detail beyond 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?

States a specific verb and resource ('Historical funding-rate payments for one Hyperliquid perp') plus the exact granularity (timestamped rate and premium per funding interval) and data source endpoint. It is immediately distinguishable from hyperliquid_asset_context, which it names as the current-rate alternative.

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?

Gives two concrete use cases (trend analysis with a worked example interpretation, and reconstructing realized funding cost over a window), then explicitly routes the agent away with a cheaper alternative for the current rate only. When-to-use and when-not-to-use are both present.

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

All Hyperliquid 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