Skip to main content
Glama

Tessera Analytics - Hyperliquid Market Intelligence

Funding divergence

funding_divergence
Read-only

Rank markets by how far their funding has diverged from a benchmark (default ETH) over a trailing window. Pick bar (1d, the default, or 1h for completed hours) to read completed days or completed hours. day defaults to the last complete interval. metric=rate compares mean funding over the window; metric=cum_funding_spread compares how far a market's cumulative funding level travelled inside the window (its high minus its low, so never negative) — that is not the funding the window accumulated, which is funding_paid_7d (or funding_rate_7d_avg times the window's completed-interval count). Returns the most diverged in each direction, each row with usd_volume_7d_avg so a spread can be sized; pass min_usd_volume_7d_avg (USD/day) to exclude markets too illiquid to trade the divergence in. Markets with no funding reading are excluded from both lists. Descriptive only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "funding_divergence"
  }
}

Input Schema

NameRequiredDescriptionDefault
barNo`1d` (the default) for completed UTC days, `1h` for completed UTC hours. An interval, at either grain, is stamped by the instant it **closes** — an hourly `…T09:00:00Z` is the hour that ended at 09:00.
dayNoThe day or hour to rank as of: `YYYY-MM-DD` or `latest` at `bar: 1d`, a completed `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or `latest` at `bar: 1h`.
coinsNoRestrict to these markets.
scopeNo`crypto` (the default), `hip3`, or `all`.
top_nNoMarkets per ranked list, 1..100 (values outside are clamped to the nearest bound and the response says so). Defaults to 10.
metricNo`rate` (the default) ranks each market's mean funding over the window minus the benchmark's; `cum_funding_spread` ranks the **spread of the cumulative funding level** over the window — its high minus its low, so always non-negative — minus the benchmark's. That is not the funding the window accumulated: `cum_funding` is a running total, so a market whose level retraced has a large spread and a *negative* accumulation (and one that reversed inside the window has a spread several times its true accumulation). Measured 2026-10-13 over 34 markets and the trailing 168 hours, the expression below reproduced the served value exactly, while `SUM(funding_paid)` over the same window disagreed in sign for 11 of them (TRX +0.00440 vs −0.00445) and by up to 100× (CASHCAT 0.2050 vs 0.0020). The accumulation is `funding_paid_7d`, or equivalently `funding_rate_7d_avg` × the window's completed-interval count — 7 intervals at the daily grain and 168 at the hourly one.
benchmarkNoThe market whose funding is the yardstick. Defaults to ETH.
window_daysNoLength of the trailing window in days, 1..365. Defaults to 7.
min_usd_volume_7d_avgNoDrop markets whose average **daily** traded notional over the divergence window is below this value, in USD/day at either bar. Each row carries that figure as `usd_volume_7d_avg`, so the floor decides which spreads are tradeable rather than which are largest.

Output Schema

NameRequiredDescriptionDefault
barYesThe grain this answer was computed at: `1d` or `1h`.
as_ofYes
notesYes
scopeYes
metricYes
sourceYes
benchmarkYes
truncatedYes
window_daysYes
published_atNo
top_negativeYesThe largest divergences toward the benchmark's opposite, most extreme first.
top_positiveYesThe largest divergences away from the benchmark, most extreme first.
bar_age_hoursYes
matched_countYesMarkets that had a funding reading in the window. Markets without one are excluded from both lists and from this count — a missing reading must never appear as an extreme.
visible_countYesMarkets in your plan's slice on this interval, before any filter you passed.
eligible_countYesMarkets left after your explicit market filter.
benchmark_valueYesThe benchmark's own value for the metric.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / min_usd_volume_7d_avg
      Added value: +{
      +  "default": null,
      +  "description": "Drop markets whose average **daily** traded notional over the divergence\nwindow is below this value, in USD/day at either bar. Each row carries\nthat figure as `usd_volume_7d_avg`, so the floor decides which spreads\nare tradeable rather than which are largest.",
      +  "format": "double",
      +  "nullable": true,
      +  "type": "number"
      +}
    • addedOutput schema / $defs / DivergenceRow / properties / usd_volume_7d_avg
      Added value: +{
      +  "description": "Average **daily** traded notional over the same window, in USD/day at\neither grain. A funding spread is only as interesting as the size a\nposition in it can take, and the widest divergence in a slice is\nregularly a quiet day in an illiquid market — read this column before\nreading `divergence`.",
      +  "format": "double",
      +  "type": "number"
      +}
    • changedOutput schema / $defs / DivergenceRow / required
      Previous value: -[
      -  "coin",
      -  "value",
      -  "divergence"
      -]New value: +[
      +  "coin",
      +  "value",
      +  "divergence",
      +  "usd_volume_7d_avg"
      +]
  2. Changed3 schema fields changed
    • addedOutput schema / properties / bar_age_hours
      Added value: +{
      +  "format": "double",
      +  "type": "number"
      +}
    • addedOutput schema / properties / published_at
      Added value: +{
      +  "nullable": true,
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "bar",
      -  "source",
      -  "as_of",
      -  "scope",
      -  "visible_count",
      -  "eligible_count",
      -  "matched_count",
      -  "metric",
      -  "benchmark",
      -  "window_days",
      -  "benchmark_value",
      -  "top_positive",
      -  "top_negative",
      -  "truncated",
      -  "notes"
      -]New value: +[
      +  "bar",
      +  "source",
      +  "as_of",
      +  "bar_age_hours",
      +  "scope",
      +  "visible_count",
      +  "eligible_count",
      +  "matched_count",
      +  "metric",
      +  "benchmark",
      +  "window_days",
      +  "benchmark_value",
      +  "top_positive",
      +  "top_negative",
      +  "truncated",
      +  "notes"
      +]
  3. Changed2 schema fields changed
    • addedInput schema / properties / day
      Added value: +{
      +  "default": null,
      +  "description": "The day or hour to rank as of: `YYYY-MM-DD` or `latest` at `bar: 1d`, a\ncompleted `YYYY-MM-DDTHH:00:00Z` (the hour that *ended* there) or `latest`\nat `bar: 1h`.",
      +  "nullable": true,
      +  "type": "string"
      +}
    • changedInput schema / properties / top_n / description
      Previous value: -"Markets per ranked list, 1..50. Defaults to 10."New value: +"Markets per ranked list, 1..100 (values outside are clamped to the\nnearest bound and the response says so). Defaults to 10."
  4. Changed1 schema field changed
    • changedInput schema / properties / metric / description
      Previous value: -"`rate` (the default) ranks each market's mean funding over the window\nminus the benchmark's; `cum_funding_spread` ranks the **spread of the\ncumulative funding level** over the window — its high minus its low, so\nalways non-negative — minus the benchmark's. That is not the funding the\nwindow accumulated: `cum_funding` is a running total, so a market whose\nlevel retraced has a large spread and a *negative* accumulation (and one\nthat reversed inside the window has a spread several times its true\naccumulation). Measured 2026-10-13 over 34 markets and the trailing 168\nhours, the expression below reproduced the served value exactly, while\n`SUM(funding_paid)` over the same window disagreed in sign for 11 of\nthem (TRX +0.00440 vs −0.00445) and by up to 100× (CASHCAT 0.2050 vs\n0.0020). The accumulation is `funding_rate_7d_avg` × the window's completed-interval count — that is 7 intervals at the daily grain and 168 at the hourly one."New value: +"`rate` (the default) ranks each market's mean funding over the window\nminus the benchmark's; `cum_funding_spread` ranks the **spread of the\ncumulative funding level** over the window — its high minus its low, so\nalways non-negative — minus the benchmark's. That is not the funding the\nwindow accumulated: `cum_funding` is a running total, so a market whose\nlevel retraced has a large spread and a *negative* accumulation (and one\nthat reversed inside the window has a spread several times its true\naccumulation). Measured 2026-10-13 over 34 markets and the trailing 168\nhours, the expression below reproduced the served value exactly, while\n`SUM(funding_paid)` over the same window disagreed in sign for 11 of\nthem (TRX +0.00440 vs −0.00445) and by up to 100× (CASHCAT 0.2050 vs\n0.0020). The accumulation is `funding_paid_7d`, or equivalently\n`funding_rate_7d_avg` × the window's completed-interval count — 7\nintervals at the daily grain and 168 at the hourly one."
  5. Changed1 schema field changed
    • changedInput schema / properties / metric / description
      Previous value: -"`rate` (the default) ranks each market's mean funding over the window\nminus the benchmark's; `cum_funding_spread` ranks funding accumulated\nover the window, high minus low, minus the benchmark's."New value: +"`rate` (the default) ranks each market's mean funding over the window\nminus the benchmark's; `cum_funding_spread` ranks the **spread of the\ncumulative funding level** over the window — its high minus its low, so\nalways non-negative — minus the benchmark's. That is not the funding the\nwindow accumulated: `cum_funding` is a running total, so a market whose\nlevel retraced has a large spread and a *negative* accumulation (and one\nthat reversed inside the window has a spread several times its true\naccumulation). Measured 2026-10-13 over 34 markets and the trailing 168\nhours, the expression below reproduced the served value exactly, while\n`SUM(funding_paid)` over the same window disagreed in sign for 11 of\nthem (TRX +0.00440 vs −0.00445) and by up to 100× (CASHCAT 0.2050 vs\n0.0020). The accumulation is `funding_rate_7d_avg` × the window's completed-interval count — that is 7 intervals at the daily grain and 168 at the hourly one."
  6. Changed1 schema field changed
    • changedInput schema / properties / bar / description
      Previous value: -"`1d` (the default) for completed UTC days, `1h` for the most recent\ncompleted UTC hour."New value: +"`1d` (the default) for completed UTC days, `1h` for completed UTC hours.\nAn interval, at either grain, is stamped by the instant it **closes** —\nan hourly `…T09:00:00Z` is the hour that ended at 09:00."
  7. Changed8 schema fields changed
    • addedInput schema / properties / bar
      Added value: +{
      +  "default": null,
      +  "description": "`1d` (the default) for completed UTC days, `1h` for the most recent\ncompleted UTC hour.",
      +  "nullable": true,
      +  "type": "string"
      +}
    • changedInput schema / properties / metric / description
      Previous value: -"`rate` (the default) ranks each market's mean daily funding minus the\nbenchmark's; `cum_funding_spread` ranks funding accumulated over the\nwindow, high minus low, minus the benchmark's."New value: +"`rate` (the default) ranks each market's mean funding over the window\nminus the benchmark's; `cum_funding_spread` ranks funding accumulated\nover the window, high minus low, minus the benchmark's."
    • addedOutput schema / properties / bar
      Added value: +{
      +  "description": "The grain this answer was computed at: `1d` or `1h`.",
      +  "type": "string"
      +}
    • removedOutput schema / properties / coin_count
      Removed value: -{
      -  "description": "How many markets had a funding reading in the window; markets without\none are excluded from both lists and from this count.",
      -  "format": "int64",
      -  "type": "integer"
      -}
    • addedOutput schema / properties / eligible_count
      Added value: +{
      +  "description": "Markets left after your explicit market filter.",
      +  "format": "int64",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / matched_count
      Added value: +{
      +  "description": "Markets that had a funding reading in the window. Markets without one are\nexcluded from both lists and from this count — a missing reading must\nnever appear as an extreme.",
      +  "format": "int64",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / visible_count
      Added value: +{
      +  "description": "Markets in your plan's slice on this interval, before any filter you\npassed.",
      +  "format": "int64",
      +  "type": "integer"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "source",
      -  "as_of",
      -  "scope",
      -  "coin_count",
      -  "metric",
      -  "benchmark",
      -  "window_days",
      -  "benchmark_value",
      -  "top_positive",
      -  "top_negative",
      -  "truncated",
      -  "notes"
      -]New value: +[
      +  "bar",
      +  "source",
      +  "as_of",
      +  "scope",
      +  "visible_count",
      +  "eligible_count",
      +  "matched_count",
      +  "metric",
      +  "benchmark",
      +  "window_days",
      +  "benchmark_value",
      +  "top_positive",
      +  "top_negative",
      +  "truncated",
      +  "notes"
      +]
  8. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds real behavior: results are returned as the most diverged markets in each direction, markets with no funding reading are excluded from both lists, and rows carry usd_volume_7d_avg so a spread can be sized. "Descriptive only" usefully signals the output is not a tradeable signal. It leaves rate limits and row-count semantics to top_n and the output schema.

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 is front-loaded, then parameter guidance follows in a logical order, and no sentence is purely filler. The single dense paragraph with stacked em-dashes and parentheticals makes it harder to scan than a short bulleted structure would, and a few clauses (e.g. the interval-stamping aside) overlap with the schema.

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?

With an output schema covering return shape and annotations covering safety, the description supplies the decision-relevant substance: metric choice, benchmark default, liquidity floor, and exclusion of unreadable markets. It omits the scope values (crypto/hip3/all) and the top_n default, though both are fully documented in the 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 all nine parameters are already documented in detail, and much of the description's bar/metric/benchmark/min_usd_volume wording restates that schema text. The one thing it adds is a cross-parameter relationship (the accumulation equals funding_paid_7d, or funding_rate_7d_avg times the window's completed-interval count, i.e. 7 or 168), which is useful but largely duplicated in the metric schema description. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause gives a specific verb and resource: "Rank markets by how far their funding has diverged from a benchmark (default ETH) over a trailing window." That is far more precise than a tautology, but it never names or contrasts a sibling (e.g. query_cross_section or screen_universe), so an agent must infer why it would choose this over a general cross-sectional query.

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 concrete decision rules inside the tool: pick bar 1d vs 1h for daily vs hourly grains, and pick metric=rate for mean funding vs metric=cum_funding_spread for level travel. It explicitly warns that cum_funding_spread is not accumulated funding and points to funding_paid_7d instead, which is genuine when-to-use guidance. It stops short of saying when to reach for this tool versus a sibling tool.

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.

Resources