amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_accept_convert_quote

Execute an approved Binance convert quote to exchange assets at the quoted ratio. Accepting a quote is irreversible and moves real funds, so use only after human approval.

Instructions

Accept a convert quote and EXECUTE the conversion. This moves real funds.

Calls POST /sapi/v1/convert/acceptQuote (SIGNED, UID weight 500). The conversion is irreversible: converting back needs a new quote at whatever ratio the market offers then, so the round trip costs the spread twice.

Kill-switch. Refused with Error: … trading is disabled … unless the server runs with BINANCE_ALLOW_TRADING=1. The gate lives in the HTTP client, so no tool can bypass it. If you see that error, the operator has deliberately put the server in read-only mode — report it, do not try to work around it.

Always price the conversion with binance_get_convert_quote first (it works even with the kill-switch off) and have the human approve that exact quoteId and amount.

When to Use:

Immediately after a human approved the ratio in a fresh quote, before it expires.

When NOT to Use:

To "see what would happen" — that is binance_get_convert_quote.
To convert at a price that is not on offer now — use binance_place_convert_limit_order.

Returns: A confirmation echoing exactly what Binance returned — orderId, createTime and orderStatus verbatim (PROCESS / ACCEPT_SUCCESS / SUCCESS / FAIL). Only SUCCESS means the assets were exchanged; the other statuses are reported as-is with the next step, never paraphrased as "converted".

Examples: params = {"quote_id": "12415572564"}

Error Handling: An expired or already-used quoteId is rejected by Binance — request a new quote rather than retrying this one. A 5xx or a timeout means the execution status is UNKNOWN: check with binance_get_convert_order_status (by quote_id) before accepting anything again — never blind-retry a conversion.

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.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds crucial behavior: irreversible funds movement, the kill-switch and its bypass prevention, error handling for expired quotes, and the meaning of orderStatus values. It fully discloses the irreversible financial impact and operational constraints 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 well-structured with headers (When to Use, When NOT to Use, Returns, Error Handling). The critical warning about moving real funds and irreversibility is front-loaded. Every section adds necessary context; there is no filler or redundancy.

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?

The description covers the full workflow: prerequisite quoting, human approval, execution semantics, status interpretation, error handling for expired quotes and 5xx/timeouts, and the next-step tool (binance_get_convert_order_status). With an output schema present and a thorough description, nothing an agent needs to call this tool safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides a clear description for the sole parameter quote_id ('The `quoteId` returned by `binance_get_convert_quote`. Accepting it EXECUTES the conversion at the quoted ratio.'). The tool description does not add new parameter-level semantics beyond reinforcing the same information. With schema coverage high, a baseline of 3 is appropriate.

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 states a specific action ('Accept a convert quote and EXECUTE the conversion') with a clear resource and consequence ('moves real funds'). It also distinguishes itself from siblings like binance_get_convert_quote (for pricing) and binance_place_convert_limit_order (for non-current prices). The purpose is unambiguous.

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 includes explicit 'When to Use' and 'When NOT to Use' sections, naming the alternative tools and the conditions that select them. It also provides a prerequisite (price with binance_get_convert_quote first) and a kill-switch condition. No ambiguity remains 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