Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_transfer_history

Read-onlyIdempotent

List past Binance wallet transfers in one direction (e.g., Spot to Funding) to reconcile balances or trace Funding-wallet activity. Specify the transfer type to see history.

Instructions

List past transfers between the account's own wallets, one direction at a time.

Calls GET /sapi/v1/asset/transfer (SIGNED, IP weight 1). Unlike the POST that performs a transfer, this read does not need the key's "Permits Universal Transfer" flag.

type is mandatory and Binance offers no "all directions" value: MAIN_FUNDING and FUNDING_MAIN are two separate queries, so a full Spot⇄Funding picture costs two calls. MAIN_FUNDING / FUNDING_MAIN is also the closest proxy to a Binance Card top-up log, since the card was funded out of the Funding wallet.

When to Use:

  • To reconcile where a balance went between wallets.

  • To reconstruct Funding-wallet activity that Pay/fiat history does not explain.

When NOT to Use:

  • For deposits/withdrawals to and from other platforms — use binance_get_deposit_history / binance_get_withdraw_history (wallet_capital.py).

  • To perform a transfer — that is binance_transfer_between_wallets.

Returns: Binance's {total, rows} rendered as a markdown table of time / asset / amount / type / status / tranId, with the page position and the per-asset totals of the rows shown, or the raw envelope with response_format="json".

Pagination: page → Binance's current (1-based), limit → Binance's size (max 100, Binance default 10). total in the response is the full count for the filter, so page * limit < total means there is more.

Windows: Binance "supports query within the last 6 months only" and defaults to the last 7 days when start_time/end_time are omitted — so an empty result with no window given usually means "nothing in the last week", not "never". Pass start_time to look further back.

Examples: params = {"type": "MAIN_FUNDING"} params = {"type": "FUNDING_MAIN", "start_time": "2026-03-01", "limit": 100}

Error Handling: -2015 means the key lacks Reading permission or this IP is not allowlisted. Dates more than 6 months old simply return nothing.

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.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint; the description adds meaningful context: the key does not need the 'Permits Universal Transfer' flag, the type parameter has no 'all directions' option, default window is 7 days, and error code -2015 meaning. These details go well beyond the annotations and aid correct usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized with clear sections (purpose, usage, returns, pagination, windows, examples, errors). Every section carries useful information, though it could be tightened without losing value. Front-loaded with the core purpose and key constraints.

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?

Covers the API endpoint, authentication flag, direction semantics, pagination logic, time window defaults, examples, and error handling. An output schema exists so return format details are not necessary, but the description still mentions the markdown/json rendering. Nothing essential for a correct call 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?

The input schema provides detailed descriptions for every parameter (type enum with full list, page/limit ranges, time formats). The description supplements this with practical guidance: type is mandatory with no all-directions value, start_time for looking back, pagination mapping, and window default. Adds value beyond the schema without repeating it fully.

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 lists past transfers between the account's own wallets, one direction at a time, and explicitly distinguishes it from deposit/withdraw history and the transfer execution tool. The purpose is unambiguous and sibling differentiation is explicit.

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?

Contains dedicated 'When to Use' and 'When NOT to Use' sections, naming alternative tools (binance_get_deposit_history, binance_get_withdraw_history, binance_transfer_between_wallets) and the conditions that select them. No ambiguity about when to call 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