Skip to main content
Glama

Funding history (paid, x402) — $0.005

get_funding_history
Read-onlyIdempotent

Paid endpoint ($0.005): hourly funding settlements for one Hyperliquid perp (rate hourly/8h/annualized, premium) plus mean/min/max, positive/negative hours and cumulative rate. Give hours (1-720, default 168) or from/to (YYYY-MM-DD or ISO 8601 UTC, max 720 hours); interval=4h/8h/1d returns UTC buckets (mean rate, cumulative) and allows up to 2160 hours (90 days). Any Hyperliquid perp incl. HIP-3 (xyz:TSLA). History back to each perp's listing (BTC since 2023-05-12). Bad params or unknown symbol return an error and no charge. Returns the x402 payment requirements and URL. Free sample response: https://cryptofeed402.site/samples/funding-history

Input Schema

NameRequiredDescriptionDefault
toNoEnd, YYYY-MM-DD (inclusive) or ISO 8601 UTC; default now
fromNoStart, YYYY-MM-DD or ISO 8601 UTC
hoursNoLast N hours (default 168; max 720 for interval=1h). Do not combine with from/to.
symbolYesHyperliquid perp ticker, e.g. BTC, ETH, kPEPE; HIP-3 builder-dex perps as dex:TICKER, e.g. xyz:TSLA
intervalNo1h = raw hourly settlements (default, max 720 hours); 4h/8h/1d = UTC buckets (max 2160 hours = 90 days)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "hours": 168,
      +    "interval": "1h",
      +    "symbol": "BTC"
      +  }
      +]
    • addedInput schema / properties / hours / examples
      Added value: +[
      +  168
      +]
    • addedInput schema / properties / interval / examples
      Added value: +[
      +  "1h"
      +]
    • addedInput schema / properties / symbol / examples
      Added value: +[
      +  "BTC"
      +]
  2. Changed5 schema fields changed
    • changedInput schema / properties / hours / description
      Previous value: -"Last N hours (default 168). Do not combine with from/to."New value: +"Last N hours (default 168; max 720 for interval=1h). Do not combine with from/to."
    • changedInput schema / properties / hours / maximum
      Previous value: -720New value: +2160
    • addedInput schema / properties / interval
      Added value: +{
      +  "description": "1h = raw hourly settlements (default, max 720 hours); 4h/8h/1d = UTC buckets (max 2160 hours = 90 days)",
      +  "enum": [
      +    "1h",
      +    "4h",
      +    "8h",
      +    "1d"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / symbol / description
      Previous value: -"Hyperliquid perp ticker, e.g. BTC"New value: +"Hyperliquid perp ticker, e.g. BTC, ETH, kPEPE; HIP-3 builder-dex perps as dex:TICKER, e.g. xyz:TSLA"
    • changedInput schema / properties / symbol / pattern
      Previous value: -"^[A-Za-z0-9]{1,20}$"New value: +"^(?:[A-Za-z]{1,10}:)?[A-Za-z0-9]{1,20}$"
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark this as read-only/idempotent/non-destructive, and the description adds important behavior beyond that: exact $0.005 pricing, x402 payment requirements, no charge on bad params, and a free sample URL. These are high-value operational details for a paid endpoint.

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 definition is dense but front-loaded with the paid endpoint, data returned, and key constraints. Every clause is relevant, though the semicolon-heavy single paragraph is slightly harder to scan than a more structured layout would be.

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?

For a complex paid endpoint with no output schema, it explains the core returned data, x402 payment requirements, URL, error behavior, and provides a sample response link. It does not describe the exact funding-history response shape or field names, but the sample link materially offsets that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 is warranted, but the description adds some meaning beyond the schema by explaining interval bucket contents (mean rate, cumulative) and synthesizing the hours/from-to and interval-dependent maximum constraints. It still largely restates schema constraints rather than documenting new parameter behavior.

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 description states a specific resource and scope: hourly funding settlements for one Hyperliquid perp, including the metrics returned and interval options. An agent can distinguish this from siblings such as get_extreme_funding because it is full funding history, not an extremes scan.

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?

It gives clear invocation conditions: provide hours or from/to, choose interval with corresponding maximum windows, and expect an error with no charge on bad params or unknown symbols. It does not explicitly route the agent away from alternatives like get_extreme_funding or get_perps, so it stops short of full when-to-use-vs-alternatives guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.