binance_get_exchange_infoFull exchange info Binance Futures: status pair, filters (PRICE_FILTER, LOT_SIZE, MIN_NOTIONAL, dll), precision, contractType. Kalau symbol dikirim, hanya return 1 pair. Berguna cek tick size, min qty, status trading sebelum buka grid/order.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Opsional. Kalau diisi, filter hanya 1 symbol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations: if `symbol` is provided, only one pair is returned; otherwise the full exchange info is returned. It also lists the categories of information returned. The readOnlyHint and openWorldHint annotations are consistent with this read-only, externally-dependent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each of the three sentences earns its place: the first states what the tool returns, the second explains optional symbol behavior, and the third gives a concrete pre-trade use case. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description is sufficiently complete. It names the main return categories and the optional scope behavior, though a tiny bit more detail about what happens when no symbol is sent could make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the `symbol` parameter. The description only restates the same optional-filter behavior, adding no extra detail like format, edge cases, or validation beyond what structured data already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource and scope: full Binance Futures exchange info including pair status, filters, precision, and contract type. It is distinct enough from the large set of price/history/funding siblings, though it does not explicitly name a sibling it differs from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case: check tick size, min qty, and trading status before opening a grid or order. It does not explicitly state when to use another tool instead, but the context is clear enough for an agent to route to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.