amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_get_pay_transactions

Read-onlyIdempotent

Retrieve Binance Pay transactions—merchant payments, C2C transfers, refunds, payouts—within a 90-day window. Filter by wallet type or time range to identify which funding wallet supported each payment.

Instructions

Fetch Binance Pay transactions (merchant payments, C2C, refunds, payouts) for the account.

Calls GET /sapi/v1/pay/transactions (UID weight 3000). Binance Card spending is NOT available via API — this only shows Binance Pay activity; a payment funded by the Binance Card appears here with walletType 4 or 6 ("card"), which is the closest visibility this server has into card usage.

When to Use:

To review recent (<= 90 day) Binance Pay activity: merchant payments, C2C transfers, refunds, crypto box, payouts, remittances.
To find which wallet funded a Pay payment — pass wallet_type or read the rendered wallet name (funding/spot/fiat/card/earn).

When NOT to Use:

For a span over 90 days, or to page past the first 100 rows of a dense window — use binance_get_pay_history, which walks and bisects the window for you.
To see Binance Card POS spend — no endpoint returns that (03-card-and-gaps.md §1); this only shows card-funded Pay payments, not card terminal purchases.

Returns: Markdown list (or JSON) of transactions: time, orderType, signed amount (+ income / - expenditure) and currency, walletType name, the counterparty name, and transactionId. Markdown display is capped at 50 rows with a note pointing at a narrower window or binance_get_pay_history; response_format="json" always carries every row this call fetched (still limit-capped by the API itself, <= 100).

Pagination/Windows: start_time/end_time accept an ms epoch, a >=12-digit epoch-ms string, or an ISO-8601 string. Give both together (span <= 90 days) or neither — Binance's behavior for a single bound is undocumented for this endpoint, so a lone bound is rejected locally with a clear Error: rather than sent on. When both are omitted, Binance returns the most recent 90 days. limit is <= 100 (this endpoint's own max).

Examples: params = {"wallet_type": 4} # only card-funded Pay payments params = {"start_time": "2026-06-01", "end_time": "2026-08-01"}

Error Handling: -1127 means the startTime/endTime span exceeds Binance's cap (should not happen — this tool validates first); -2015 means the key lacks permission or the IP is not on the key's allowlist.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context: UID weight 3000, the 90-day window behavior, the local rejection of a lone time bound, the 50-row markdown cap, the client-side wallet_type filter, and error code meanings. This goes well beyond what annotations provide.

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: scope, when/when-not, returns, pagination, examples, error handling. It is well-structured with clear headers and front-loads the core purpose. Slightly verbose in places (e.g., the card-funded explanation repeats), but the density of useful information justifies the length.

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?

For a read-only list tool with an output schema, this description is complete. It covers the API endpoint, weight, time window constraints, pagination, output format differences, error codes, and the relationship to the sibling tool. An agent has everything needed to select and invoke this tool correctly, including edge cases like lone time bounds and the 50-row markdown cap.

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?

Schema description coverage is 0% for the top-level params object, but the nested PayTransactionsInput schema actually documents each parameter well. The description adds meaning beyond the schema: it explains the walletType 4/6 card semantics, the signed amount (+/-) meaning, the markdown cap behavior, and the local validation of lone time bounds. It also gives concrete examples for wallet_type and time windows.

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: 'Fetch Binance Pay transactions (merchant payments, C2C, refunds, payouts)'. It names the exact API endpoint and clearly distinguishes itself from the sibling binance_get_pay_history by stating what it does NOT cover (Binance Card POS spend) and what it does cover (card-funded Pay payments).

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 tool (binance_get_pay_history) and the exact conditions that select it (span over 90 days, paging past 100 rows). It also states a hard limitation (no Binance Card POS spend endpoint) with a file reference.

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

Deploy Server