Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_cancel_replace_order

Destructive

Cancel an existing order and place its replacement in one atomic request, avoiding the exposure gap of a separate cancel-then-place. Use it to reprice or resize a resting limit order or roll a stop as the market moves.

Instructions

Cancel one order and place its replacement in a single request.

Calls POST /api/v3/order/cancelReplace (SIGNED, IP weight 1, unfilled-order count 1). Use it to reprice a resting order without the window of exposure that a separate cancel-then-place leaves open.

Kill-switch. Refused with Error: … trading is disabled … unless the server runs with BINANCE_ALLOW_TRADING=1.

The two halves can diverge, and cancel_replace_mode decides how:

  • STOP_ON_FAILURE — if the cancel fails, the new order is never attempted.

  • ALLOW_FAILURE — the new order is attempted regardless of the cancel's outcome, so you can end up with both orders live, or neither.

HTTP 409 is the partial-success case: the cancel succeeded and the new order failed. It is returned as Error (409): Partial success … followed by the same cancelResult / newOrderResult breakdown as a success — so you can see exactly which order was cancelled. Read it as "the old order is gone, the replacement is NOT live" and re-place deliberately.

When to Use:

  • Repricing or resizing a resting limit order.

  • Rolling a stop as the market moves.

When NOT to Use:

  • For a fresh order with nothing to cancel — use binance_place_order.

  • To only pull an order — use binance_cancel_order.

  • On an order-list leg — cancel the list with binance_cancel_order_list (order_lists.py) and place a new list.

Returns: cancelResult and newOrderResult (SUCCESS / FAILURE / NOT_ATTEMPTED) plus the two response objects Binance returned, rendered separately so it is unambiguous which order is live.

Examples: params = {"symbol": "BTCUSDT", "side": "BUY", "type": "LIMIT", "time_in_force": "GTC", "quantity": "0.001", "price": "19500.00", "cancel_replace_mode": "STOP_ON_FAILURE", "cancel_order_id": 123456789} params = {"symbol": "BTCUSDT", "side": "BUY", "type": "LIMIT", "time_in_force": "GTC", "quantity": "0.002", "price": "19000.00", "cancel_replace_mode": "ALLOW_FAILURE", "cancel_orig_client_order_id": "my-entry-001", "cancel_restrictions": "ONLY_NEW"}

Error Handling: HTTP 409 = cancel succeeded, replacement failed (see above). -2021/-2022 wrap the failing half in {code, msg, data}. -2011 means the order to cancel was not cancellable (filled, gone, or cancel_restrictions did not match). A 5xx/timeout leaves BOTH halves UNKNOWN: read binance_get_open_orders for the symbol before sending anything else.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations: it discloses the kill-switch requiring BINANCE_ALLOW_TRADING=1, explains STOP_ON_FAILURE vs ALLOW_FAILURE divergence, interprets HTTP 409 as the partial-success case, and warns that 5xx/timeouts leave both halves UNKNOWN. This richly supplements the destructiveHint and openWorldHint annotations without contradicting them.

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?

Long but disciplined: the core behavior is front-loaded, followed by kill-switch, mode semantics, HTTP 409 interpretation, use cases, exclusions, return values, and error handling in clearly separated sections. Every paragraph earns its place and the examples are highly illustrative for an agent.

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 high-complexity, destructive atomic operation this is complete: it explains partial success, ambiguous failure states, error codes, return shape, and when to check binance_get_open_orders after a 5xx. Nothing an agent needs to invoke and interpret this tool correctly is missing.

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 prose adds real meaning to the parameters: it explains how cancel_replace_mode changes the operation's outcome, clarifies the cancelResult/newOrderResult semantics, and gives two concrete example parameter sets showing cancel_order_id vs cancel_orig_client_order_id. The schema already documents individual fields thoroughly, so the description complements rather than merely repeats — though a dedicated sentence on the either-or cancel identifier requirement would push it to 5.

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 — 'Cancel one order and place its replacement in a single request' — and names the exact endpoint. It explicitly differentiates itself from sibling tools such as binance_place_order, binance_cancel_order, and binance_cancel_order_list, leaving no ambiguity about scope.

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?

Dedicated 'When to Use' and 'When NOT to Use' sections give explicit conditions: reprice a resting order, roll a stop, and clearly route to alternative tools for fresh orders, pure cancels, or order-list legs. This is textbook usage guidance.

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

Deploy Server

Other Tools