Skip to main content
Glama
GemachDAO

GDEX Trading

by GemachDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

close_perp_position

Destructive

Closes a Hyperliquid perpetual position fully or partially with a reduce-only market order, reading the side from the live position; rejects flat, oversized, or ambiguous builder-DEX positions.

Instructions

Close (fully or partially) one perp position with a reduce-only market order. The side is read from the live HL position: a long is closed with a sell, a short with a buy. Rejects when the position is flat/missing, when size exceeds it, or when a bare coin is open on several builder DEXes.

Input Schema

NameRequiredDescriptionDefault
dexNoBuilder DEX for a bare coin, e.g. 'xyz' (omit for the default dex)
coinYesAsset symbol to close; builder-DEX assets as 'dex:ASSET', e.g. 'xyz:TSLA'
sizeNoSize to close as a decimal string; omit to close the whole position
priceNoClose price; omit or '0' to use the mark price
apiKeyNoGDEX API key for AES encryption
accountRefNoConnected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
szDecimalsNoMarket size decimals (HL meta szDecimals); rejects a size with more decimals
walletAddressNoControl wallet address
positionAddressNoAddress whose HL account holds the position — normally the MANAGED wallet from sign-in. Defaults to walletAddress.
sessionPrivateKeyNoSession private key from sign-in

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 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 / properties / coin / description
      Previous value: -"Asset symbol to close"New value: +"Asset symbol to close; builder-DEX assets as 'dex:ASSET', e.g. 'xyz:TSLA'"
    • addedInput schema / properties / dex
      Added value: +{
+  "description": "Builder DEX for a bare coin, e.g. 'xyz' (omit for the default dex)",
+  "type": "string"
+}
    • addedInput schema / properties / positionAddress
      Added value: +{
+  "description": "Address whose HL account holds the position — normally the MANAGED wallet from sign-in. Defaults to walletAddress.",
+  "type": "string"
+}
    • changedInput schema / properties / price / description
      Previous value: -"Price for the close order"New value: +"Close price; omit or '0' to use the mark price"
    • changedInput schema / properties / size / description
      Previous value: -"Size to close (use full position size for 100% close)"New value: +"Size to close as a decimal string; omit to close the whole position"
    • addedInput schema / properties / szDecimals
      Added value: +{
+  "description": "Market size decimals (HL meta szDecimals); rejects a size with more decimals",
+  "type": "number"
+}
    • changedInput schema / required
      Previous value: -[
-  "apiKey",
-  "walletAddress",
-  "sessionPrivateKey",
-  "coin",
-  "size",
-  "price"
-]New value: +[
+  "coin"
+]
  2. First observedv4.11.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructive=true and openWorld=true, but the description adds real substance: the order type (reduce-only market), that the side is derived from the live HL position rather than supplied, and the three rejection cases. It omits auth/session prerequisites, though the schema's accountRef/apiKey fields cover that.

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 tight sentences, front-loaded with what the tool does, then the side-derivation rule, then failure conditions. Nothing is padded or redundant.

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, 10-parameter mutation tool with no output schema, the description covers the operation, the side logic, and the failure modes; the remaining gaps (fill/return details, session requirements) are largely carried by the annotations and the 100%-covered schema.

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%, so the baseline is 3. The description does clarify a genuinely tricky parameter interaction (a bare coin open on several builder DEXes is rejected, and a partial size must not exceed the live position), which is marginally useful but not syntax-level guidance beyond the schema.

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 ('Close ... one perp position') plus the exact mechanism ('reduce-only market order'), which cleanly separates it from open_perp_position and close_all_positions in the sibling list.

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 concrete rejection conditions (flat/missing position, size exceeding it, bare coin across multiple builder DEXes) that tell the agent when this call will fail, and 'fully or partially' scopes it to a single position. It never names an explicit alternative such as close_all_positions, so it falls short of a 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