amazing-binance-mcp

by trustxai

Overview Schema Source Related Servers Discussions Admin

Python

Local

binance_place_oco_order

Place a Binance OCO bracket order: submit a take-profit and stop-loss pair atomically so one fill cancels the other.

Instructions

Place a REAL one-cancels-the-other pair (take-profit + stop). This spends real money.

Calls POST /api/v3/orderList/oco (SIGNED, IP weight 1, unfilled-order count 2). Both legs carry the same quantity and the same side; when one triggers, Binance cancels the other. This is the bracket around a position you already hold (SELL) or the breakout/dip pair for one you want (BUY).

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.

There is no dry-run for a list. binance_test_order validates ONE order, not a list; run it per leg if you want Binance's filter check before committing.

Leg rules, enforced locally before anything is signed:

exactly one take-profit leg (LIMIT_MAKER / TAKE_PROFIT / TAKE_PROFIT_LIMIT) and one stop leg (STOP_LOSS / STOP_LOSS_LIMIT);
on a SELL the take-profit leg is the above one, on a BUY it is the below one;
the above leg's price must be strictly greater than the below leg's. Binance's full rule is above > last traded price > below, and this server does not know the last traded price — only the relationship between the two prices you pass is checked here. Read the market with binance_get_ticker_price first.

When to Use:

Bracketing an open position with a target and a stop in one atomic request.
Any time two orders must be mutually exclusive — placing them separately risks both filling.

When NOT to Use:

For a single order — binance_place_order (spot_orders.py).
When the bracket should only arm after an entry fills — that is binance_place_otoco_order.
To change an existing list: cancel it with binance_cancel_order_list and place a new one; there is no amend for lists.

Returns: A confirmation echoing exactly what Binance returned: orderListId, contingencyType, listStatusType, listOrderStatus, listClientOrderId, and a ### Legs table built from orderReports when the response carries one (ids only otherwise, and it says so). Nothing is inferred.

Examples: params = {"symbol": "BTCUSDT", "side": "SELL", "quantity": "0.001", "above_type": "LIMIT_MAKER", "above_price": "72000.00", "below_type": "STOP_LOSS_LIMIT", "below_price": "58000.00", "below_stop_price": "58500.00", "below_time_in_force": "GTC", "list_client_order_id": "btc-bracket-001"} params = {"symbol": "BTCUSDT", "side": "BUY", "quantity": "0.001", "above_type": "STOP_LOSS_LIMIT", "above_price": "71000.00", "above_stop_price": "70500.00", "above_time_in_force": "GTC", "below_type": "LIMIT_MAKER", "below_price": "60000.00"}

Error Handling:

Error: … trading is disabled … → the kill-switch is off; nothing was sent.
-2010 → insufficient balance, a symbol filter (LOT_SIZE / PRICE_FILTER / NOTIONAL), or the pair sits on the wrong side of the last traded price.
-2021 means a LIMIT_MAKER leg would have taken liquidity immediately.
-1013 / -1111 are precision / filter errors — read binance_get_exchange_info.
A 5xx or a timeout means the execution status is UNKNOWN — the list may well be live. Query it with binance_get_order_list (by list_client_order_id if you set one) before doing anything else. NEVER resend blindly.

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

A5/5.0

Behavior5/5

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

The description substantially exceeds the coarse annotations (readOnlyHint=false, openWorldHint=true). It discloses a server-side kill-switch with BINANCE_ALLOW_TRADING=1, explains that no tool can bypass it, warns that 5xx/timeout means execution status is UNKNOWN, and details error codes including -2010, -2021, -1013, -1111. This is exactly the behavioral context an agent needs for a real-money mutation.

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: real-money warning, kill-switch, no-dry-run caveat, leg rules, usage routing, return format, examples, and error handling. It is front-loaded with the most critical fact first and uses clear headings and bullets, making the density navigable rather than bloated.

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 complex, high-risk OCO order tool with many interdependent parameters, the description is complete. It covers preconditions, local validation, the missing last-traded-price constraint, return behavior, examples, and error recovery. An agent selecting and invoking this tool would not need to guess about side effects, failure ambiguity, or how to verify outcome.

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?

Although the top-level schema coverage is reported as 0%, the description compensates with high-value semantic rules: both legs share the same quantity and side, the above/below price relationship must satisfy above > below, SELL means the take-profit leg is above while BUY means it is below, and the server cannot verify against last traded price. The two complete examples also disambiguate how the many optional fields fit together.

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: 'Place a REAL one-cancels-the-other pair (take-profit + stop).' It immediately states the real-money consequence and names the endpoint. It also distinguishes itself from siblings in the 'When NOT to Use' section, explicitly routing to binance_place_order for single orders and binance_place_otoco_order for delayed brackets.

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 is a dedicated 'When to Use' and 'When NOT to Use' section with explicit alternatives: binance_place_order for single orders, binance_place_otoco_order for post-entry brackets, and binance_cancel_order_list for amending lists. It also states there is no dry-run for lists and tells the agent to use binance_test_order per leg, making the routing decision unambiguous.

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

Deploy Server