Skip to main content
Glama

Cross-exchange funding history of a coin

funding_history
Read-only

Charged funding rates of one coin across all exchanges where it trades, normalized to %/hour on a common hourly grid (up to 90 days back). Shows whether the cross-exchange spread is sustained (feeds a hedged pair) or a one-off spike. Returns the curves plus the median and maximum spread.

Input Schema

NameRequiredDescriptionDefault
baseYesBase coin, e.g. BTC
daysNoWindow in days: 1, 3, 7 (default), 30 or 90
langNoLanguage of the summary and links: 'en' (default) or 'ru'

Output Schema

NameRequiredDescriptionDefault
dataYesCompact numbers the conclusion is based on, units named inside
linkYesLive page with the same data
summaryYesOne-line conclusion — quote this

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

It provides significant behavioral detail beyond the schema and annotations by describing how the data is processed ('normalized to %/hour on a common hourly grid'). It clarifies the analytical value of the output, such as distinguishing between 'a hedged pair' and 'a one-off spike'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely dense and front-loaded. It manages to convey the core service, the processing logic, the timeframe, and the types of data returned in a few highly impactful sentences.

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?

Given that the output involves financial curves, normalization, and spread analysis, the description is exceptionally complete. It helps the agent understand not just what to call, but what kind of complex financial data it will receive.

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?

The schema coverage is 100%, establishing a baseline of 3. The description mentions the scope ('one coin,' 'up to 90 days back'), which aligns with the schema constraints but adds no semantics or meaning that is not already structured in the parameters or their documentation.

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 is highly specific, stating that it 'Charged funding rates of one coin across all exchanges.' It goes beyond a simple noun-verb match by explaining the normalization (normalized to %/hour) and the result (curves plus median and maximum spread).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it defines the specific scope (cross-exchange rates), it doesn't explicitly tell the AI whether to use it over `funding_events` or `pair_briefing`. It primarily defines its domain rather than outlining clear decision paths against siblings.

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