Skip to main content
Glama
GemachDAO

GDEX Trading

by GemachDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

hl_close_outcome_order

Destructive

Exit a HIP-4 outcome position by selling held side tokens. Specify outcome, side, and limit or market order for full or partial exits.

Instructions

Exit a HIP-4 outcome position by SELLING held side tokens (the backend always sells; it cannot short). Structured mode: apiKey, walletAddress (control), sessionPrivateKey, outcomeId, one of coin/sideIndex/sideLabel, price (limit) or isMarket=true, optional size (whole contracts; omit for a full exit — the backend caps size to what you hold). With managedAddress, partial exits must leave both the sold part and the remainder >= 11 quote. Settled markets have no book: GDEX has no claim endpoint, check the HL spot balance instead. Pre-built mode: computedData alone.

Input Schema

NameRequiredDescriptionDefault
coinNoSide coin "#<assetId>" from hl_outcomes sides[].coin. Give exactly one of coin / sideIndex / sideLabel.
sizeNoContracts to sell; omit for the full position
priceNoLimit price (omit for isMarket)
apiKeyNoStructured mode: API key
isMarketNo
outcomeIdNo
sideIndexNoSide index in sides[] (sides are NOT always Yes/No; read the labels)
sideLabelNoExact side label from sides[].label, e.g. "No" or a team name
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)
managedAddressNoManaged wallet; enables position-aware partial-exit checks
sessionPrivateKeyNoStructured mode: session private key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 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>\" from hl_outcomes sides[].coin. Give exactly one of coin / sideIndex / sideLabel."
    • 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 / managedAddress
      Added value: +{
+  "description": "Managed wallet; enables position-aware partial-exit checks",
+  "type": "string"
+}
    • addedInput schema / properties / price / description
      Added value: +"Limit price (omit for isMarket)"
    • addedInput schema / properties / sessionPrivateKey / description
      Added value: +"Structured mode: session private key"
    • addedInput schema / properties / sideIndex
      Added value: +{
+  "description": "Side index in sides[] (sides are NOT always Yes/No; read the labels)",
+  "type": "integer"
+}
    • addedInput schema / properties / sideLabel
      Added value: +{
+  "description": "Exact side label from sides[].label, e.g. \"No\" or a team name",
+  "type": "string"
+}
    • addedInput schema / properties / size / description
      Added value: +"Contracts to sell; omit for the full position"
    • 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

A4.3/5.0
Behavior5/5

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

Beyond the destructive/openWorld annotations, it discloses important behavior: the backend always sells and cannot short, size is capped to the held position, omitting size exits fully, managedAddress partial exits must leave both parts >= 11 quote, and settled markets have no book. These are material operational constraints not present in the annotations.

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?

The description front-loads the action and constraint, then moves into structured-mode and pre-built-mode requirements. Despite covering many constraints for a 13-parameter tool, every clause carries operational meaning and there is no obvious 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 a destructive 13-parameter tool with no output schema, the description covers mode selection, required field combinations, partial-exit limits, and the settled-market caveat. It leaves some gaps around accountRef-based credential flow and error/return behavior, but annotations and schema cover part of that ground.

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 high at 85%, so the baseline is 3, but the description adds useful semantics: size is in whole contracts, omit size for a full exit, the backend caps size, and exactly one of coin/sideIndex/sideLabel is needed. It also groups structured vs pre-built mode parameters. It does not mention every schema field, such as accountRef, so it is strong but not exhaustive.

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?

It states a specific verb and resource: 'Exit a HIP-4 outcome position by SELLING held side tokens.' It also clarifies the critical sell-only constraint, which separates it from opening or shorting. It does not explicitly name sibling alternatives, so it falls just short of the highest clarity tier.

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?

The description gives clear operational context: use structured mode with the listed fields, or pre-built mode with computedData alone. It also explains the settled-market case ('GDEX has no claim endpoint, check the HL spot balance instead'), which is a useful when-not alternative. It does not explicitly route against hl_create_outcome_order or hl_cancel_outcome_order, so 4 rather than 5.

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