Skip to main content
Glama

WhaleScope MCP

by io.github.osindo-dev

Top-Trader Long/Short Ratio (Breakdown Murni)

binance_get_top_trader_ratio
Read-only

Rasio long/short KHUSUS TOP TRADER, terpisah dari retail, LANGSUNG dari Binance (bukan Coinalyze). mode='account' = breakdown jumlah akun; mode='position' = breakdown size posisi (lebih relevan buat modal besar). KETERBATASAN: threshold 'top trader' tidak dipublikasikan Binance; bandingkan RELATIF ke histori pendek pair sendiri, jangan pakai threshold absolut universal (docs/mm_detection_framework.md Section 4.2). Default ringkas (snapshot + tren + <=10 poin terbaru); detail: "full" untuk histori lengkap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'account' = breakdown jumlah akun top trader, 'position' = breakdown size posisi top traderaccount
limitNoJumlah data poin terakhir
detailNo'summary' (default): metrik turunan + <=10 poin terbaru saja, HEMAT TOKEN. 'full': array/level mentah lengkap seperti sebelumnya. Lihat docs/tool_response_reference.md.summary
periodNoInterval antar data poin: 5m, 15m, 30m, 1h, 2h, 4h, 6h, 12h, 1d1h
symbolYesSimbol pair Binance Futures, contoh: BTCUSDT, ETHUSDT. Harus pair perpetual yang terdaftar di Binance USDS-M Futures.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, setting a safety baseline. The description adds valuable behavioral context: the undisclosed threshold, output behavior for summary vs full mode (token-saving), and the existence of a detailed reference doc. No contradictions with annotations.

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?

A single well-structured Indonesian sentence/paragraph packs purpose, differentiation, mode guidance, limitation, and default behavior without redundancy. Every clause adds value, and it's not overly verbose for the information conveyed.

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?

For a tool with 5 params, 1 required, no output schema, the description covers all necessary aspects: what it returns (summary vs full), default values, the critical threshold limitation, and a documentation pointer for further details. It addresses the complexity and provides actionable context for an agent.

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 covers 100% of parameters with descriptions. The description adds practical semantics: explains mode 'position' as more relevant for large capital, clarifies detail='summary' as token-efficient with derived metrics, and describes the default limit of 10 points. It goes beyond schema's basic enum descriptions.

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 clearly specifies it provides the top-trader long/short ratio, distinct from retail, and sourced directly from Binance (not Coinalyze). It distinguishes from sibling tools like binance_get_long_short_ratio by emphasizing 'top trader' and 'separate from retail', giving a specific verb+resource+scope.

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?

Provides explicit guidance on when to use mode='account' vs 'position' (position more relevant for large capital), and highlights a key limitation: Binance does not publish the top-trader threshold, advising relative comparison to the pair's own history rather than absolute thresholds, with reference to documentation section. This clearly informs usage.

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

All WhaleScope MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation4/5

Most tools map to a distinct Binance metric or analytic concept, and descriptions explicitly contrast near-neighbors (spot vs futures, snapshot vs delta, 'BEDA dari...' notes). A few pairs could still be confused—`binance_get_basis` vs `binance_get_basis_history` and `binance_get_agg_trades` vs `binance_get_recent_trades`—but their purpose differences are explained well enough for careful agents.

Naming Consistency4/5

The dominant pattern is `binance_<verb>_<object>` in snake_case, with consistent complementary pairs like `get_*` and `get_*_history`. There are minor style breaks: `orderbook` vs `order_book`, the `whalescope_*` prefix, and `whalescope_full_pipeline` which lacks a verb, but the overall structure is readable and predictable.

Tool Count1/5

56 tools cross the explicit '50+ tools' extreme threshold. Although the Binance Futures domain is broad, many tools are single-endpoint or single-metric wrappers—multiple klines variants, order book variants, and ticker variants—that could be consolidated into parameterized composite tools. The surface is far too large for most agents to navigate efficiently.

Completeness4/5

The public market-data and analytics surface is remarkably complete: klines, funding, open interest, long/short ratios, top-trader data, liquidations, basis, order book behavior, regime detection, and full pipeline scoring are all covered. The main gaps are documented limitations such as unavailable liquidation-by-price data and non-public account/execution tooling, but agents can work around them without dead ends.

Resources