Skip to main content
Glama
longbridge

longbridge

Official
by longbridge
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Rust
Hybrid

Cancel Order

cancel_order
DestructiveIdempotent

Cancel an open order by its order ID after a two-step confirmation dry run. Also cancels attached take-profit/stop-loss legs when targeting the parent order.

Instructions

Cancel an open order by order_id. Returns plain text "order cancelled" on success; errors if the order is already filled or cancelled. 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 also echoes the order being targeted so the user can verify it is the right one. Set is_attached=true to cancel a single take-profit/stop-loss leg by its own order_id; cancelling a parent order cancels its legs along with it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_jqNoOptional 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.
executeNoThe `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_idYesOrder ID to cancel (from today's orders or order history)
is_attachedNoSet to true to cancel an attached take-profit / stop-loss leg by its own order_id, leaving the parent order in place. Omit (or false) to cancel a parent order, which cancels its attached legs with it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • 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."
  2. Changed2 schema fields changedv0.10.6
    • addedInput schema / properties / _jq
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / is_attached
      Added value: +{
+  "description": "Set to true to cancel an attached take-profit / stop-loss leg by its own\norder_id, leaving the parent order in place. Omit (or false) to cancel a\nparent order, which cancels its attached legs with it.",
+  "type": "boolean"
+}
  3. Changed2 schema fields changedv0.10.2
    • 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"
+}
    • changedInput schema / properties / order_id / description
      Previous value: -"Order ID (from today's orders or order history)"New value: +"Order ID to cancel (from today's orders or order history)"
  4. Changed1 schema field changedv0.8.7
    • changedInput schema / properties / order_id / description
      Previous value: -"Order ID (returned by submit_order or listed in today_orders / history_orders)"New value: +"Order ID (from today's orders or order history)"
  5. Changed1 schema field changedv0.7.1
    • removedInput schema / title
      Removed value: -"OrderIdParam"
  6. Addedv0.4.5
  7. Removedv0.4.0
  8. Addedv0.3.2
  9. Removedv0.3.1
  10. First observedv0.1.12

TDQS

A3.6/5.0
Behavior1/5

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

The description discloses rich behavior: plain-text success response, errors on already-filled/cancelled orders, single-use 10-minute confirmation code, dry-run preview echo, and attached-leg semantics. However, this contradicts the idempotentHint=true annotation: the code is single-use and cancelling an already-cancelled order errors, so repeated identical calls do not succeed. Per rubric, a contradiction forces a score of 1.

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?

Core purpose, success/error behavior, and the safety-critical confirmation protocol are front-loaded and clearly flagged. The description is longer than strictly necessary because it partially restates the confirmation details already present on the execute parameter, but the redundancy is acceptable for a destructive tool and nothing is ambiguous or wasted.

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 destructive, two-step tool with no output schema, the description is complete: it states the return value, failure modes, confirmation-code constraints, dry-run behavior, and parent/attached-leg semantics. An agent has everything needed to call the tool correctly.

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 schema already documents execute, order_id, is_attached, and _jq in detail, including the two-step confirmation protocol. The description reinforces the confirmation flow but adds little new parameter-level meaning beyond the schema, so the baseline score of 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: 'Cancel an open order by order_id.' It also distinguishes cancelling a parent order from cancelling an attached take-profit/stop-loss leg via is_attached=true, so an agent can tell exactly what the tool does and how it differs from related order tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit, mandatory usage protocol: call as a dry run first, show the preview, then call again with the confirmation code only after explicit user confirmation, and never quote the code back in the same turn. It also clarifies when to use is_attached=true vs cancelling a parent order. It does not name sibling alternatives (e.g., grid_cancel), so it misses the upper bound.

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