Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_stop

Destructive

Tighten an open perpetual position's stop-loss toward the mark to lock in gains or cut risk. Places the new stop first, then cancels older stops; never widens.

Instructions

LIVE MONEY: acts on the real account. Move an open position's stop-loss tighter, toward the mark, to lock in gains or cut risk; never wider. One stop for the whole position goes on first, then every older stop on the coin is cancelled, so the position is never unprotected and a refused new order leaves the old one in place. Refused: no open position, a stop past the mark (it would fire at once), or a stop wider than or equal to the current one (a long's new stop must be above it, a short's below). With no stop at all, any stop on the right side of the mark is placed. Never changes the target or the size. To widen a stop, close and re-enter with place_bracket; to move the target use set_target. Needs a trading key. Returns {ok, stop_px, size, mark, replaced: old stop prices}; a refusal is {ok: false, reason, mark, current_stop} with isError true and nothing sent.

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>",
      "stop_px": "<stop_px>"
    },
    "name": "set_stop"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesCoin: a main-dex perp by name (BTC, ETH) or a HIP-3 perp as dex:SYMBOL (xyz:GOLD, xyz:BRENTOIL).
stop_pxYesNew stop: above the current stop for a long, below it for a short, and on the safe side of the mark.

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?

Annotations supply only destructiveHint=true, so the description carries the rest and does so thoroughly: it warns that real money is at stake, discloses the ordering guarantee (new stop placed first, then older stops cancelled) and the safety property that a refused order leaves the old stop in place. It also documents both return shapes, including that a refusal returns isError true with 'nothing sent'.

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 critical warning — LIVE MONEY — is front-loaded, and the remaining clauses each carry a distinct constraint (ordering, refusal cases, scope limits, return shape) rather than filler. It is dense and long for a single paragraph, and a little of the stop-direction wording duplicates the schema, but no sentence is wasted.

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?

For a two-parameter mutation tool with no output schema, the description covers everything an agent needs: preconditions, failure modes, key requirement, ordering guarantees, side effects (older stops cancelled, target and size untouched), and the explicit response shapes for success and refusal.

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 schema's own descriptions already explain coin naming (main-dex vs dex:SYMBOL) and the directional stop constraint, so the description's restatement of 'a long's new stop must be above it, a short's below' adds little beyond the structured data. The only genuinely new parameter-level meaning is 'never wider', which is also covered under the refusal rules, so the baseline 3 is appropriate.

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?

The description opens with a specific verb and resource — 'Move an open position's stop-loss tighter, toward the mark' — and immediately scopes it with 'never wider'. It explicitly distinguishes itself from siblings by naming set_target for target changes and place_bracket for widening, so an agent can route correctly without opening other schemas.

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?

It states exactly when the tool applies (tighter stop on an open position) and when it does not, listing the three refusal conditions — no open position, stop past the mark, stop equal-or-wider than current — plus the special case of no existing stop. It also names the correct alternatives for the excluded operations (place_bracket to widen, set_target to retarget).

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