Skip to main content
Glama

Trade Plan Check & Replay

research_trade_plan
Read-only

Check, review or replay a perp trade setup (entry, stop, optional target), before it is placed or after: the tool for 'check this setup', 'is this trade good' and 'how did my trade do'. Renders an interactive trade ticket. Give the coin, entry and stop; optionally target, leverage, order type, placed_at, and account size with risk percent. Returns reward:risk, the stop's distance in % and 4h ATR, the isolated liquidation price at the leverage (first-tier 0.5% maintenance margin, so the optimistic case), funding per day at the current rate (in % of notional, and in USD when sized), the perp levels around the setup (from flow_levels: volume nodes, value area, liquidation clusters, entries, walls), and named checks: liquidation before the stop, price already through the stop, a stop inside one ATR of noise, a stop just in front of a level a wick would reach for, a level between entry and target, reward:risk under 2:1, leverage over 10x, and an entry far from live. Everything reads in R and % without an account; give account_size and risk_percent (both or neither) to add the fixed-fractional size, notional and margin. Pass placed_at (when the order was placed) to replay the setup since then from public candles, filling the entry by order_type: a limit fills when price comes to it (or at once if it was already marketable, e.g. a buy limit above the market), a stop entry when price comes through it, a market order at placement; R is measured from the actual fill. Statuses: PENDING, MISSED (target traded before the entry), OPEN with the result and best/worst so far in R, STOPPED, TARGET, or AMBIGUOUS when one candle reached both; plus funding paid while open. Nothing about the plan is stored: the numbers come in, the replay goes out, and planLine is the one-line copy to bring the plan back later. Use it after research_opportunities or flow_levels has suggested a setup; it is a check of the setup, not a signal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stopYesStop-loss price (below entry = long, above = short)
entryYesPlanned entry price
symbolYesCoin symbol, e.g. "ETH".
targetNoOptional take-profit price
leverageNoOptional leverage the position is opened at, 1–200, for the liquidation price. Default when sized: the smallest whole leverage that carries the notional; unsized: no liquidation price unless given.
placed_atNoWhen the order was placed, as ISO 8601 (e.g. 2026-10-14T12:00:00Z) or unix time, up to 90 days back. Pass it whenever the user says when the trade was placed or opened ('placed 2026-10-12T12:00Z', 'opened yesterday at 14:00'): with it the tool replays the trade and reports filled / stopped / target / open; without it the plan is checked as if not yet placed.
order_typeNoHow the entry was placed, for the replay. limit (default): fills when price comes to the entry, or at once if the entry was already on the far side of the market. stop: a breakout trigger that fills when price comes through the entry. market: filled at placement. Omit it when the user hasn't said: if the entry was through the market at placement, one call returns both readings (lifecycle as a limit, alternativeLifecycle as a stop); ask the user which applies rather than calling again.
account_sizeNoOptional account equity in USD, with risk_percent: adds the position size, notional and margin. Leave both out when the user didn't give them.
risk_percentNoOptional percent of the account lost if the stop is hit, e.g. 1; only with account_size

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / account_size / description
      Previous value: -"Account equity in USD"New value: +"Optional account equity in USD, with risk_percent: adds the position size, notional and margin. Leave both out when the user didn't give them."
    • changedInput schema / properties / leverage / description
      Previous value: -"Optional leverage the position is opened at, 1–200. Default: the smallest whole leverage that carries the notional."New value: +"Optional leverage the position is opened at, 1–200, for the liquidation price. Default when sized: the smallest whole leverage that carries the notional; unsized: no liquidation price unless given."
    • changedInput schema / properties / risk_percent / description
      Previous value: -"Percent of the account lost if the stop is hit, e.g. 1"New value: +"Optional percent of the account lost if the stop is hit, e.g. 1; only with account_size"
    • changedInput schema / required
      Previous value: -[
      -  "symbol",
      -  "entry",
      -  "stop",
      -  "account_size",
      -  "risk_percent"
      -]New value: +[
      +  "symbol",
      +  "entry",
      +  "stop"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / order_type / description
      Previous value: -"How the entry was placed, for the replay. limit (default): fills when price comes to the entry, or at once if the entry was already on the far side of the market. stop: a breakout trigger that fills when price comes through the entry. market: filled at placement. Ask the user when an entry above the market (long) or below it (short) could be either."New value: +"How the entry was placed, for the replay. limit (default): fills when price comes to the entry, or at once if the entry was already on the far side of the market. stop: a breakout trigger that fills when price comes through the entry. market: filled at placement. Omit it when the user hasn't said: if the entry was through the market at placement, one call returns both readings (lifecycle as a limit, alternativeLifecycle as a stop); ask the user which applies rather than calling again."
  3. Changed1 schema field changed
    • changedInput schema / properties / placed_at / description
      Previous value: -"Optional: when the order was placed, as ISO 8601 (e.g. 2026-10-14T12:00:00Z) or unix time, up to 90 days back. Replays the plan since then."New value: +"When the order was placed, as ISO 8601 (e.g. 2026-10-14T12:00:00Z) or unix time, up to 90 days back. Pass it whenever the user says when the trade was placed or opened ('placed 2026-10-12T12:00Z', 'opened yesterday at 14:00'): with it the tool replays the trade and reports filled / stopped / target / open; without it the plan is checked as if not yet placed."
  4. Changed1 schema field changed
    • addedInput schema / properties / order_type
      Added value: +{
      +  "description": "How the entry was placed, for the replay. limit (default): fills when price comes to the entry, or at once if the entry was already on the far side of the market. stop: a breakout trigger that fills when price comes through the entry. market: filled at placement. Ask the user when an entry above the market (long) or below it (short) could be either.",
      +  "enum": [
      +    "limit",
      +    "stop",
      +    "market"
      +  ],
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / placed_at
      Added value: +{
      +  "description": "Optional: when the order was placed, as ISO 8601 (e.g. 2026-10-14T12:00:00Z) or unix time, up to 90 days back. Replays the plan since then.",
      +  "type": "string"
      +}
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds substantial behavioral context: nothing is persisted ('the numbers come in, the replay goes out'), planLine is the round-trip handle, liquidation is priced with first-tier 0.5% maintenance margin (flagged as the optimistic case), and the full status set (PENDING/MISSED/OPEN/STOPPED/TARGET/AMBIGUOUS) is enumerated. No contradiction with readOnlyHint.

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-loaded with purpose in the first sentence, and every subsequent clause maps to a real behavior (returns, statuses, sizing coupling, replay rules). It is dense as a single block — the return inventory could be broken out — but little of it is filler for a tool of this complexity.

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?

With no output schema, the description carries the return burden itself and does so thoroughly: reward:risk, stop distance in % and 4h ATR, liquidation price, funding per day, perp levels, and the named checks. Edge cases (AMBIGUOUS candle, MISSED target-first) and the stateless model are covered, so an agent has everything needed to call and interpret it.

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 genuinely adds semantics: the both-or-neither coupling of account_size and risk_percent, the leverage default logic, and the order_type fill rules (limit fills on approach or immediately if already marketable). It stops short of 5 because most field-level detail is still carried by 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?

States a specific verb set and resource: 'Check, review or replay a perp trade setup (entry, stop, optional target)', and names the sibling tools it follows (research_opportunities, flow_levels). It also explicitly disclaims being a signal, which separates it from adjacent research tools without opening a schema.

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?

Explicit routing: use after research_opportunities or flow_levels has suggested a setup. It gives conditional guidance for placed_at ('pass it whenever the user says when the trade was placed') and instructs to ask the user rather than re-call when order_type is ambiguous — when/when-not/alternatives are all covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources