Skip to main content
Glama
Sign In

Moby

by win.moby
OverviewDiscussionsAdmin

Check my open positions and exits

check_positions
Read-only

THE first call of every scheduled run, before the scan: what each held position needs now under a strategy's exit rules. One call for position upkeep: for each held token, the live exit legs, age, PnL and the actions due (time-stop sell or sell-now, missing SL/TP, cancel the orphan leg) under the strategy's rules, plus today's counts (buys, stop-outs, open positions, closed-at-loss 7d) so you never recompute them. Do what actions says with quick_sell / create_order / cancel_order, then scan. Each action's params are the arguments for that tool; verdict is sell_now, fix_exits or hold. Nothing is placed or sold by this call. Pass the strategy you run; with no strategy and no rule it runs under the user's active strategy, else as a rules-free report (rules in the result says which).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_positions"
  }
}

Input Schema

NameRequiredDescriptionDefault
sl_pctNoOverride: stop loss this % below the average cost. Number > 0 and < 100 (30 = -30%).
tp_pctNoOverride: take profit this % above the average cost. Number > 0 (100 = 2x, 200 = 3x).
strategyNoStrategy preset id, exactly one of: smart_money_confirmed, early_launch_hunter, stonkfun_trend_rider, stonkfun_whale_swarm (lowercase, underscores). Omit to pass the rules yourself or to use the user's active strategy.
token_addressNoOne held token's Solana mint (base58 string, not a symbol or id); omit for all.
time_stop_hoursNoOverride: sell a position open this many hours. Number > 0, at most 720.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedInput schema / properties / sl_pct / title
      Removed value: -"Sl Pct"
    • removedInput schema / properties / strategy / title
      Removed value: -"Strategy"
    • removedInput schema / properties / time_stop_hours / title
      Removed value: -"Time Stop Hours"
    • removedInput schema / properties / token_address / title
      Removed value: -"Token Address"
    • removedInput schema / properties / tp_pct / title
      Removed value: -"Tp Pct"
    • removedInput schema / title
      Removed value: -"check_positionsArguments"
  2. Changed5 schema fields changed
    • changedInput schema / properties / sl_pct / description
      Previous value: -"Override: stop loss this % below the average cost."New value: +"Override: stop loss this % below the average cost. Number > 0 and < 100 (30 = -30%)."
    • changedInput schema / properties / strategy / description
      Previous value: -"Strategy preset (its id from list_strategies). Omit only to pass the rules yourself."New value: +"Strategy preset id, exactly one of: smart_money_confirmed, early_launch_hunter, stonkfun_trend_rider, stonkfun_whale_swarm (lowercase, underscores). Omit to pass the rules yourself or to use the user's active strategy."
    • changedInput schema / properties / time_stop_hours / description
      Previous value: -"Override: sell a position open this many hours."New value: +"Override: sell a position open this many hours. Number > 0, at most 720."
    • changedInput schema / properties / token_address / description
      Previous value: -"Check one held token (its mint) instead of all."New value: +"One held token's Solana mint (base58 string, not a symbol or id); omit for all."
    • changedInput schema / properties / tp_pct / description
      Previous value: -"Override: take profit this % above the average cost (100 = 2x)."New value: +"Override: take profit this % above the average cost. Number > 0 (100 = 2x, 200 = 3x)."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Nothing is placed or sold by this call' and goes further by explaining that the tool returns an `actions` list whose `params` are arguments for other mutating tools. It also discloses fallback behavior (explicit strategy → user's active strategy → rules-free report, with `rules` in the result signalling which), which is real behavioral context not present in the annotations.

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 most important instruction is front-loaded in the first clause, and the dense middle section (what the result contains) earns its space by pre-empting recomputation questions. It is long and somewhat run-on with parenthetical lists, but no sentence is filler.

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 5-parameter, zero-required, read-only planning call with an output schema, the description covers the call ordering, the decision outputs, the follow-up tool routing, and the default-strategy resolution. An agent could invoke and act on it correctly without opening anything else.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds interaction semantics the schema cannot express: how `strategy` relates to the sl_pct/tp_pct/time_stop_hours overrides and what happens when neither is supplied. That precedence rule meaningfully raises it above baseline, though the per-parameter numeric ranges are left entirely to the schema.

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 names a specific verb and resource — 'what each held position needs now under a strategy's exit rules' — and enumerates exactly what comes back (exit legs, age, PnL, actions due, today's counts). It is clearly separable from siblings like get_my_position or get_my_portfolio because it is explicitly the decision/upkeep call, not a raw lookup.

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 precisely when to call it ('THE first call of every scheduled run, before the scan') and what to do afterwards ('Do what `actions` says with quick_sell / create_order / cancel_order, then scan'), naming the alternative tools explicitly. The strategy-vs-override precedence is also spelled out, so nothing about when/how to invoke is left to inference.

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

All Moby toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources