Skip to main content
Glama

close_perp_position

Destructive

Close a perp position (full/partial) on its venue (non-custodial).

position_id is venue-native (for Drift it is the market symbol). close_pct in (0, 100]. Returns an UNSIGNED tx / signing payload to sign + broadcast.

jurisdiction: closes are geo-gated too -- see place_perp_order.

idempotency_key (optional): a client-generated UUID. Retrying with the same key + same args replays the original result instead of re-closing the position. Reuse the SAME key across the build call and its signed_transaction completion call -- see place_perp_order; the two legs dedupe independently, so this never raises IDEMPOTENCY_CONFLICT.

signed_transaction / verify (two-phase execution): see place_perp_order -- re-call with the signed payload and Crank relays it by custody tier and verifies the result.

venue_action (optional, completion leg only): see place_perp_order -- pass back the build leg's extra['venue_action'] (e.g. Jupiter's decrease-position) so the relay route is the venue's own declared one instead of one inferred from the signed bytes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipNo
venueNo
verifyNo
caller_idNo
close_pctNo
position_idYes
jurisdictionNo
pay_in_crankNo
venue_actionNo
payment_headerNo
wallet_addressYes
idempotency_keyNo
acknowledge_tier_bNo
signed_transactionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / venue_action
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / ip
      Added value: +{
      +  "default": "",
      +  "type": "string"
      +}
    • addedInput schema / properties / jurisdiction
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / signed_transaction
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • addedInput schema / properties / verify
      Added value: +{
      +  "default": true,
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The description discloses behavior well beyond the annotations: it returns an unsigned transaction/signing payload, explains idempotency replay semantics, describes two-phase execution, and notes jurisdictional gating. This gives an agent a clear model of the side effects and execution pattern without contradicting the `destructiveHint: true` annotation.

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?

The description is well-structured: it front-loads the core purpose, then explains related parameter semantics in thematic blocks. It is somewhat long, but the length is justified for a 14-parameter tool, and repeated references to `place_perp_order` avoid duplicating shared behavior.

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?

Given the complexity, the description covers the most security-critical and flow-specific aspects well, and an output schema exists so return details are not required. It loses a point for leaving important parameters like `wallet_address, pay_in_crank, and acknowledge_tier_b mostly undescribed.

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?

With 0% schema description coverage, the description compensates well by explaining `position_id`, `close_pct`, `jurisdiction`, `idempotency_key`, `signed_transaction`, `verify`, and `venue_action`. Some parameters remain undocumented, notably the required `wallet_address` and the risk-related `acknowledge_tier_b`.

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?

The description clearly states the operation: 'Close a perp position (full/partial) on its venue (non-custodial).' This is specific and actionable. However, it does not explicitly differentiate itself from the sibling tool `perp_close`, which appears to have a similar close-purpose.

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 provides clear context: it explains the non-custodial nature, geo-gating, idempotency behavior, and the two-phase signed-transaction flow. It does not articulate exclusions or when to prefer this tool over alternatives like `perp_close` or `cancel_perp_order`, but the usage context is otherwise strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources