Skip to main content
Glama
Sign In

Bitquery: Crypto & Blockchain Data

by io.bitquery
OverviewDiscussionsAdmin

Hyperliquid Funding Rates

hyperliquid_funding_rates
Read-only

HOURLY funding-rate and open-interest HISTORY of ONE Hyperliquid perpetual — for "how has BTC funding moved this week", cost-of-carry, crowding over time. NOT the cross-market snapshot (hyperliquid_open_interest), NOT a price series (hyperliquid_candles).

One row per hourly settlement: Funding_Rate (per hour, signed: positive = longs pay), Funding_Apr_Pct, Open_Interest (one side, base units), Long_Positions / Short_Positions, Long_Accounts_Pct (share of accounts that are long), Funding_Paid_Usd (gross paid by the paying side; zero-sum across accounts), Payers / Receivers, Implied_Price. Newest first. Spot and outcome markets have no funding.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "market": "<market>"
    },
    "name": "hyperliquid_funding_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
hoursNoHistory window in hours, 1..720. Default 168 (7 days).
limitNoRows to return, 1..720. Default 168.
formatNoShape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.rows
marketYesExact perpetual market id (BTC, xyz:NFLX). Case-insensitive. Required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
+  "default": "rows",
+  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/safe, but the description adds real behavioral context: row granularity (one row per hourly settlement), ordering (newest first), unit and sign conventions for Funding_Rate, that Open_Interest is one side in base units, and that Funding_Paid_Usd is gross and zero-sum across accounts. That is meaning an agent cannot get from readOnlyHint alone.

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?

Purpose and exclusions are front-loaded in the first sentence, and the second sentence's column glossary earns its place because there is no output schema. It is dense and the long mid-sentence column enumeration is harder to scan than a list would be, but there is no filler.

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 takes on the full burden of explaining the return shape and does so: column names, units, sign convention, and newest-first ordering. Combined with the named alternatives and the no-funding edge case, an agent has everything needed to call it correctly.

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% with per-parameter descriptions for hours, limit, format and market, so the schema already carries parameter meaning. The description reinforces row granularity and the market scope but adds no syntax, bounds or interaction detail (e.g., hours vs limit relationship) beyond the schema. Baseline 3 applies.

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: hourly funding-rate and open-interest history for ONE Hyperliquid perpetual. It explicitly disambiguates from two named siblings (hyperliquid_open_interest for cross-market snapshot, hyperliquid_candles for price series), so an agent can pick it without opening any schema.

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 concrete use cases ("how has BTC funding moved this week", cost-of-carry, crowding over time) and explicit exclusions with the correct alternatives named. It also states an applicability boundary: spot and outcome markets have no funding, which prevents a class of failed calls.

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

All Bitquery: Crypto & Blockchain Data 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