Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_all_deposits

Read-onlyIdempotent

Fetch complete deposit history from Binance, automatically walking 90-day API windows with pagination and resume support.

Instructions

Every crypto deposit since since — the 90-day cap walked for you.

Binance only answers 90 days at a time, so this walks untilsince in 89-day windows, newest first, paging offset by 1000 inside each window until a short page proves it is drained. Rows are deduped by their Binance id, so overlapping windows (and a resumed run) can never double-count.

since defaults to 2017-07-01, Binance's launch: there is no API that reports when an account was created — apiRestrictions.createTime is the API KEY's date, not the account's — so "everything" means "since the exchange existed". Windows before the account opened simply return nothing.

Cost: GET /sapi/v1/capital/deposit/hisrec is IP weight 1, so the default max_calls=60 (≈ 15 years of windows) is cheap. The budget is checked BEFORE every request and the reported call count is the real one.

When to Use:

  • "Show me every deposit I have ever made" — the headline question.

  • Reconstructing cost basis or an audit trail of money coming IN.

When NOT to Use:

  • For one recent window — binance_get_deposit_history is one call.

  • For withdrawals — use binance_get_all_withdrawals.

  • For fiat on-ramps (card/bank) — use binance_get_fiat_orders / binance_get_fiat_payments (fiat.py); they are a different rail.

Returns: Rows sorted newest-first with per-coin totals (count + summed amount). Markdown displays at most 50 rows; response_format="json" returns {count, truncated, no_progress, since, until, resume_before, calls_made, totals, items} with the full set. truncated is true exactly when the walk did not reach since; no_progress is true when it did not finish even the first window, and then resume_before is null on purpose — see Pagination.

Pagination: If the walk stops before since — budget exhausted, or an error — it returns the rows it already has PLUS resume_before, the boundary of the next UNFETCHED range. Call again with the same since and that resume_before to continue. A stop in the middle of a window re-fetches that window, which the dedupe makes harmless. If it stopped without completing even the FIRST window there is no cursor to give: resume_before comes back null with no_progress: true, because repeating the run with resume_before = until would re-issue the identical calls forever. Raise max_calls (or fix the error) and re-run the same range instead.

Examples: params = {} params = {"since": "2024-01-01", "coin": "USDT"} params = {"since": "2017-07-01", "resume_before": 1717200000000, "response_format": "json"}

Error Handling: An over-wide-window error from Binance is tolerated: the window is halved and retried. Anything else — auth (-2015), rate limits (429/418), a Binance envelope failure — stops the walk immediately and is reported alongside the rows already collected and the resume cursor, so nothing fetched is ever thrown away.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes far beyond by explaining the windowed walk (89-day windows, offset paging), deduplication by Binance id, the default since date and its rationale, cost per call, budget checking, resume cursor semantics, error handling (window halving, stop conditions), and exactly what truncated/no_progress mean. This rich behavioral detail is essential for correct invocation and is not available from annotations alone. No contradiction with 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 sentence earns its place. It is structured with clear headers (When to Use, When NOT to Use, Returns, Pagination, Examples, Error Handling) and front-loaded with the core behavior. There is no fluff; each paragraph addresses a distinct aspect an agent must know. The length is proportional to the tool's complexity.

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 (windowed pagination, resume cursors, deduplication, error recovery), the description covers all operational concerns: what it returns, how to continue a partial run, how to interpret flags, and how errors are handled. It also notes the output schema's JSON structure and the markdown row limit. An agent has everything needed to invoke it correctly and interpret results without further guesswork.

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 schema already describes each parameter (since, until, max_calls, resume_before, response_format), the description adds crucial semantics: the walk algorithm for since/until, the meaning and handling of resume_before (it replaces until), the default max_calls covering 15 years, and the response_format differences (markdown truncation vs full JSON structure). This goes well beyond the schema's basic field descriptions and clarifies inter-parameter behavior.

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 precise, specific statement: 'Every crypto deposit since `since` — the 90-day cap walked for you.' It clearly identifies the resource (crypto deposits) and the action (retrieve all since a date). It further distinguishes itself from siblings by explicitly naming alternatives (binance_get_deposit_history for recent windows, binance_get_all_withdrawals for withdrawals, binance_get_fiat_orders for fiat rails). No ambiguity remains about what this tool does.

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 contains dedicated 'When to Use' and 'When NOT to Use' sections. It lists concrete use cases ('Show me every deposit I have ever made', reconstructing cost basis) and explicit exclusions with the exact sibling tool to use instead. This is the gold standard for usage guidance—an agent is never left guessing when to pick 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