Skip to main content
Glama
agasavenue17

dreamDEX Perps MCP

by agasavenue17

close_position

Closes the server wallet's entire open position in a specified perpetual market by submitting an opposite-side IOC market order sized exactly to that position.

Instructions

Close the server wallet's entire position in one market with an opposite-side IOC market order sized exactly to the open position.

Input Schema

NameRequiredDescriptionDefault
symbolYesBase symbol, e.g. BTC

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations at all, the description still discloses the meaningful mechanics: it is a market order (so price impact/slippage applies), it is IOC (won't rest on the book), it hits the server wallet specifically, and the size is derived rather than supplied. It does not state required permissions, what happens if the position is zero, or how a residual after partial IOC fill is handled.

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?

One front-loaded sentence that states scope, mechanism, order type, time-in-force, and sizing rule with zero padding. Nothing to trim and nothing reordered.

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

Completeness3/5

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

For a mutating trading tool with no annotations and no output schema, the description covers the mechanism well but omits failure/no-position behavior, permissions, and what the response contains (fill price/quantity, residual position after a partial IOC fill). Those gaps matter for an agent deciding whether to invoke it.

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?

Single parameter with 100% schema coverage, so the schema already explains symbol as the base symbol. The description only adds that the symbol identifies the single market whose position is closed, which is minimal but consistent; baseline 3 applies when the schema does the heavy lifting.

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?

A specific verb and resource ("Close ... entire position in one market") plus the exact mechanism: an opposite-side IOC market order sized to the open position. This distinguishes it from the generic place_order/cancel_order siblings without needing to open their schemas.

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?

Usage is implied by the name and description — you call it to flatten an existing position rather than to open or partially adjust one. There is no explicit when-to-use vs. place_order guidance and no stated preconditions (e.g. behavior when no position exists), so the agent must infer.

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