amazing-binance-mcp

Overview Schema Source Related Servers Discussions Admin

binance_place_order

Place a real spot order on Binance when you're ready to trade: submit limit, market, or stop-loss orders with validated parameters after a dry run passes.

Instructions

Place a REAL spot order on Binance. This spends real money.

Calls POST /api/v3/order (SIGNED, IP weight 1, unfilled-order count 1). A MARKET order executes immediately at whatever the book offers; a LIMIT order rests until it fills, expires or is cancelled.

Kill-switch. This call is 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 run binance_test_order first with identical parameters: it is allowed even with the kill-switch off and catches filter/precision rejections for free.

When to Use:

After a dry-run passed and the human has approved this specific order.
To act on a decision that already names symbol, side, type, quantity and price.

When NOT to Use:

To "see if it would work" — that is binance_test_order.
For a bracket/OCO (entry plus stop plus target) — use the order-list tools in order_lists.py, which place the legs atomically.
To modify a resting order — use binance_cancel_replace_order, which does not leave you unhedged between the two calls.

Returns: A confirmation echoing exactly what Binance returned: symbol, orderId, clientOrderId, status, executedQty, cummulativeQuoteQty, and the fills table when the response carries one. Nothing is inferred: with new_order_resp_type="ACK" Binance reports only the ids, and the confirmation says so rather than implying a fill. When Binance answers EXPIRED / EXPIRED_IN_MATCH / REJECTED the heading reads Order NOT live — an IOC/FOK that never rested is not a placed order.

Examples: params = {"symbol": "BTCUSDT", "side": "BUY", "type": "LIMIT", "time_in_force": "GTC", "quantity": "0.001", "price": "20000.00", "new_client_order_id": "my-entry-001"} params = {"symbol": "BTCUSDT", "side": "SELL", "type": "MARKET", "quantity": "0.001"} params = {"symbol": "BTCUSDT", "side": "SELL", "type": "STOP_LOSS_LIMIT", "time_in_force": "GTC", "quantity": "0.001", "price": "19000.00", "stop_price": "19100.00"}

Error Handling:

Error: … trading is disabled … → the kill-switch is off; nothing was sent.
-2010 (order rejected) → insufficient balance, or a symbol filter: quantity off the LOT_SIZE step, price off the PRICE_FILTER tick, or the order under the NOTIONAL minimum. Read the filters with binance_get_exchange_info and re-run the dry-run.
-1013 / -1111 are the same family (precision / filter).
-2021 means a LIMIT_MAKER would have taken liquidity immediately.
A 5xx or a timeout means the execution status is UNKNOWN — the order may well be live. Query it with binance_get_order (by new_client_order_id if you set one) or binance_get_open_orders before doing anything else. NEVER resend blindly: a duplicate market order is real money lost.

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 the kill-switch behavior and `BINANCE_ALLOW_TRADING=1` requirement, real-money risk, market-vs-limit execution semantics, and the critical unknown-state-after-5xx behavior. It also warns never to blindly resend a duplicate market order. Annotations already mark `readOnlyHint: false`, and the description reinforces that rather than contradicting it.

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?

Though long, the description is tightly structured with bold section headers, bullet risk callouts, and clean example blocks. Every section serves a purpose: endpoint metadata, kill-switch, usage boundaries, return behavior, and error handling. The length is justified by the high-stakes nature of real-money trading.

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 tool that places real orders, the description covers everything needed to call it safely: the operational precondition, pre-flight testing requirement, when-not-to-use alternatives, response semantics, error taxonomy, and post-timeout verification steps. The output schema is also present, so return-value details are reinforced by structured data.

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 description adds meaningful behavioral context for order types (MARKET executes immediately, LIMIT rests) and maps error codes to parameter issues like LOT_SIZE and PRICE_FILTER. The input schema's $defs already provides thorough per-parameter descriptions, so the description doesn't need to repeat every field. Examples further clarify realistic parameter combinations.

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 'Place a REAL spot order on Binance' and names the exact endpoint, making the operation unmistakable. It also differentiates itself from `binance_test_order`, OCO/OTO order-list tools, and `binance_cancel_replace_order`, so an agent can tell this tool apart from its close siblings.

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?

There are explicit 'When to Use' and 'When NOT to Use' sections that name alternatives with conditions: use it only after a dry-run passes, use `binance_test_order` for dry-runs, use order-list tools for OCO brackets, and use `binance_cancel_replace_order` for modifications. The guidance to always run `binance_test_order` first is prescriptive and actionable.

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

Deploy Server