longbridge

Official

by longbridge

Overview Schema Source Related Servers Discussions(1)Admin

Rust

Hybrid

Replace Order

replace_order

DestructiveIdempotent

Modify an open order's quantity, price, trigger price, or trailing parameters, including attached take-profit/stop-loss legs. Requires a two-step dry-run confirmation before changes are sent to the exchange.

Instructions

Modify an open order's quantity, price, trigger_price, or trailing params. Returns "order replaced" on success. Only open/pending orders can be modified. TWO-STEP CONFIRMATION IS MANDATORY: this tool is a DRY RUN unless you pass the confirmation_code its own dry run returned. Call it first without execute, show the returned preview to the user, and only call it again with execute="" after the user has explicitly confirmed that exact order. The code is derived from the order itself, so it applies only to that exact order. Never quote it back on your own initiative, and never in the same turn the user first asks. The dry run echoes the current order alongside the requested change. Attached take-profit/stop-loss legs are changed here too: attached_order_type with the new attached_profit_taker_price / attached_stop_loss_price adds or reprices a leg, attached_profit_taker_id / attached_stop_loss_id target an existing leg, and attached_cancel_all=true removes every leg while leaving the order in place.

Input Schema

TableJSON Schema

Name	Required	Description
`_jq`	No	Optional jq filter (jaq syntax) applied to this tool's JSON response before it is returned; it never changes the upstream request. One output is returned as-is, several as a JSON array, none as []. Module imports and the `env`/`debug`/`stderr` builtins are unavailable. Example: .data \| map({symbol}). Omit for the full response.
`price`	No	New limit price (for limit-style orders)
`execute`	No	The `confirmation_code` from this order's dry run. WITHOUT IT NOTHING IS SENT. Omitted (the default) makes this a DRY RUN: the request is validated and echoed back with a three-digit `confirmation_code`, and nothing reaches the exchange. Required protocol: call once without `execute`, show the returned preview to the user, and call again quoting the code only after the user has explicitly confirmed that exact order. The code is single use, expires in 10 minutes, and applies only to this exact order — change any field and it stops working. Never quote it back on your own initiative, and never in the same turn the user first asks.
`order_id`	Yes	Order ID to replace (returned by submit_order or listed in today_orders / history_orders)
`quantity`	Yes	New order quantity (number of shares)
`limit_offset`	No	New limit offset from the trailing stop price (for TSLPAMT / TSLPPCT)
`trigger_price`	No	New trigger (activation) price (for LIT / MIT / trailing-stop orders)
`trailing_amount`	No	New trailing amount as absolute price distance (for TSLPAMT)
`attached_main_id`	No	ID of the parent order that owns the attached leg, when the leg is modified on its own rather than through its parent.
`trailing_percent`	No	New trailing percent as decimal e.g. 0.05 = 5% (for TSLPPCT)
`attached_quantity`	No	New quantity for the attached leg.
`attached_cancel_all`	No	Set to true to cancel every attached take-profit / stop-loss leg of this order, leaving the order itself in place.
`attached_order_type`	No	Attached leg to add or update: "PROFIT_TAKER", "STOP_LOSS" or "BRACKET". Required unless the only attached change is attached_cancel_all.
`attached_expire_time`	No	New expiry for the attached leg as a unix timestamp in seconds. Required when attached_time_in_force is GTD.
`attached_outside_rth`	No	New outside-RTH setting for the triggered leg: "RTH_ONLY" / "ANY_TIME" / "OVERNIGHT" / "OPTION_PRE_MARKET".
`attached_market_price`	No	Reference market price for the attached leg.
`attached_stop_loss_id`	No	ID of the existing stop-loss leg to update (from order_detail's attached_orders[]). Omit to add a new leg.
`attached_time_in_force`	No	New time-in-force for the attached leg: "Day" / "GTC" / "GTD".
`attached_profit_taker_id`	No	ID of the existing take-profit leg to update (from order_detail's attached_orders[]). Omit to add a new leg.
`attached_stop_loss_price`	No	New stop-loss trigger price.
`attached_profit_taker_price`	No	New take-profit trigger price.
`attached_activate_order_type`	No	New order type for the triggered leg, e.g. "LO" or "MO".
`attached_stop_loss_submit_price`	No	New limit price for the stop-loss leg.
`attached_profit_taker_submit_price`	No	New limit price for the take-profit leg.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.12.0Sep 23, 2026

addedInput schema / properties / _jq / description

Added value: +"Optional jq filter (jaq syntax) applied to this tool's JSON response before it is returned; it never changes the upstream request. One output is returned as-is, several as a JSON array, none as []. Module imports and the `env`/`debug`/`stderr` builtins are unavailable. Example: .data | map({symbol}). Omit for the full response."

changedInput schema / properties / attached_outside_rth / description

Previous value: -"New outside-RTH setting for the triggered leg: \"RTH_ONLY\" / \"ANY_TIME\"\n/ \"OVERNIGHT\"."New value: +"New outside-RTH setting for the triggered leg: \"RTH_ONLY\" / \"ANY_TIME\"\n/ \"OVERNIGHT\" / \"OPTION_PRE_MARKET\"."

Changed16 schema fields changedv0.10.6Sep 10, 2026

addedInput schema / properties / _jq
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / attached_activate_order_type

Added value: +{
+  "description": "New order type for the triggered leg, e.g. \"LO\" or \"MO\".",
+  "type": "string"
+}

addedInput schema / properties / attached_cancel_all

Added value: +{
+  "description": "Set to true to cancel every attached take-profit / stop-loss leg of this\norder, leaving the order itself in place.",
+  "type": "boolean"
+}

addedInput schema / properties / attached_expire_time

Added value: +{
+  "description": "New expiry for the attached leg as a unix timestamp in seconds.\nRequired when attached_time_in_force is GTD.",
+  "type": "string"
+}

addedInput schema / properties / attached_main_id

Added value: +{
+  "description": "ID of the parent order that owns the attached leg, when the leg is\nmodified on its own rather than through its parent.",
+  "type": "string"
+}

addedInput schema / properties / attached_market_price

Added value: +{
+  "description": "Reference market price for the attached leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_order_type

Added value: +{
+  "description": "Attached leg to add or update: \"PROFIT_TAKER\", \"STOP_LOSS\" or \"BRACKET\".\nRequired unless the only attached change is attached_cancel_all.",
+  "type": "string"
+}

addedInput schema / properties / attached_outside_rth

Added value: +{
+  "description": "New outside-RTH setting for the triggered leg: \"RTH_ONLY\" / \"ANY_TIME\"\n/ \"OVERNIGHT\".",
+  "type": "string"
+}

addedInput schema / properties / attached_profit_taker_id

Added value: +{
+  "description": "ID of the existing take-profit leg to update (from\norder_detail's attached_orders[]). Omit to add a new leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_profit_taker_price

Added value: +{
+  "description": "New take-profit trigger price.",
+  "type": "string"
+}

addedInput schema / properties / attached_profit_taker_submit_price

Added value: +{
+  "description": "New limit price for the take-profit leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_quantity

Added value: +{
+  "description": "New quantity for the attached leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_stop_loss_id

Added value: +{
+  "description": "ID of the existing stop-loss leg to update (from order_detail's\nattached_orders[]). Omit to add a new leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_stop_loss_price

Added value: +{
+  "description": "New stop-loss trigger price.",
+  "type": "string"
+}

addedInput schema / properties / attached_stop_loss_submit_price

Added value: +{
+  "description": "New limit price for the stop-loss leg.",
+  "type": "string"
+}

addedInput schema / properties / attached_time_in_force

Added value: +{
+  "description": "New time-in-force for the attached leg: \"Day\" / \"GTC\" / \"GTD\".",
+  "type": "string"
+}

Changed1 schema field changedv0.10.2Aug 29, 2026

addedInput schema / properties / execute

Added value: +{
+  "description": "The `confirmation_code` from this order's dry run. WITHOUT IT NOTHING IS\nSENT.\n\nOmitted (the default) makes this a DRY RUN: the request is validated and\nechoed back with a three-digit `confirmation_code`, and nothing reaches\nthe exchange.\n\nRequired protocol: call once without `execute`, show the returned\npreview to the user, and call again quoting the code only after the user\nhas explicitly confirmed that exact order. The code is single use,\nexpires in 10 minutes, and applies only to this exact order — change any\nfield and it stops working. Never quote it back on your own initiative,\nand never in the same turn the user first asks.",
+  "type": "string"
+}

Changed1 schema field changedv0.7.1Jun 26, 2026
- removedInput schema / title
```
Removed value: -"ReplaceOrderParam"
```
Addedv0.4.5May 28, 2026
Removedv0.4.0May 21, 2026
Addedv0.3.2May 19, 2026
Removedv0.3.1May 15, 2026
First observedv0.1.12May 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses critical behavioral traits beyond annotations: the dry-run vs. execute behavior, the confirmation_code mechanism, single-use code with 10-minute expiry, and the fact that attached take-profit/stop-loss legs are modified here too. It also explains the effect of attached_cancel_all. The annotations say destructiveHint=true and idempotentHint=true, and the description's emphasis on confirmation aligns with the destructive nature. No contradiction.

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?

The description is dense but well-structured, front-loading the core purpose and the critical confirmation protocol. The attached-leg explanation is a bit long but necessary given the complexity. Every sentence earns its place; no filler. Slightly long, but justified by the tool's complexity.

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 complex mutation tool with 24 parameters, no output schema, and destructive annotations, the description covers the essential context: what can be modified, the mandatory confirmation flow, the attached-leg behavior, and the success return string. The schema covers parameter details, and the description covers the protocol. Nothing critical is missing for an agent to call this tool correctly.

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?

Schema description coverage is 100%, so the schema already documents all 24 parameters. The description adds value by explaining the high-level grouping: quantity, price, trigger_price, trailing params, and the attached-leg semantics (attached_order_type with new prices adds/reprices, attached_profit_taker_id/attached_stop_loss_id target existing legs, attached_cancel_all removes all legs). This goes beyond the schema's per-parameter descriptions, though it doesn't detail every parameter.

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: 'Modify an open order's quantity, price, trigger_price, or trailing params.' It clearly distinguishes this from sibling tools like submit_order, cancel_order, and grid_replace by focusing on modifying existing open orders. The scope is explicit: only open/pending orders can be modified.

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 explicit when-to-use guidance: 'Only open/pending orders can be modified.' It also gives a mandatory two-step confirmation protocol with clear instructions on when to call the tool first (dry run), what to show the user, and when to call again with execute. It even states what not to do: 'Never quote it back on your own initiative, and never in the same turn the user first asks.' This is exemplary usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Replace Order

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools