Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sweep_brackets

Destructive

Tidies live protective orders for one coin after fills or closes: cancels stranded stops/targets when flat and merges duplicate stops or targets into a single pair when a position is open.

Instructions

LIVE MONEY: acts on the real account. Tidy one coin's protective orders (one coin per call). On a flat coin it cancels stops and targets left behind after a stop or target fired (a resting entry's own attached stop and target are kept) and lists resting entries. With an open position it checks the stop covers the full size and folds several stops or targets at one price (one per fill) into a single pair, placing the new order before cancelling the old ones. Never opens, closes or moves a level. Run it after every close or fill; to move a level use set_stop or set_target. Needs a trading key. Returns {ok, position, stop_px[], tp_px[], stop_covers} with an open position, or {ok, position: 0, cancelled_stranded, resting_entries[]: {oid, px, sz}} when flat; ok=false with reason "POSITION NOT FULLY COVERED BY A STOP" means place one now with set_stop.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "coin": "<coin>"
    },
    "name": "sweep_brackets"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesCoin: a main-dex perp by name (BTC, ETH) or a HIP-3 perp as dex:SYMBOL (xyz:GOLD, xyz:BRENTOIL). One coin per call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the destructiveHint annotation: it warns this is LIVE MONEY on the real account, specifies exactly what gets cancelled versus kept (a resting entry's own attached stop and target are kept), and states the safe ordering ('placing the new order before cancelling the old ones'). It also documents the auth requirement ('Needs a trading key') and decodes the ok=false reason, which the annotation alone cannot convey.

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?

Front-loads the critical LIVE MONEY warning and the one-line purpose, then layers mode-specific behavior, constraints, and return shapes in a logical order. It is dense and slightly run-on in places, but nearly every clause carries operational meaning.

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

Completeness5/5

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

Although no output schema exists, the description supplies both return shapes ({ok, position, stop_px[], tp_px[], stop_covers} and the flat-case variant with resting_entries) plus the failure semantics. For a single-parameter destructive tool, an agent has everything needed to call and interpret it correctly.

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 coverage is 100% and the coin parameter already documents main-dex vs. HIP-3 formats, so the description adds little new syntax. The 'one coin per call' emphasis reinforces the schema but is largely a restatement, so baseline 3 applies.

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: 'Tidy one coin's protective orders (one coin per call)', and clarifies scope to a single coin. It is clearly distinguishable from set_stop/set_target/place_bracket by the explicit 'Never opens, closes or moves a level' boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Run it after every close or fill') and names the correct alternative for a different need ('to move a level use set_stop or set_target'). It also defines the two operating modes (flat coin vs. open position), so the agent knows when each behavior applies.

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