Tanod MCP server

chainpeek: cross-venue perpetual funding carry ranking across Binance, Bybit, OKX, Hyperliquid and dYdX

rank_funding_carry

Read-onlyIdempotent

Rank cross-venue perpetual funding carry by annualized spread across Binance, Bybit, OKX, Hyperliquid, and dYdX, returning long/short venue pairs gross and net of taker fees.

Instructions

chainpeek: Rank cross-venue perpetual funding carry. For Hyperliquid against dYdX alone use compare_funding_rates; for market data use get_perp_markets. Returns the best long and short venue pair per asset across Binance USDT-M, Bybit, OKX, Hyperliquid and dYdX v4, with the annualised funding spread gross and net of taker fees. Net subtracts four taker legs (open and close on both venues) at taker_fee_bps, spread over holding_days; with the default 0 bps net equals gross. Rates are normalised to hourly and annualised (simple); a venue that is down is listed in venues_failed. Cached up to 60 s. Data only, not trading advice. Bad input is a 422 (not charged). Typically 1-5 s. Price: USD 0.005. Free: 10 chain reads per IP per UTC day. Docs: https://tanod.dev/learn/funding-rate-arbitrage-api.html

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Rows returned, 1-100 (default 20).
`venues`	No	Optional subset of hyperliquid, dydx, binance, bybit, okx (at least two). Default: all five.
`symbols`	No	Optional: only these base assets (case-insensitive, at most 50), such as BTC. Names listed on fewer than two of the chosen venues are returned in symbols_not_found.
`holding_days`	No	Days the position is held; the fees are amortised over it (default 7).
`taker_fee_bps`	No	Taker fee per side in basis points (default 0). Net APR subtracts 4 taker legs (open and close on both venues): 4 x bps / 100 x 365 / holding_days.
`min_volume_usd`	No	A venue is only used for a symbol when its 24 h volume there reaches this (USD), so it applies to both legs. Default 0.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`pair`	No
`cache`	No
`count`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`source`	No
`markets`	No
`sorted_by`	No
`rate_basis`	No
`net_formula`	No
`venues_used`	No
`holding_days`	No
`annualization`	No
`taker_fee_bps`	No
`venues_failed`	No
`intervals_note`	No
`markets_ranked`	No
`intervals_unknown`	No
`symbols_not_found`	No
`fee_cost_annualized_pct`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, but the description adds substantial operational context beyond them: gross vs. net spread calculation, normalisation to hourly annualised rates, `venues_failed` and `symbols_not_found` behavior, 60-second caching, 422 on bad input (not charged), 1–5 s latency, USD 0.005 price, and a free-tier rate limit. That is a rich behavioral profile.

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 the core purpose and alternatives, then layers on detailed behavior. It is dense but every sentence adds information; the pricing and free-tier lines are operationally useful though slightly tangential to selection, keeping it just short of a 5.

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?

Despite an output schema existing, the description still clarifies key return concepts (best long/short pair, gross vs. net spread, failed venues, missing symbols), and it covers error handling, latency, and caching. For a 6-parameter, read-only ranking tool, nothing an agent needs to call it correctly is missing.

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 documents all six parameters, including the taker-fee formula. The description repeats the taker-fee/net relationship rather than adding new parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.

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: 'Rank cross-venue perpetual funding carry.' It also names the exact scope (five venues) and explicitly distinguishes itself from siblings compare_funding_rates and get_perp_markets, so an agent can select it without opening the 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?

Explicitly routes the agent: 'For Hyperliquid against dYdX alone use compare_funding_rates; for market data use get_perp_markets.' This gives both a when-to-use and named alternatives, leaving no inference needed for tool selection.

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

Deploy Server