amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_place_convert_limit_order

Place a resting Binance convert limit order that triggers at your target price and converts real funds automatically. Use it to lock in a future conversion rate not currently available.

Instructions

Place a convert LIMIT order: convert automatically if the ratio is reached.

Calls POST /sapi/v1/convert/limit/placeOrder (SIGNED, UID weight 500). The order rests until limit_price is reached or expired_type (1_D / 3_D / 7_D / 30_D) expires it. When it triggers it spends real funds, without asking again.

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.

Check the pair's limits with binance_get_convert_pairs and the amount precision with binance_get_convert_asset_info first; there is no dry-run for this endpoint.

When to Use:

To convert at a ratio the market is not offering right now, after a human approved that price and size.

When NOT to Use:

To convert at the current ratio — quote it with binance_get_convert_quote and accept it, which is immediate and shows you the exact ratio first.
For a spot LIMIT order on a trading pair — that is binance_place_order, a different book with different fees.

Returns: A confirmation echoing exactly what Binance returned — orderId and status verbatim. A resting order is not a conversion: nothing has been exchanged until it triggers, and this confirmation never says otherwise.

Examples: params = {"base_asset": "BTC", "quote_asset": "USDT", "limit_price": "50000", "side": "BUY", "expired_type": "7_D", "quote_amount": "500"}

Error Handling: A rejection about limits means the amount is outside the pair's min/max (binance_get_convert_pairs); -1111 means too many decimals for the asset (binance_get_convert_asset_info); a 5xx or timeout means the order's status is UNKNOWN — check binance_get_convert_open_limit_orders before placing it again.

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?

The description discloses critical behavior beyond annotations: it 'spends real funds, without asking again', has a kill-switch tied to BINANCE_ALLOW_TRADING=1, has no dry-run, and clarifies that a resting order is not yet a conversion. It also explains ambiguous error cases such as 5xx/timeout leaving status UNKNOWN. No contradiction with the annotations exists.

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 section earns its place: risk warning, endpoint context, when/when-not, return semantics, example, and error handling. It is front-loaded with the most important behavioral warning about spending real funds and organized with clear headers.

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 fund-spending, non-idempotent order placement tool, it covers prerequisites, alternatives, return semantics, error ambiguity, and the no-dry-run constraint. The description is complete enough for an agent to invoke the tool correctly and know what to check before and after calling it.

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 schema already documents each parameter in its $defs, including enum meanings and the exactly-one-of base_amount/quote_amount rule. The description adds value through a concrete example and by mapping errors to specific parameters (limit errors to binance_get_convert_pairs, -1111 to binance_get_convert_asset_info), which helps the agent choose values correctly.

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 opening sentence states a specific verb and resource: 'Place a convert LIMIT order: convert automatically if the ratio is reached' and names the exact endpoint. It is clearly distinguished from sibling order-placing tools like binance_place_order and binance_accept_convert_quote.

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 naming alternatives: binance_get_convert_quote for immediate conversions and binance_place_order for spot LIMIT orders. It also tells the agent to check pair limits and asset precision first via binance_get_convert_pairs and binance_get_convert_asset_info.

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

Deploy Server