Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_cancel_order_list

DestructiveIdempotent

Cancel an entire Binance order list by its ID, removing all legs in one request. Pass the symbol with either order_list_id or list_client_order_id to pull a bracket order before replacing it.

Instructions

Cancel an ENTIRE order list — every leg of it — by id.

Calls DELETE /api/v3/orderList (SIGNED, IP weight 1). Pass the symbol plus exactly one id: order_list_id or list_client_order_id. Both at once is rejected locally.

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

Cancelling is idempotent in effect: a second cancel of the same list returns -2011 ("unknown order") and changes nothing. What it cannot undo is a fill — a leg that has already triggered is gone, and its sibling with it. Note that cancelling ONE leg (via binance_cancel_order) also cancels the whole list; this tool just makes the intent explicit.

When to Use:

  • Pulling a bracket that is no longer wanted, before replacing it.

  • Cleaning up after a partial fill changed the position the bracket was sized for.

When NOT to Use:

  • To cancel everything on a symbol, lists included — binance_cancel_all_open_orders (spot_orders.py) does it in one call.

  • To see what would be cancelled — binance_get_order_list first; that read is free of consequence and this one is not.

Returns: A confirmation echoing the cancelled list: orderListId, contingencyType, listStatusType, listOrderStatus and the ### Legs table from orderReports[] with each leg's status (CANCELED) and its original client id.

Examples: params = {"symbol": "BTCUSDT", "order_list_id": 27} params = {"symbol": "BTCUSDT", "list_client_order_id": "btc-bracket-001", "new_client_order_id": "cancel-bracket-001"}

Error Handling: -2011 means the list is not cancellable: it does not exist, already completed, or was already cancelled. A 5xx/timeout leaves the cancel UNKNOWN: check with binance_get_order_list before assuming either way — do not assume the legs are gone.

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?

Annotations already indicate destructive, idempotent, and non-read-only behavior, and the description adds substantial context: the BINANCE_ALLOW_TRADING=1 kill-switch, the -2011 idempotent no-op case, the risk of partial fills, and the unknown state after 5xx/timeout. This goes well beyond what annotations alone provide.

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 highly structured with clear headers, bullets, examples, and error handling. The main purpose is front-loaded, and every section adds actionable information for a dangerous mutation tool without 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?

Covers the endpoint, authentication signature, server-side kill-switch, idempotency, error semantics, return shape, examples, and when to check the list status afterward. Combined with the output schema and annotations, an agent has everything needed to invoke this tool correctly and safely.

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 critical meaning not obvious from the schema: exactly one of order_list_id or list_client_order_id must be passed, both at once are rejected locally, and cancelling a leg also cancels the whole list. The example illustrates the optional new_client_order_id usage, though it does not exhaustively restate every parameter's constraints.

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?

States a specific verb and resource: cancel an ENTIRE order list by id, explicitly noting every leg is affected. This clearly differentiates it from single-order cancel tools like binance_cancel_order and bulk-cancel binance_cancel_all_open_orders.

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?

Includes explicit 'When to Use' and 'When NOT to Use' sections, naming alternatives such as binance_cancel_all_open_orders and binance_get_order_list. It also explains when cancelling one leg via binance_cancel_order makes this tool redundant, giving an agent actionable routing rules.

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