Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_asset_dividends

Read-onlyIdempotent

List airdrops, rebates, and interest credited to your Binance account to explain balance increases that did not come from trades.

Instructions

List asset distributions credited to the account (airdrops, rebates, interest).

Calls GET /sapi/v1/asset/assetDividend (SIGNED, IP weight 10). This is Binance's "asset dividend record": savings interest, BNB fee rebates, airdrops, referral payouts and similar credits, each with the reason in enInfo.

When to Use:

  • To explain a balance that grew without a trade or a deposit.

  • To total up rebates/airdrops over a period.

When NOT to Use:

  • For Simple Earn positions and their APR — use the earn tools (simple_earn.py).

  • For trades — use binance_get_my_trades (trade_history.py).

Returns: A markdown table of time / asset / amount / description / tranId, capped at 50 rows, plus per-asset totals of the rows shown, or the raw envelope with response_format="json".

Windows: start_time..end_time must span at most 180 days — Binance rejects anything wider, and this is checked locally before the call. Omit both for Binance's own default window.

Examples: params = {"asset": "BNB", "limit": 100} params = {"start_time": "2026-01-01", "end_time": "2026-06-01"}

Error Handling: A window wider than 180 days is rejected locally with an Error: naming the cap, instead of round-tripping to Binance. -2015 means the key lacks Reading permission or this IP is not allowlisted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the API weight, the 180-day window cap with local validation, error code -2015 meaning, and the exact return format (markdown table capped at 50 rows). This adds substantial behavioral context that is not available from annotations alone.

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?

The description is well-structured with clear sections (purpose, when to use, returns, windows, examples, error handling). It front-loads the primary action and then provides necessary details without unnecessary fluff. Every section earns its place.

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?

The description covers the return format, window constraints, error handling, and usage examples. It also mentions the response_format option for raw JSON. Given the tool's moderate complexity and rich schema, this is a complete and self-sufficient description.

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?

The input schema already contains detailed descriptions for every parameter (asset, limit, start_time, end_time, response_format), so schema coverage is high. The description itself adds little about parameters beyond mentioning the 180-day constraint, which is also in the schema's start_time description. Thus, the baseline of 3 applies.

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 states the tool's function as listing asset distributions (airdrops, rebates, interest) and explicitly identifies the underlying API endpoint. It differentiates itself from siblings by naming specific alternatives like binance_get_my_trades and simple_earn tools, so an agent can easily distinguish its purpose.

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?

The description provides explicit 'When to Use' and 'When NOT to Use' sections, naming exact alternatives and conditions. It tells the agent to use this for balance growth without trades and to use earn tools for Simple Earn, and binance_get_my_trades for trades. This is complete guidance.

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

Deploy Server

Other Tools