Skip to main content
Glama
trustxai

amazing-binance-mcp

by trustxai

binance_get_open_algo_orders

Read-onlyIdempotent

List currently working spot TWAP algo orders across all symbols to confirm a placement, check free slots before, or verify existence after a timeout.

Instructions

List the spot TWAP algo orders that are still working, across every symbol.

Calls GET /sapi/v1/algo/spot/openOrders (SIGNED, IP weight 1). It takes no filters: one call returns everything currently running, which is also how you check the 20 open algo orders ceiling before placing another.

When to Use:

  • Right after binance_place_twap_order, to confirm the order is actually working — the placement response only says "accepted".

  • Before placing a new TWAP, to see how many of the 20 slots are free.

  • After a 5xx/timeout on a placement, to find out whether the order exists.

When NOT to Use:

  • For orders that have finished — use binance_get_algo_order_history.

  • For the fills of one order — use binance_get_algo_sub_orders.

  • For ordinary spot orders — use binance_get_open_orders (spot_orders.py); algo and ordinary orders live in separate endpoints and neither lists the other.

Returns: A markdown table (bookTime, algoId, symbol, side, algoStatus, algoType, totalQty, executedQty, executedAmt, avgPrice, urgency, endTime) capped at 50 rows, or the raw {total, orders[]} payload with response_format="json" (which also carries clientAlgoId).

Examples: params = {} params = {"response_format": "json"}

Error Handling: An empty list is a valid answer: nothing is working. -2015 means the key lacks Reading permission or this IP is not allowlisted. /sapi does not exist on the spot testnet — a 404 there is expected, not a bug.

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.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context beyond that: it takes no filters, returns an empty list as a valid result, explains the 20 open algo orders ceiling, and details error handling (-2015 permission/allowlist, testnet 404). 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 well-structured with clear sections: purpose, when/not, returns, examples, error handling. It is front-loaded with the core purpose and scoping, and every section earns its place. Despite length, it is efficient and easy to scan.

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?

Given the simple one-parameter schema and strong annotations, the description is thorough: it covers usage scenarios, exclusions, return formats, error codes, and the 20-slot ceiling. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the single parameter response_format with enum, default, and a description stating 'markdown' vs 'json (raw Binance payload)'. The tool description adds detail about the markdown table columns and the extra clientAlgoId field in JSON, but this is marginal beyond the schema's own description. With schema coverage high, baseline 3 is appropriate.

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 states a specific verb ('List'), resource ('spot TWAP algo orders'), and scope ('still working, across every symbol'). It immediately distinguishes this from other order tools by name in the NOT-to-use section, so an agent can differentiate it from binance_get_algo_order_history, binance_get_algo_sub_orders, and binance_get_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?

Explicit 'When to Use' and 'When NOT to Use' sections name exact alternative tools and the conditions that select them (e.g., after placement, before placing to check the 20-slot ceiling, after 5xx; finished orders go to history, fills go to sub_orders, ordinary orders go to open_orders). This leaves nothing to inference.

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