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, costs that pull a 2:1 plan under it, leverage over 10x, and an entry far from live. Costs: fees per fill (a venue's base tier, Binance by default; override with venue, fee_bps, maker_fee_bps), funding carry over hold_hours at the current rate with the rate's 1y percentile, and, when sized, the slippage of a market exit of the whole size at the stop against today's visible book; they give a net reward:risk, the break-even win rate, and the stop, target and liquidation outcomes in R (and USD and % of account when sized). 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

NameRequiredDescriptionDefault
stopYesStop-loss price (below entry = long, above = short)
entryYesPlanned entry price
venueNoOptional venue whose base-tier fees to apply. Default binance (5 bps taker, 2 bps maker).
symbolYesCoin symbol, e.g. "ETH".
targetNoOptional take-profit price
fee_bpsNoOptional taker fee per fill in bps of notional (e.g. 4.5), when the user states their own fee tier. Overrides the venue's.
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.
hold_hoursNoOptional expected holding time in hours, e.g. 72 for three days: prices the funding carry over the hold into the net reward:risk.
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. Also sets the entry fee: a resting limit pays maker, anything else taker.
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
maker_fee_bpsNoOptional maker fee per fill in bps (negative for a rebate). Overrides the venue's.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / fee_bps
      Added value: +{
      +  "description": "Optional taker fee per fill in bps of notional (e.g. 4.5), when the user states their own fee tier. Overrides the venue's.",
      +  "type": "number"
      +}
    • addedInput schema / properties / hold_hours
      Added value: +{
      +  "description": "Optional expected holding time in hours, e.g. 72 for three days: prices the funding carry over the hold into the net reward:risk.",
      +  "type": "number"
      +}
    • addedInput schema / properties / maker_fee_bps
      Added value: +{
      +  "description": "Optional maker fee per fill in bps (negative for a rebate). Overrides the venue's.",
      +  "type": "number"
      +}
    • 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. 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."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. Also sets the entry fee: a resting limit pays maker, anything else taker."
    • addedInput schema / properties / venue
      Added value: +{
      +  "description": "Optional venue whose base-tier fees to apply. Default binance (5 bps taker, 2 bps maker).",
      +  "enum": [
      +    "binance",
      +    "bybit",
      +    "okx",
      +    "hyperliquid",
      +    "bingx",
      +    "bitget"
      +  ],
      +  "type": "string"
      +}
  2. 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"
      +]
  3. 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."
  4. 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."
  5. 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"
      +}
  6. 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"
      +}
  7. Added

TDQS

A4.8/5.0
Behavior5/5

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

Despite only carrying readOnlyHint=true, the description goes well beyond annotations by disclosing extensive behavior: output metrics, named checks, cost modeling, replay statuses, and that nothing is stored. This is exactly the kind of behavioral context an agent needs for a complex read/analysis tool.

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 description is long but front-loaded with purpose and justified by the tool's complexity, 13 parameters, and lack of an output schema. It is dense with semicolon-chained details, so it is not maximally clean, but most content earns its place.

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 complex tool with no output schema, the description explains the return values, named checks, cost breakdown, replay statuses, and storage behavior. An agent has enough context to invoke and interpret the tool correctly.

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 already 100%, so the schema does most parameter documentation. The description still adds operational meaning, such as account_size and risk_percent being both-or-neither, how placed_at toggles replay, and how order_type affects fills and fee treatment.

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 states a specific verb and resource: check, review or replay a perp trade setup before or after placement. It distinguishes itself from sibling tools explicitly by naming research_opportunities and flow_levels and stating it is a check, not a signal.

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 gives clear when-to-use guidance: after research_opportunities or flow_levels suggests a setup, and before or after placement. It also clarifies it is not a signal, which directly separates it from signal-producing siblings.

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