Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_cancel_order

DestructiveIdempotent

Cancel one open spot order on Binance by its order ID or client order ID. Use it to pull a resting order you no longer want, with optional restrictions to avoid cancelling an order that has started filling.

Instructions

Cancel one open spot order by id.

Calls DELETE /api/v3/order (SIGNED, IP weight 1). Pass the symbol plus exactly one id — order_id or orig_client_order_id; both at once is rejected locally because Binance would resolve the numeric id and ignore a mismatched client id.

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 order returns -2011 ("unknown order") and changes nothing. What it cannot undo is a fill — use cancel_restrictions="ONLY_NEW" to make the cancel fail rather than succeed against an order that has already started filling.

When to Use:

  • To pull a resting order that is no longer wanted.

  • Before replacing an order, when you do not need the atomicity of binance_cancel_replace_order.

When NOT to Use:

  • To cancel everything on a symbol — use binance_cancel_all_open_orders (one call, one weight unit).

  • To cancel one leg of an OCO/OTO list — that cancels the whole list; use binance_cancel_order_list (order_lists.py) so the intent is explicit.

Returns: A confirmation echoing Binance's cancelled-order object: symbol, orderId, origClientOrderId, status (CANCELED), and the executed quantities at cancellation.

Examples: params = {"symbol": "BTCUSDT", "order_id": 123456789} params = {"symbol": "BTCUSDT", "orig_client_order_id": "my-entry-001", "cancel_restrictions": "ONLY_NEW"}

Error Handling: -2011 means the order is not cancellable: it does not exist, already filled, was already cancelled — or cancel_restrictions did not match its current state, which is the safe outcome, not a failure. A 5xx/timeout leaves the cancel UNKNOWN: check with binance_get_order before assuming the order is still live.

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

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses the kill-switch behavior, the local rejection of passing both order_id and orig_client_order_id, the idempotent effect of a second cancel, the inability to undo fills, and the meaning of -2011 errors. It also clarifies that 5xx/timeouts leave cancel state UNKNOWN and advises verification. This substantially exceeds the annotation coverage.

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 tightly organized into labeled sections: core action, kill-switch, idempotency, when to use/not use, returns, examples, and error handling. Each section adds necessary operational knowledge, and the most essential usage constraint is front-loaded in the first sentence.

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 mutation tool with no output schema details needed (output schema is present), the description covers endpoint, signing, IP weight, parameter constraints, error semantics, failure ambiguity, and concrete examples. It leaves no significant gap an agent would need to resolve before calling the tool correctly.

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?

Despite the schema property descriptions, the tool description adds critical semantics: exactly one identifier must be passed, both at once is rejected locally, and why that matters. It also explains cancel_restrictions as the safe guard against racing a fill and interprets -2011 in that context. Examples reinforce correct usage for both identifier variants.

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 open spot order by id.' It also differentiates from siblings by explicitly naming binance_cancel_all_open_orders and binance_cancel_order_list as alternatives for different intents, leaving no ambiguity about what this tool does.

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?

The description provides dedicated 'When to Use' and 'When NOT to Use' sections. It names specific sibling tools and the conditions that should route the agent to them, such as using binance_cancel_all_open_orders for cancelling all orders and binance_cancel_order_list for OCO/OTO legs.

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