Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_order

Read-onlyIdempotent

Look up a single order's status by Binance order ID or your client order ID. Use after a timeout or error to verify if an order was placed before retrying.

Instructions

Look up one order — open, filled, cancelled or expired — by id.

Calls GET /api/v3/order (SIGNED, IP weight 4). Pass the symbol plus exactly one id: order_id (Binance's numeric orderId) or orig_client_order_id (the id you supplied when placing). Both at once is rejected locally: Binance searches orderId first and would silently ignore a mismatched client id.

When to Use:

  • After a 5xx or a timeout on a placement — this is how you find out whether the order exists before considering a retry.

  • To check the final state of an order that is no longer open.

When NOT to Use:

  • To list what is currently resting — use binance_get_open_orders.

  • To page through history — use binance_get_all_orders.

  • For the individual trades that filled the order — use binance_get_my_trades (trade_history.py).

Returns: A markdown detail block (status, side, type, prices, quantities, timestamps), or the raw Binance object with response_format="json".

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

Error Handling: -2011/-2013 mean no such order for that symbol — check the symbol, or the order may be older than 90 days and archived (-2026). Orders are scoped per symbol: the right id on the wrong symbol looks identical to a missing order.

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?

Annotations already mark this read-only and idempotent, and the description adds significant operational context: SIGNED endpoint, IP weight, local rejection when both IDs are supplied, Binance's orderId-first lookup that silently ignores mismatched client IDs, per-symbol scoping, and 90-day archiving behavior with error codes. 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?

The description is front-loaded with the core lookup semantics, then organized into When/When NOT/Returns/Examples/Error Handling. Every section adds non-redundant information necessary for correct invocation, and the examples are compact and useful.

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 read-only order lookup, the description covers selection criteria, both accepted ID forms, output options, and failure modes. The output schema exists and the description still summarizes the response format, so nothing critical is missing.

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?

With 0% schema description coverage, the description carries the full burden for parameters. It explains symbol, the exactly-one constraint between order_id and orig_client_order_id, why passing both is rejected, what each ID means, and the response_format ('markdown' vs 'json'). This fully compensates for the schema's lack of parameter descriptions.

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 opening sentence states a specific verb ('Look up'), a precise resource ('one order'), and the full state scope ('open, filled, cancelled or expired') by id. It also clearly differentiates from sibling tools in the 'When NOT to Use' list by naming binance_get_open_orders, binance_get_all_orders, and binance_get_my_trades.

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 an explicit 'When to Use' section (post-5xx/timeout placement uncertainty, final status checks) and a 'When NOT to Use' section naming concrete alternatives. This is exactly the guidance an agent needs to avoid mis-selecting among the large sibling tool set.

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