Skip to main content
Glama
GemachDAO

GDEX Trading

by GemachDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hl_cancel_outcome_order

Destructive

Cancel a resting HIP-4 outcome order on Hyperliquid by order ID; any partial fills remain in your position.

Instructions

Cancel a resting HIP-4 outcome order. Structured mode: apiKey, walletAddress (control), sessionPrivateKey, outcomeId, coin (must belong to outcomeId), orderId (numeric Hyperliquid oid from hl_create_outcome_order or hl_outcome_account openOrders). Partial fills before the cancel stay in the position. Pre-built mode: computedData alone.

Input Schema

NameRequiredDescriptionDefault
coinNoSide coin "#<assetId>" of the order
apiKeyNoStructured mode: API key
orderIdNoNumeric Hyperliquid oid
outcomeIdNo
accountRefNoConnected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
computedDataNoPre-built mode ONLY: encrypted payload. Must be sent alone (no structured fields).
walletAddressNoStructured mode: CONTROL wallet address from sign-in (not the managed address)
sessionPrivateKeyNoStructured mode: session private key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv5.1.0
    • addedInput schema / properties / apiKey / description
      Added value: +"Structured mode: API key"
    • addedInput schema / properties / coin / description
      Added value: +"Side coin \"#<assetId>\" of the order"
    • addedInput schema / properties / computedData / description
      Added value: +"Pre-built mode ONLY: encrypted payload. Must be sent alone (no structured fields)."
    • removedInput schema / properties / dex
      Removed value: -{
-  "type": "string"
-}
    • addedInput schema / properties / orderId / description
      Added value: +"Numeric Hyperliquid oid"
    • addedInput schema / properties / sessionPrivateKey / description
      Added value: +"Structured mode: session private key"
    • addedInput schema / properties / walletAddress / description
      Added value: +"Structured mode: CONTROL wallet address from sign-in (not the managed address)"
  2. Changed1 schema field 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"
+}
  3. First observedv4.11.3

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, so safety is partly covered. The description adds real behavioral context beyond annotations: partial fills before the cancel remain in the position, and it enumerates the auth inputs (apiKey, sessionPrivateKey, control walletAddress) required in structured mode. It does not describe the response or failure modes.

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?

Front-loaded with the purpose, then mode-specific requirements and the partial-fill caveat. Dense but every sentence carries information. Slightly run-on, but no filler.

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 an 8-parameter, 0-required mutation tool with no output schema, the description covers mode selection, credential requirements, parameter provenance, and post-cancel state. It lacks any note on error conditions or confirmation behavior, which keeps it short of a 5.

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 88%, so the baseline is 3, but the description adds meaning the schema lacks: coin 'must belong to outcomeId', orderId's origin and numeric-oid nature, walletAddress as the control wallet, and the mutual exclusivity of computedData vs. structured fields. That is meaningful guidance beyond the schema text.

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: 'Cancel a resting HIP-4 outcome order.' That is far more precise than the bare name. However, it never contrasts itself with the closely-named sibling hl_close_outcome_order, so an agent must infer that 'cancel' (resting order) differs from 'close' (position).

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

Usage Guidelines3/5

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

The description explains the two invocation modes (structured vs. pre-built with computedData alone) and where orderId comes from (hl_create_outcome_order or hl_outcome_account openOrders), which is genuinely useful routing. But there is no explicit when-to-use-this-vs-alternative guidance, especially against hl_close_outcome_order and the generic cancel/update order tools.

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