BytNode

Get Pair Brief

get_pair_brief

Read-only

The state of 1 to 10 pairs in ONE call, fixed shape: price_change, funding_next, the latest basis, oi (with oi_usd) and cvd of the last closed 1h bucket, liquidations_24h {from, to (start of the first and of the last 1h bucket), long_usd, short_usd, total_usd, bucket_count} and fear_greed (Financial plan), with context: where each value sits in its own recent history. Two quota requests per pair, plus one. Anything else: get_pair_data.

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": "get_pair_brief"
  }
}

Input Schema

Name	Required	Description
`symbol`	Yes	1 to 10 pairs, e.g. ["BTCUSDT"].
`dry_run`	No	Plans the call without making it: its quota cost, your remaining rate and quota, the checks. No data, no quota.
`max_quota_cost`	No	Refuses the call, before any request, if it would use more quota requests than this.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare this a safe read operation, so the description's main added value is the quota disclosure ('Two quota requests per pair, plus one') and the fixed return shape, which is meaningful since no output schema exists. However it omits rate-limit ceilings, behavior on invalid symbols beyond the schema pattern, and clarification of cryptic items like 'fear_greed (Financial plan)'.

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?

The opening clause is front-loaded with the core scope and the sibling routing is tacked onto the end where it reads cleanly. The middle is a dense run-on field list with bracketed cardinality notes, efficient but harder to scan, and items like 'oi (with oi_usd)' are cryptic without domain knowledge.

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?

Because there is no output schema, the description carries the full burden of describing return values, and it does so field by field including the nested liquidations_24h object and the context block. Remaining gaps are quota limits and error semantics for a complex multi-pair batch call, but the essential shape is covered.

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%, so all three parameters are already documented, making this a baseline-3 case. The description does add one useful link by quantifying cost ('Two quota requests per pair, plus one'), which gives meaning to max_quota_cost, but it says nothing extra about dry_run or symbol formatting.

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 names a specific verb and resource ('The state of 1 to 10 pairs in ONE call') and enumerates the exact fields returned in a fixed shape. It explicitly routes other needs to the sibling get_pair_data, so an agent can separate the two without opening either schema.

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 a clear usage context (brief state of up to 10 pairs in one batched call) and names the alternative (get_pair_data) for everything else, plus a concrete quota cost for budgeting. The exclusion 'Anything else' is broad and doesn't say which needs belong to get_pair_data, leaving some inference to the agent.

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

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