TraderSpy Trading Signals

TraderSpy's AI signals are automated reads of the market: a named preset fires when several technical conditions line up on one crypto futures pair, a validator scores the alignment, and the published signal carries an entry, a take-profit ladder, a stop and — later — what actually happened. The signals feed at https://traderspy.app/signals publishes every one with its resolved outcome. Your job is to fetch, translate and contextualise them; the decision stays with the user.

When to Use

• Use when the user mentions crypto signals, AI alerts, "any setups", "what is the AI seeing", long or short ideas, or TraderSpy alerts, even without the word "signal".
• Use to explain one signal's entry, take-profit and stop levels and the conditions that triggered it, or whether it still stands at the current price.
• Use when the user asks how signals have resolved (hits vs stops) over the last 4h to 7d.
• Not for placing trades (no tool can), not for top-trader positioning (@traderspy-smart-money), not for indicator reads on a coin (@traderspy-technical-analysis).

Tools

Three argument behaviours that are easy to get wrong:

• importance is inclusive downward. high returns high only, medium returns high AND medium, low returns everything. To show "medium and above" pass medium, not low.
• coin is a prefix match on the pair name. BTC matches BTCUSDT and also BTCDOMUSDT; check the coin field of each row before presenting "BTC signals".
• limit is what gets rendered. In hosts that draw signal cards, every fetched row becomes a card. If the user asks for "the last 5", pass limit: 5 — do not fetch 20 and show 5.

What a signal row contains

strategyName (the preset, e.g. "OBV Divergence Buy (4H)") · action buy / sell · timeframe 1h / 4h / 1d · price at trigger · targets[] as {label, type, pct} where pct is measured from price · triggeredConditions[] in plain language · importance · signalStrength weak / moderate / strong / very_strong · resolutionStatus · createdAt.

Convert target percentages to prices before showing them — users think in prices:

• buy: TP = price × (1 + pct/100), SL = price × (1 − pct/100)
• sell: TP = price × (1 − pct/100), SL = price × (1 + pct/100)
• reward-to-risk at TP1 = TP1 pct ÷ SL pct (a 0.7 R:R is normal for this system, whose first target sits close to entry; read it together with the hit rate from get_signal_stats, and do not call a sub-1 R:R "bad" on its own).

resolutionStatus is the outcome so far:

Outcomes are judged on 1-minute wicks, so "TP1 hit" means price actually traded there. The tracking window is 24 × the signal timeframe (24h for a 1h signal, 4 days for a 4h signal); a 1h signal that is still pending two days later is stale rather than alive.

Workflows

"Latest signals" / "any setups?" → get_signals with the limit the user implies (default 10 if they gave no number). Lead with the newest, group by side if several, and make the resolved ones visible — a list that mixes three winners, two stops and five pending rows should say so.

"Signals for SOL" → get_signals with coin. If the result is empty, say there is no recent signal on that pair rather than offering a different pair as if it were the same thing.

"Is this signal still valid?" / "Should I still care about it?" → get_signal_details, then compare livePrice with the entry, TP1 and SL in the same units:

• distance from entry in % (signed the way the trade wants it: for a buy, positive = in profit)
• whether a level has already been crossed (a pending buy with livePrice below the SL price

…