Basis

market_derivatives

Read-onlyIdempotent

Read current perpetual funding (fonlama/takas ücreti), open interest and positioning directly by symbol, without loading candles first. Optional ref reuses a fresh derivatives handle. Funding is a transfer between longs/shorts, NOT a maker/taker trading commission. Returns decimal and percentage rates, actual settlement interval and optional payment scenario.

Input Schema

Name	Required	Description
`ref`	No	Optional existing data handle.
`side`	No	For payment estimate; default long.
`market`	No	Default: the chart.
`symbol`	No	Default chart symbol; perpetual funding is read on futures even when the chart is spot.
`exchange`	No
`timeframe`	No	Aggregation for OI/positioning; not the funding settlement interval.
`notionalQuote`	No	Optional hypothetical position value in quote units to estimate one funding payment.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 23, 2026

addedInput schema / properties / exchange

Added value: +{
+  "enum": [
+    "binance",
+    "bybit",
+    "okx",
+    "hyperliquid"
+  ],
+  "type": "string"
+}

addedInput schema / properties / market

Added value: +{
+  "description": "Default: the chart.",
+  "enum": [
+    "spot",
+    "futures"
+  ],
+  "type": "string"
+}

addedInput schema / properties / notionalQuote

Added value: +{
+  "description": "Optional hypothetical position value in quote units to estimate one funding payment.",
+  "type": "number"
+}

addedInput schema / properties / ref / description
```
Added value: +"Optional existing data handle."
```

addedInput schema / properties / side

Added value: +{
+  "description": "For payment estimate; default long.",
+  "enum": [
+    "long",
+    "short"
+  ],
+  "type": "string"
+}

addedInput schema / properties / symbol

Added value: +{
+  "description": "Default chart symbol; perpetual funding is read on futures even when the chart is spot.",
+  "type": "string"
+}

addedInput schema / properties / timeframe

Added value: +{
+  "description": "Aggregation for OI/positioning; not the funding settlement interval.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "ref"
-]
```

First observedSep 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare the tool as read-only, idempotent, non-destructive and open-world. Beyond that, the description clarifies that funding is a transfer between longs and shorts rather than a trading commission, explains handle reuse via ref, and lists the returned data including decimal and percentage rates, settlement interval and optional payment scenario.

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 front-loaded with the tool's purpose and scope, followed by concise clarifications about ref reuse, the nature of funding, and return values. Every sentence contributes useful information without repetition.

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?

Given the seven optional parameters, 86% schema coverage and rich annotations, the description is largely complete. It explains the core purpose, ref behavior, funding semantics and key return values, though it does not describe the return shape for open interest and positioning in detail.

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 description coverage is high at 86%, so the schema already carries most parameter meaning. The description still adds useful semantics for ref by saying it reuses a fresh derivatives handle, and it clarifies the payment-scenario context relevant to side and notionalQuote. It does not add much detail for the remaining parameters.

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 verb and resource: reading current perpetual funding, open interest and positioning directly by symbol. It also distinguishes this from candle-based workflows by saying it works 'without loading candles first,' which helps separate it from siblings such as market_candles.

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 usage context: use this for direct by-symbol derivatives reads and avoid loading candles first. It also explains that an optional ref reuses a fresh derivatives handle. However, it does not explicitly name alternatives or state when not to use the tool.

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

All Basis 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?