Skip to main content
Glama
chand1012

Polymarket US MCP server

by chand1012

Close Position Order

close_position_order
Destructive

Creates an order to sell all contracts held in a specified market, closing an existing position and updating live account state.

Instructions

LIVE ACCOUNT ACTION: Create an order to close an existing position in a market. This will sell all contracts held in the specified market. This operation may affect real funds or account state.

Input Schema

NameRequiredDescriptionDefault
bodyYesRequest to create an order to close a position

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the risk profile is conveyed structurally. The description adds useful context beyond that: it is a live-account action that sells ALL contracts in the market, implying no partial close. It does not cover permissions, failure behavior, whether the resulting order can be canceled, or how slippage/maxBlockTime affect execution.

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 short sentences with the risk warning front-loaded via the 'LIVE ACCOUNT ACTION:' prefix, followed by the effect and the fund impact. Nothing is redundant or padded.

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?

This is a destructive live-trading mutation with a nested parameter object and no output schema, so the description carries weight. It explains the core effect but omits what the agent gets back (order id, status), what happens if the position is absent or execution fails, and how the synchronous path interacts with maxBlockTime.

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% for the single nested body object and its fields, so the schema already explains marketSlug, slippageTolerance, maxBlockTime, and synchronousExecution. The description adds no parameter-level meaning, so the baseline of 3 applies.

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 names a specific verb and resource ("Create an order to close an existing position in a market") and clarifies the effect: it sells all contracts in that market. That is enough to distinguish it from the sibling create_order for most agents, though it never explicitly contrasts the two.

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 phrase 'to close an existing position', which tells the agent the situation this tool is for. However, there is no explicit guidance on alternatives (create_order, preview_order for a dry run, or cancel/modify), no prerequisites such as having an open position, and no note on when not to use it.

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