Skip to main content
Glama

update_order

Destructive

Modify an existing limit order's amount, trigger price, take-profit and stop-loss together, or cancel it by setting the delete flag.

Instructions

Update or delete an existing limit order. Set isDelete=true to cancel (no other fields needed). An update replaces amount, triggerPrice and TP/SL together, so all four are required.

Input Schema

NameRequiredDescriptionDefault
amountNoNew amount in raw units (required unless isDelete)
apiKeyNoAPI key for AES encryption
userIdNoControl wallet address
chainIdYesNumeric chain ID
orderIdYes64-char hex order ID from get_limit_orders
isDeleteNoSet true to cancel the order
accountRefNoConnected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
lossPercentNoNew SL %, whole number under 100, '0' = none (required unless isDelete)
triggerPriceNoNew trigger price in USD (required unless isDelete)
profitPercentNoNew TP %, whole number, '0' = none; buy orders only, sell orders ignore it (required unless isDelete)
sessionPrivateKeyNoSession private key from sign-in

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv5.1.0
    • changedInput schema / properties / amount / description
      Previous value: -"New amount in raw units"New value: +"New amount in raw units (required unless isDelete)"
    • changedInput schema / properties / lossPercent / description
      Previous value: -"New SL % (buy orders only)"New value: +"New SL %, whole number under 100, '0' = none (required unless isDelete)"
    • changedInput schema / properties / profitPercent / description
      Previous value: -"New TP % (buy orders only)"New value: +"New TP %, whole number, '0' = none; buy orders only, sell orders ignore it (required unless isDelete)"
    • changedInput schema / properties / triggerPrice / description
      Previous value: -"New trigger price in USD"New value: +"New trigger price in USD (required unless isDelete)"
  2. Changed2 schema fields changedv4.12.0
    • addedInput schema / properties / accountRef
      Added value: +{
      +  "description": "Connected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "apiKey",
      -  "userId",
      -  "sessionPrivateKey",
      -  "chainId",
      -  "orderId"
      -]New value: +[
      +  "chainId",
      +  "orderId"
      +]
  3. First observedv4.11.3

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true. The description adds genuinely non-obvious behavior beyond that: an update atomically replaces amount, triggerPrice and both TP/SL values rather than patching individual fields, and the delete path needs no payload. It doesn't address reversibility or confirmation requirements, keeping it short of a 5.

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?

Three short sentences, front-loaded with the action, then the cancel branch, then the update requirement. No filler and no repetition of schema text.

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

Completeness4/5

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

For a destructive, 11-parameter mutation with no output schema, it covers both modes and the coupling of update fields. It leaves the credential path (accountRef vs apiKey vs sessionPrivateKey vs userId) to the schema and says nothing about what a successful update returns, but those are secondary.

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 coverage is 100%, so the baseline is 3, but the description adds a cross-field rule the schema only states per-parameter: the four update fields must travel together, and isDelete short-circuits them. That is real value above the per-property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update or delete an existing limit order'), which separates it from creation siblings limit_buy/limit_sell. It does not explicitly name or contrast with direct_cancel_order, so sibling differentiation is implied rather than stated.

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?

Gives clear conditional guidance: isDelete=true cancels with no other fields, while an update requires all four of amount, triggerPrice and TP/SL. No explicit 'when not to use' or alternate-tool routing, but the mode selection is unambiguous.

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