Skip to main content
Glama

WhaleScope MCP

by io.github.osindo-dev

Insurance Fund Balance Snapshot

binance_get_insurance_fund_balance
Read-only

Mengambil snapshot saldo insurance fund Binance Futures per asset margin (LANGSUNG dari Binance native, endpoint publik). Insurance fund yang tebal = buffer lebih besar buat nutup liquidation yang gak ke-cover posisi trader (ngurangin kemungkinan ADL nge-trigger ke trader lain). PENTING: ini SNAPSHOT HISTORIS periodik, BUKAN saldo live/real-time -- gunakan buat konteks kesehatan sistem jangka menengah-panjang, bukan sinyal jangka pendek.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNoFilter symbol tertentu -- opsional, kosongkan untuk semua asset margin.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint as true, so the description's burden is reduced. The description adds value by clarifying this is a periodic historical snapshot (not live), and explains the significance of a thick insurance fund buffer. No contradiction 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action, followed by context and usage caveats. It is efficient but includes explanatory detail about insurance fund buffer, which adds value without being verbose. Could be slightly tighter by removing the parenthetical about ADL, but overall concise.

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 tool has only one optional parameter, good annotations, and no output schema, the description sufficiently explains the tool's purpose, data nature, and usage context. It covers what the tool returns and how to interpret it, making it complete for this level of complexity.

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 coverage is 100%, and the parameter is well-documented in the schema (optional filter for symbol). The description does not need to add much beyond what the schema provides, so a baseline of 3 is appropriate. It adds minimal extra meaning.

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 description clearly states that the tool takes a snapshot of the Binance Futures insurance fund balance per margin asset, directly from Binance's native public endpoint. It distinguishes itself by noting it is a periodic historical snapshot, not live/real-time, which helps differentiate from other real-time tools in the sibling list.

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?

The description explicitly notes that this is not a live/real-time balance, advising use for medium-to-long-term system health context rather than short-term signals. It does not, however, explicitly name alternative tools for real-time data or when not to use this tool.

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