amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_transfer_between_wallets

Move funds between your own Binance wallets (Spot, Funding, Margin, Futures) with a single internal transfer. Specify the FROM_TO wallet pair, asset, and amount to rebalance or fund trading accounts without withdrawing from Binance.

Instructions

Move funds between the account's OWN wallets (Spot ⇄ Funding ⇄ Margin ⇄ Futures).

Calls POST /sapi/v1/asset/transfer (SIGNED, UID weight 300 of the 180000/min UID budget). The funds stay inside this Binance account: this is an internal move between wallets, never a transfer to another user and never a withdrawal off the platform. No tool in this server can send funds out of Binance.

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 additionally needs the "Permits Universal Transfer" flag; without it Binance rejects the call even with the kill-switch on. binance_get_api_restrictions (wallet_account.py) reports it as permitsUniversalTransfer.

The isolated-margin directions need the pair named — from_symbol for ISOLATEDMARGIN_MARGIN and ISOLATEDMARGIN_ISOLATEDMARGIN, to_symbol for MARGIN_ISOLATEDMARGIN and ISOLATEDMARGIN_ISOLATEDMARGIN. Both rules are checked locally, so a malformed transfer fails before anything is signed or sent.

When to Use:

After a human has approved this specific movement of this specific amount.
To fund Binance Pay (MAIN_FUNDING) or to sweep Funding back to Spot (FUNDING_MAIN).

When NOT to Use:

To send crypto to another exchange or wallet — this server never withdraws.
To swap one asset for another — that is the convert tools (convert.py) or a spot order (binance_place_order).
To check what a past transfer did — use binance_get_transfer_history.

Returns: A confirmation echoing exactly what Binance returned, which is only the tranId. Binance sends no status field on this endpoint, so the confirmation says the transfer was accepted and points at binance_get_transfer_history / binance_get_wallet_balances to verify it settled. It never claims a balance changed.

Examples: params = {"type": "MAIN_FUNDING", "asset": "USDT", "amount": "25.5"} params = {"type": "FUNDING_MAIN", "asset": "BNB", "amount": "0.1"} params = {"type": "MARGIN_ISOLATEDMARGIN", "asset": "USDT", "amount": "100", "to_symbol": "BTCUSDT"}

Error Handling:

Error: … trading is disabled … → the kill-switch is off; nothing was sent.
-2015 / "permission denied" → the key lacks "Permits Universal Transfer", or this IP is not allowlisted.
-3020 / insufficient balance → the source wallet does not hold the amount.
A 5xx or a timeout means the transfer status is UNKNOWN — it may have gone through. Check binance_get_transfer_history for the same type before retrying; never resend blindly.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations indicate this is a real fund-moving operation (readOnlyHint=false, idempotentHint=false) and the description substantially enriches that: it discloses the kill-switch gate (BINANCE_ALLOW_TRADING=1), the 'Permits Universal Transfer' key permission, the UID weight 300 rate limit, the local validation of isolated-margin rules, and the critical caveat that a 5xx/timeout leaves status UNKNOWN and should never be blindly retried. This goes far beyond the 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?

The description is long but impeccably structured with clear headers (When to Use, When NOT, Returns, Examples, Error Handling). Every section earns its place, and the core purpose is front-loaded in the first sentence. There is no filler; the detail is dense but purposeful.

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?

Given the complexity of the operation (31 transfer directions, isolated-margin special cases, kill-switch, permission, unknown status on failure), the description covers every aspect an agent needs to call it safely: it explains the return value (only tranId), points to verification tools, lists error codes, and warns about idempotency. The output schema is not present but the description fully explains the return behavior, so nothing essential is missing.

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?

While the schema already provides thorough descriptions for all five parameters (including the enum meaning and isolated-margin pair requirements), the description adds value through two concrete examples and reiterates the from_symbol/to_symbol rules for isolated margin. It also explains the decimal-string amount requirement indirectly via the example. The schema carries the heavy lifting, so a 4 is appropriate rather than a 5.

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 immediately states 'Move funds between the account's OWN wallets' with a clear verb and resource, and explicitly distinguishes internal moves from transfers to other users and withdrawals. It names the exact endpoint and scopes the operation precisely, making it unmistakable what the tool does and how it differs from external transfer tools.

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 includes dedicated 'When to Use' and 'When NOT to Use' sections, explicitly listing approved scenarios (after human approval, funding Pay, sweeping Funding back to Spot) and exclusions (external transfers, swaps, checking history). It names sibling alternatives like convert tools and binance_get_transfer_history, leaving no ambiguity about when to select this tool.

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

Deploy Server