AlphaPipeline Agent MCP

derivatives.funding_rate

Read-only

Use this tool when analyzing perpetual futures funding rates, long/short market sentiment crowding, or timing hedging strategies before settlement periods. Aggregates Bybit (primary) and Binance (fallback) perpetual funding rates, plus mark_price/index_price (both paths) and open_interest_usd (Bybit path only - null on the Binance fallback). Do not use for spot market volume or token security checks. Paid in USDC on Base.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Ticker symbol, e.g. BTC, ETH, or BTCUSDT.

Output Schema

TableJSON Schema

Name	Required	Description
`notice`	No
`symbol`	Yes
`mark_price`	No	Perpetual futures mark price at lookup time. Populated on both the Bybit and Binance paths.
`data_source`	Yes
`index_price`	No	Underlying spot index price feeding the perpetual's funding calculation. Populated on both the Bybit and Binance paths.
`funding_rate`	No
`generated_at`	Yes
`predicted_rate`	No
`next_funding_time`	No
`open_interest_usd`	No	Total open interest in USD notional. Only available via the Bybit path - always null on the Binance fallback, since Binance's premiumIndex endpoint does not report open interest.
`funding_interval_hours`	No
`funding_rate_percentage`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 18, 2026

addedOutput schema / properties / index_price

Added value: +{
+  "description": "Underlying spot index price feeding the perpetual's funding calculation. Populated on both the Bybit and Binance paths.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / mark_price

Added value: +{
+  "description": "Perpetual futures mark price at lookup time. Populated on both the Bybit and Binance paths.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / open_interest_usd

Added value: +{
+  "description": "Total open interest in USD notional. Only available via the Bybit path - always null on the Binance fallback, since Binance's premiumIndex endpoint does not report open interest.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

AddedSep 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: Bybit primary with Binance fallback, open_interest_usd only existing on the Bybit path and null on Binance, and payment currency on Base. This gives a useful, non-obvious operational picture.

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?

Three sentences carry a use case, data source behavior, exclusions, and payment context with no filler. The structure front-loads the most decision-relevant information and then gives data path details. Slightly dense, but efficient.

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 simple one-parameter tool with read-only annotations and an output schema, the description captures the key behaviors, source paths, and nullability caveat. It is sufficiently complete for an agent to decide whether to call it and understand the response shape, though it does not explain symbol normalization beyond the schema examples.

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% and includes examples like 'BTC, ETH, or BTCUSDT,' so the schema already documents the single parameter fully. The tool description adds context about what symbol relates to but does not add much beyond the schema, 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 description starts with a clear use case ('analyzing perpetual futures funding rates, long/short market sentiment crowding, or timing hedging strategies before settlement periods') and explicitly states the resource: Bybit/Binance perpetual funding rates plus mark_price/index_price and open_interest_usd. It also names what it is not for ('spot market volume or token security checks'), distinguishing it from unrelated sibling tools.

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?

The description gives explicit when-to-use instructions tied to concrete market conditions, and explicit negative guidance for spot volume and token security. It does not name any specific sibling tool to switch to, so routing is slightly weaker than the highest bar, but the exclusions are clear.

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

All AlphaPipeline Agent MCP tools Inspect

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

Need Help?