Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_convert_dust_to_bnb

Sell small asset balances for BNB in one irreversible batch. Preview eligible assets first, then convert up to 100 per call using Binance's dust endpoint.

Instructions

Convert small balances to BNB. Irreversible — the assets are sold for BNB.

Calls POST /sapi/v1/asset/dust (SIGNED, UID weight 10). Every asset listed is swapped to BNB at Binance's dust rate, minus a service charge; there is no undo and no "cancel" endpoint.

Preview first. Run binance_get_dust_convertible and pass only assets it listed: it names what qualifies and how much BNB each one yields, and it works even with the kill-switch off.

Kill-switch. This call is refused with Error: … trading is disabled … unless the server runs with BINANCE_ALLOW_TRADING=1. The gate lives in the HTTP client, so no tool can bypass it. If you see that error, the operator has deliberately put the server in read-only mode — report it, do not try to work around it.

Key permission. The API key needs "Enable Spot & Margin Trading"; this is a trade, not a transfer.

At most 100 assets per call — a client-side guard, not a Binance limit (Binance documents no cap). Split a longer list into batches; each batch is its own irreversible conversion.

When to Use:

  • After a human approved converting these specific assets, and after the preview confirmed they qualify.

When NOT to Use:

  • To swap a meaningful amount of one asset for another — the dust rate is worse than the market; use the convert tools (convert.py) or a spot order instead.

  • To see what happened in past conversions — use binance_get_dust_log.

Returns: A confirmation echoing exactly what Binance returned: totalTransfered (BNB received), totalServiceCharge, and the per-asset transferResult rows with their tranIds. Nothing is inferred; an asset Binance silently skipped simply will not appear in the table.

Examples: params = {"assets": ["ADA"]} params = {"assets": ["ADA", "DOT", "XRP"], "account_type": "SPOT"}

Error Handling:

  • Error: … trading is disabled … → the kill-switch is off; nothing was converted.

  • -2015 means the key lacks Spot & Margin Trading permission, or this IP is not allowlisted.

  • "The asset does not have a dust balance" family of errors → re-run binance_get_dust_convertible; eligibility changes with price.

  • A 5xx or a timeout means the conversion status is UNKNOWN — check binance_get_dust_log before retrying; a duplicate conversion cannot be undone.

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

A5/5.0
Behavior5/5

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

The description goes far beyond the annotations: it discloses irreversibility, lack of a cancel endpoint, service charges, the BINANCE_ALLOW_TRADING kill-switch, required Spot & Margin Trading permission, client-side batching limits, and the ambiguity of 5xx/timeout results. No contradiction with the annotations is apparent.

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 long, but every section earns its place for a high-stakes irreversible operation. Bold headers, front-loaded warnings, examples, and error handling make the information scannable without redundancy.

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 prerequisites, kill-switch behavior, permissions, limits, return values, examples, and error handling. For a complex mutating operation with irreversible side effects, nothing an agent needs to safely call and verify the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though the signal says schema coverage is 0%, the description explains both parameters thoroughly: `assets` gets batching, preview, and query-key semantics, while `account_type` is clarified as SPOT or MARGIN with default behavior. Examples illustrate valid parameter shapes.

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 states a specific verb and resource: 'Convert small balances to BNB' via `POST /sapi/v1/asset/dust`. It also clearly distinguishes this from related tools by emphasizing irreversibility and pointing to alternate tools for meaningful trades and history.

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?

There is an explicit 'When to Use' and 'When NOT to Use' section. It names `binance_get_dust_convertible` as a required preview step, `binance_get_dust_log` for verifying past conversions, and the convert/spot tools as better alternatives for meaningful amounts.

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