Skip to main content
Glama
Sign In
Wicked MCP server

Wicked MCP server

by WickedAPI
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Hybrid

funding_oi

Read-onlyIdempotent

Aggregate Binance and Bybit perpetual-futures funding rates and open interest to gauge leverage and crowding, with 7-day average funding, 24-hour OI change, and long/short bias.

Instructions

[Trading Data API] Aggregated perpetual-futures funding rate & open interest from Binance + Bybit, with 7-day average funding, 24h OI change, and a long/short bias signal.

Example: /v1/funding-oi?symbol=BTC

Use when you want perp funding rates and open interest aggregated from Binance and Bybit to gauge leverage and crowding. Not for Hyperliquid-specific data (use hyperliquid) or spot-vs-perp carry (use basis).

Behavior: read-only. Priced via x402 (USDC on Base) or free with WICKEDAPI_API_KEY; with neither, you get HTTP 402 with the decoded price in payment_required (a price quote, not a failure).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "funding_oi"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYesRequired. Base crypto symbol (e.g. BTC, ETH, SOL). Mapped to the <SYMBOL>USDT perpetual ticker on Binance/Bybit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description goes well beyond them by disclosing the pricing model: x402 (USDC on Base) or free with an API key, and that an unauthenticated call returns HTTP 402 with `payment_required` as a price quote rather than a failure. That preempts a very likely agent misinterpretation of a 402 response.

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?

Front-loaded purpose, then example, then usage/exclusion, then behavior — a clean hierarchy where each block earns its place. Minor waste in the bracketed `[Trading Data API]` prefix and some bold/formatting overhead, but nothing substantive is padded.

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?

No output schema exists, so the description compensates by naming the returned metrics (7d avg funding, 24h OI change, bias signal) and the aggregation sources. Combined with the payment-failure behavior and a single well-documented parameter, an agent has everything needed to invoke and interpret the call.

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 the `symbol` parameter is already documented in the schema, including the SYMBOLUSDT perpetual mapping. The description only adds a concrete example URL (`/v1/funding-oi?symbol=BTC`), which is mildly useful but not semantic depth beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: aggregates perpetual-futures funding rate and open interest from Binance and Bybit, and names the derived fields (7d avg funding, 24h OI change, long/short bias). It explicitly distinguishes itself from the `hyperliquid` and `basis` siblings, so an agent can route without opening a 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?

Gives explicit when-to-use (gauge leverage and crowding) and two concrete when-not-to-use cases naming the correct alternatives: Hyperliquid-specific data → `hyperliquid`, spot-vs-perp carry → `basis`. This is exactly the routing guidance an agent needs among ~70 siblings.

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

Deploy Server

Other Tools