Skip to main content
Glama
Sign In

BytNode

by com.bytnode.api
OverviewDiscussionsAdmin

Get Pair Data

get_pair_data
Read-only

A trading pair, or up to 10 compared: price, candles, trades, order flow, derivatives, tokenomics. No window = current value; since_ms/until_ms/last = history. Rows newest first, dated at the START of their bucket (first_time + i x step_s); for a total, an extreme or a change read summary, for the period covered read ranges; null + unavailable = no data; _pct = percent, _ratio = fraction; every unit: describe_fields. oi is read at the END of its bucket; price_change 1d = rolling 24 h.

EXAMPLES

  • State: symbol=["BTCUSDT"], fields=["klines","funding_next","oi","cvd"], timeframe=1h, limit=24

  • Liquidations 48 h, long/short: fields=["liquidations_cumulative"], last="48h", detail="summary"

  • Buyers vs sellers, last 1000 trades: fields=["trades_futures"], limit=1000, detail="summary"

FIELDS:

  • klines: OHLCV candles (OHLC: reference spot market; volume: spot + futures). [tf, live]

  • price_change: Current price (last trade) and its rolling % change, 1m to 1w. [now, 1 point]

  • trades_spot: Individual spot trades, most recent first. [now, N<=10000]

  • trades_futures: Individual perpetual futures trades, most recent first. [now, N<=10000]

  • trades_large: Futures trades above min_usd, most recent first. [min_usd, now, N<=10000]

  • trades_kline_futures_seconds: Perpetual futures trades aggregated per second. [now]

  • oi: Open interest per bucket, base units and USD (oi_usd). [tf]

  • funding_next: Next estimated funding (8h equivalent, %) and APR: what venues show as current. [now, 1 point]

  • funding_rate: Settled funding of each period (8h equivalent, %) and APR.

  • funding_cumulative: Funding summed over a rolling 24h, and APR.

  • basis: Futures/spot basis, % and price (positive = contango). [tf]

  • oi_change: Open interest change per bucket, absolute and in %. [tf]

  • liquidations_events: Individual liquidations: side, price, quantity, USD. [min_usd, now, N<=10000]

  • liquidations_cumulative: USD liquidated per bucket, long and short positions. [tf]

  • liquidations_big_small_ratio: Large vs small liquidations per bucket: counts, USD, ratio. [tf]

  • orderbook: Order book depth (bids, asks, imbalance) by distance from mid. [tf, market]

  • cvd: Volume delta per bucket (net, buy, sell, base units) and its running total cumulative_net_volume. [tf, market, live]

  • spread_interexchange: Price spread between venues, bps (the only field naming venues). [tf, live]

  • buy_sell_ratio: Buy share of the traded volume per bucket. [tf, market]

  • trades_avg_size: Average trade size per bucket (base units). [tf, market]

  • trades_kline: Trade candles, spot + futures: count, buy, sell, net volume. [tf, live, N<=1440]

  • trades_kline_spot: Trade candles, spot: count, buy, sell, net volume. [tf, live, N<=1440]

  • trades_kline_futures: Trade candles, futures: count, buy, sell, net volume. [tf, live, N<=1440]

  • tokenomics: Supply (circulating, total, max), market cap, FDV (USD).

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>",
      "fields": "<fields>"
    },
    "name": "get_pair_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
lastNoHistory over the last '48h' / '30d' (whole buckets).
liveNoAdds the open candle (live fields).
limitNoN latest points per series (default 1).
detailNosummary: one row per series + summary; full: every column.compact
fieldsYesFields (FIELDS below).
marketNoOf cvd, buy_sell_ratio, trades_avg_size, orderbook.
symbolYes1 to 10 pairs, e.g. ["BTCUSDT"].
columnsNoColumns to keep, e.g. ["close", "volume"].
contextNoAdds `context`: where each series' latest value sits in its own recent history (percentile, z, n, window). Not a signal; no quota.
dry_runNoPlans the call without making it: its quota cost, your remaining rate and quota, the checks. No data, no quota.
min_usdNoUSD threshold: trades_large (default 100000), liquidations_events.
since_msNoHistory start: epoch ms, ISO date or '48h' ago.
until_msNoHistory end.
timeframeNoStep of tf fields (default 1h, history: ~200 points). 1w: klines.
max_tokensNoResponse budget, estimated tokens (default 6000).
max_quota_costNoRefuses the call, before any request, if it would use more quota requests than this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint annotations: bucket timestamps are the START of the interval (with the exception that oi is read at the END), rows are newest first, price_change 1d is a rolling 24h, null plus an unavailable marker means no data, and unit suffixes _pct/_ratio are defined. It also points to describe_fields for every unit and explains the summary/detail tradeoff. That is unusually rich disclosure for a read tool.

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 with the core rule, then EXAMPLES, then a FIELDS block, so an agent can stop reading after the first paragraph. Every line carries information, but the telegraphic style ('null + unavailable = no data') is cryptic on first read and some phrasing, like 'for a total, an extreme or a change read summary', is dense enough to require a second pass.

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 16-parameter tool with no output schema, the description covers return ordering, bucket dating, unit conventions, and the detail/context/max_tokens output-shaping options. Remaining gaps are modest: how multi-symbol results are laid out and what happens on partial failures are not stated, though describe_fields and dry_run cover adjacent discovery needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds real semantics the schema cannot express: the FIELDS list tags each field with the parameters it consumes ([tf], [live], [market], [min_usd], [now, N<=10000]), telling the agent which knobs matter for which field. It also clarifies that detail='summary' produces one row per series and that 'ranges' should be read for period totals.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line names the resource and its scope precisely: 'A trading pair, or up to 10 compared', followed by the data families it returns (price, candles, trades, order flow, derivatives, tokenomics). An agent immediately knows this is a broad multi-series market-data fetch rather than a summary or ranking tool. It stops short of a verb-led statement and never explicitly contrasts itself with siblings like get_pair_brief.

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?

Gives concrete usage rules: 'No window = current value; since_ms/until_ms/last = history', plus worked examples for state snapshots, cumulative liquidations with detail=summary, and raw trade pulls. These examples effectively show when each parameter combination applies. It lacks explicit when-not guidance or a named alternative for lighter-weight needs.

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

All BytNode toolsInspect
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