Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_cancel_all_open_orders

DestructiveIdempotent

Cancel every open order on a symbol, including OCO/OTO legs, in one API call. Use to flatten positions or reset strategy when many orders must go quickly.

Instructions

Cancel EVERY open order on one symbol, including order-list legs.

Calls DELETE /api/v3/openOrders (SIGNED, IP weight 1). This is a blunt instrument: it takes no id and cancels whatever is resting on that symbol, OCO/OTO lists included (their legs come back as order-list objects with orderReports[]).

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

When to Use:

  • Flattening the working orders on one symbol — a stop-out or a strategy reset.

  • When several orders must go and cancelling them one by one would race the market.

When NOT to Use:

  • When one specific order should go — use binance_cancel_order with an id.

  • To see what would be cancelled first — call binance_get_open_orders with the same symbol; that read is free of consequence and this one is not.

Returns: A confirmation listing every cancelled order, plus a section per cancelled order list (orderListId, contingencyType, and each leg from orderReports[]).

Examples: params = {"symbol": "BTCUSDT"}

Error Handling: -2011 means there was nothing open on that symbol. A 5xx/timeout leaves the outcome UNKNOWN — re-read with binance_get_open_orders rather than assuming either way.

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 signal destructive/non-read-only behavior, and the description adds meaningful operational context: the BINANCE_ALLOW_TRADING kill-switch, inclusion of OCO/OTO list legs, -2011 semantics, and the UNKNOWN outcome on 5xx/timeout. No contradiction with annotations.

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?

Front-loads the core behavior in the first line, then uses scannable sections for endpoint, usage, exclusions, returns, examples, and errors. Every section adds actionable information rather than filler.

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 invocation, side effects, alternatives, return shape, example, and ambiguous failure outcomes. For a destructive cancel-all operation with an output schema and rich annotations, nothing an agent needs to call it 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 schema covers the single symbol parameter, and the description reinforces it with a concrete example params = {'symbol': 'BTCUSDT'}. Since this is a one-parameter tool, the example plus the 'on one symbol' scope is sufficient compensation for the minimal prose about parameter formatting.

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 an explicit verb and scope: 'Cancel EVERY open order on one symbol, including order-list legs.' It further identifies the exact REST endpoint and contrasts itself with the id-based cancel sibling, so an agent can distinguish it from binance_cancel_order and binance_cancel_order_list immediately.

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?

Provides dedicated 'When to Use' and 'When NOT to Use' sections with concrete scenarios, and names sibling alternatives binance_cancel_order and binance_get_open_orders. This is exactly the routing guidance needed.

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