Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_withdraw_history

Read-onlyIdempotent

Retrieve crypto withdrawal history within a 90-day window, filterable by coin, status, or withdrawal ID, with network fees and completion times for reconciling outgoing transfers.

Instructions

List crypto withdrawals out of the account for one window (up to 90 days).

Calls GET /sapi/v1/capital/withdraw/history (SIGNED). This is a read — this server can never submit a withdrawal: POST /sapi/v1/capital/withdraw/apply is on the client's forbidden-path list and no tool exists for it.

⚠️ Cost: UID weight 18000 per call (a tenth of the 180000/min per-account budget) and a hard limit of 10 requests per second on this endpoint — Binance reports the per-second usage in X-SAPI-USED-UID-WEIGHT-1S. Do not poll it.

Each row includes transactionFee, the network fee Binance charged for that withdrawal, so the true cost of moving funds out is readable here.

When to Use:

  • "Did my withdrawal go through, and what did it cost?" — a recent, bounded lookup.

  • Looking up specific withdrawals by withdraw_order_id or id_list.

When NOT to Use:

  • For the full history since the account opened — use binance_get_all_withdrawals, which budgets these expensive calls for you.

  • For deposits — use binance_get_deposit_history.

  • To MAKE a withdrawal — impossible by design; use the Binance app.

Returns: A markdown table (applyTime, completeTime, coin, amount, transactionFee, network, status, walletType, txId, withdrawOrderId) plus per-coin totals including fees, capped at 50 displayed rows; or the raw Binance array with response_format="json".

Pagination: limit is 1-1000 (Binance default 1000) and offset pages within the window. id_list accepts at most 45 ids and is sent comma-separated.

Windows: start_time/end_time together must span under 90 days — under 7 days when withdraw_order_id is set (Binance's own rule; it also defaults to the last 7 days in that case). Both caps are enforced locally.

Examples: params = {"coin": "BTC", "status": "completed"} params = {"start_time": "2026-08-01", "end_time": "2026-09-01"} params = {"id_list": ["b6ae22b3aa844210a7041aee7589627c"], "response_format": "json"}

Error Handling: An over-wide window is rejected locally. -2015 means the key lacks Reading permission or this IP is not allowlisted. A 429 here means the 10 req/s ceiling was hit — back off, do not retry in a loop.

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?

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses critical operational behavior: the endpoint is SIGNED, the server can never submit a withdrawal, there is a UID weight cost of 18000 per call and a 10 req/s hard limit, and 429 handling is specified. It also covers local enforcement of window caps and authentication errors (-2015). This adds significant context 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 every section earns its place: purpose is front-loaded, followed by cost/rate limits, usage guidance, return format, pagination, windows, examples, and error handling. The use of headings and bullet lists makes it scannable, and there is no redundant prose.

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 tool's complexity and the presence of an output schema, the description covers all agent-relevant aspects: safety (read-only, no withdrawal submission), cost/rate limits, authentication errors, pagination, window constraints, output formats, and examples. Error handling is also included, making the description self-sufficient for correct invocation.

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?

With schema description coverage reported at 0%, the description carries full responsibility for parameter meaning. It explains limit range and default, offset paging, id_list max 45 and comma-separated format, window caps (90 days; 7 days with withdraw_order_id), response_format options, and provides three concrete examples covering coin/status, time windows, and id_list+json. This fully compensates for the missing schema descriptions.

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 opens with a specific verb+resource+scope: 'List crypto withdrawals out of the account for one window (up to 90 days)'. It explicitly differentiates from siblings by naming binance_get_all_withdrawals for full history and binance_get_deposit_history for deposits, so an agent can immediately distinguish it from similar 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 'When to Use' and 'When NOT to Use' sections give explicit guidance including concrete scenarios ('Did my withdrawal go through...?'), alternative tool names, and a clear exclusion ('To MAKE a withdrawal — impossible by design'). This leaves no ambiguity about when to invoke 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

Other Tools