Skip to main content
Glama
nexus-xyz

nexus-exchange-mcp

Official
by nexus-xyz

place_orders_batch

Submit up to 100 real orders in one request, each matching create_order fields; requires API credentials. Deprecated: use create_orders.

Instructions

Deprecated: use create_orders. Submit multiple orders in one request. Each order has the same shape as create_order (market_id, side, type, size, and the type-dependent price / trigger_price / trailing offsets / time_in_force / reduce_only). Requires API credentials. This submits REAL orders to the matching engine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ordersYesOrders to submit (1–100). Each uses the create_order arg shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / orders / description
      Previous value: -"Orders to submit (1–100). Each uses the place_order arg shape."New value: +"Orders to submit (1–100). Each uses the create_order arg shape."
  2. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / orders / items / properties / limit_offset_bps
      Added value: +{
      +  "description": "Fire-time limit-price offset in basis points (`trailing_limit` only; required together with `trailing_offset_bps`). The rested limit sits at fire_price * (1 + offset) for buys / * (1 - offset) for sells; 0 rests exactly at the fire price.",
      +  "maximum": 9999,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / orders / items / properties / price / description
      Previous value: -"Limit price as a positive decimal string (> 0). Required for limit orders, ignored for market."New value: +"Limit price as a positive decimal string (> 0). Required for limit-family orders (`limit`, `stop_limit`, `take_profit_limit`); must be omitted for market, stop_market, take_profit_market, and trailing orders (which are priced by the engine or computed at fire time)."
    • addedInput schema / properties / orders / items / properties / trailing_offset_bps
      Added value: +{
      +  "description": "Trailing trigger offset in basis points (1 bp = 0.01%). Required for trailing orders (`trailing_stop`, `trailing_limit`); must be omitted otherwise. Fires once the mark price retraces from its best-seen extreme by this many bps (0 fires at the first evaluation).",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / orders / items / properties / trigger_price
      Added value: +{
      +  "description": "Trigger threshold as a positive decimal string (> 0). Required for stop and take-profit orders (`stop_limit`, `stop_market`, `take_profit_limit`, `take_profit_market`): the order activates once the mark price crosses it — adversely for stops, favorably for take-profits. Must be omitted for other order types.",
      +  "type": "string"
      +}
    • changedInput schema / properties / orders / items / properties / type / description
      Previous value: -"Order type."New value: +"Order type. `limit` and `market` are unconditional. `stop_limit` / `stop_market` fire when the mark price crosses `trigger_price` in the adverse direction (stop-loss); `take_profit_limit` / `take_profit_market` fire on the favorable direction. `trailing_stop` fires a market order once the mark retraces from its best-seen extreme by `trailing_offset_bps`; `trailing_limit` fires the same way but rests a limit order priced off the fire price by `limit_offset_bps`. Field requirements: limit-family (`limit`, `stop_limit`, `take_profit_limit`) require `price`; stop / take-profit types require `trigger_price`; trailing types require `trailing_offset_bps`."
    • changedInput schema / properties / orders / items / properties / type / enum
      Previous value: -[
      -  "limit",
      -  "market"
      -]New value: +[
      +  "limit",
      +  "market",
      +  "stop_limit",
      +  "stop_market",
      +  "take_profit_limit",
      +  "take_profit_market",
      +  "trailing_stop",
      +  "trailing_limit"
      +]
  3. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does disclose two critical traits: 'Requires API credentials' (auth prerequisite) and 'This submits REAL orders to the matching engine' (real-money mutation, not a preview). It stops short of batch-specific behavior such as atomicity or what happens if one order in the batch is rejected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the deprecation warning so the agent sees the most decision-relevant fact first. The field-shape sentence is partly redundant with the schema, but the rest earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers auth, real-order impact, and item shape, but for a batch mutation tool with no annotations and no output schema it omits partial-failure semantics (all-or-nothing vs per-order rejection), the 1–100 limit's consequence, and no indication of the return payload.

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?

Schema description coverage is 100% and the nested `orders` schema already documents every field, including type-dependent requirements. The description's field recap ('market_id, side, type, size, and the type-dependent price / trigger_price / trailing offsets...') restates the schema rather than adding format or constraint meaning. 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?

States a specific verb and resource ('Submit multiple orders in one request') and distinguishes itself from both `create_order` (singular) and its named replacement `create_orders`. The deprecation prefix immediately classifies the tool's standing among siblings.

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?

Explicitly routes the agent away from this tool ('Deprecated: use `create_orders`'), naming the alternative. That covers both the when-not and the alternative-selection guidance in one clause, leaving nothing to infer.

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