Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_all_my_trades

Read-onlyIdempotent

Get a complete history of every executed trade across all Binance symbols in one call. Handles Binance's per-symbol API limit by walking each traded symbol and returning a resumable cursor for large exports.

Instructions

Collect every fill across every symbol this account traded — the "all my trades" answer.

Binance has no such endpoint (myTrades needs a symbol; staff confirm the gap on dev.binance.vision threads 4810 and 4329), so this tool does the only thing that works over REST: take a symbol list — yours, or one from binance_discover_traded_symbols — and walk each symbol by fromId at 1000 fills a page until a short page says that symbol is exhausted.

Two brakes keep it inside the 6000/min IP budget. max_weight (default 3000 = 150 pages) is checked before every request, and the walk also stops when Binance's own reported used weight passes weight_ceiling (default 5000). When either fires — or when a request errors mid-walk — the fills collected so far are returned together with a cursor, so nothing is lost and the next run resumes exactly there.

Cost, so nobody is surprised: 20 IP weight per page per symbol. 150 symbols with no trades still costs 3000 weight. Walking all 1370 TRADING symbols would cost 27,400 — about five minutes of full budget — which is why discovery narrows the list first.

When to Use:

  • "Show me every trade I have ever made", tax/portfolio reconstruction, a full export.

  • Incremental top-ups: keep the returned cursor and pass it back next time.

When NOT to Use:

  • For one pair — binance_get_my_trades is one call.

  • For orders that never filled, deposits, withdrawals, converts or Pay/Card spending: those are different endpoints (spot_orders, wallet_capital, convert, pay).

Returns: Markdown: the walk status (symbols finished, calls, weight), a time-sorted table of up to 200 fills, per-symbol totals (fills, bought/sold base and quote, fees by asset) and the next cursor as a JSON block to paste back. JSON: the same data with every fill.

Pagination: cursor maps symbol → the last trade id already collected; the walk restarts each symbol at that id + 1, so re-running is cheap and never duplicates a fill. Symbols the budget never reached keep whatever position the cursor already held. A symbol that returns no trades gets no cursor entry, so every incremental run re-checks it from scratch at 20 weight a time — drop the empties from symbols once you know them.

Examples: params = {} params = {"symbols": ["BTCUSDT", "ETHUSDT"], "max_weight": 200} params = {"symbols": ["BTCUSDT"], "cursor": {"BTCUSDT": 4211999}}

Error Handling: An error mid-walk never discards work: the partial fills plus the cursor come back alongside the error text. -2015 means the key lacks Reading or the IP is not allowlisted; a 429/418 means the budget was already spent elsewhere — lower weight_ceiling and wait a minute.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds substantial behavioral context beyond that: the pagination strategy (fromId, 1000 fills/page), the two budget brakes (max_weight and weight_ceiling), the cost model (20 IP weight per page per symbol), the cursor semantics, and the error-handling behavior (partial results returned with cursor on error). It also explains what happens with empty symbols and how to avoid re-checking them. This is rich, honest behavioral disclosure.

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 every section earns its place: the endpoint gap rationale, the two brakes, the cost model, when-to-use, when-not-to-use, returns, pagination, examples, and error handling. It is well-structured with clear headers and front-loaded with the core purpose. It loses one point for length — some details (e.g., the dev.binance.vision thread numbers) are arguably noise for an agent selecting a tool — but the structure keeps it navigable.

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 (multi-symbol pagination, budget management, cursor resumption, discovery fallback), the description is remarkably complete. It covers cost, error handling, return format, pagination semantics, and examples. The output schema exists, so return values are further specified. An agent has everything needed to invoke this tool correctly and to decide when it is the right choice.

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?

Schema description coverage is 0% per the context signal, but the description compensates thoroughly for the main parameters: symbols, cursor, max_weight, weight_ceiling are all explained with defaults and semantics. The discovery-related parameters (extra_assets, quote_assets, include_break) are only mentioned indirectly via 'same params as binance_discover_traded_symbols', which is a reasonable pointer but leaves some detail to the sibling. The response_format parameter is covered by the schema's own description. Overall, the description adds significant meaning beyond the schema.

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 and resource: 'Collect every fill across every symbol this account traded' — the 'all my trades' answer. It explicitly distinguishes itself from binance_get_my_trades (single pair) and explains the workaround for Binance's missing endpoint. This is a model of purpose clarity.

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 has explicit 'When to Use' and 'When NOT to Use' sections. It names the alternative for single-pair queries (binance_get_my_trades), lists excluded transaction types (orders, deposits, withdrawals, converts, Pay/Card), and gives concrete use cases (tax/portfolio reconstruction, incremental top-ups). This is exactly the guidance an agent needs.

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