TraderSpy
REMOTE · MCP.TRADERSPY.APP
AI crypto signals, whale positions, 19 technical indicators, derivatives, screener and backtests
Available components
Last scanned (1 hour ago)
Scores higher than 99% of remote servers
Reachable. Last reached 17 Oct 2026.
Category Crypto and Web3
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability80
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 3247 tokens (~162/item across 20 items; 17 tools + 3 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management94
- Stability check failed: schema churn in the 30 days we've observed: 1 tool removals, 0 breaking changes, 0 auth/transport breaks, 0 additions. See how to fix → Fail
Tool Coverage99
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 98% of tool parameters carry a description.Partial
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 17 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 19 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
- Supports UI / widget rendering.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 13 Oct 26 0
- The server rewrote its instructions, which are the text every model session reads security
- 11 Oct 26 +2
- Authorization: fail → pass ▲ security
- First check of Authorization: partial security
- The server rewrote its instructions, which are the text every model session reads security
- 3 Oct 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “get_technical_indicators” rewrote its description, which is the text the model reads security
- Server version: 3.0.1 → 3.0.2 functional
- “get_technical_indicators” added an optional parameter “symbols” cosmetic
- “get_technical_indicators” reworded the description of “symbol” cosmetic
- “get_technical_indicators” made “symbol” optional cosmetic
- 1 Oct 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Server version: 3.0.0 → 3.0.1 functional
- 30 Sept 26 0
- Server version: 1.0.0 → 3.0.0 functional
- 29 Sept 26 0
- Tool “get_signal_stats” rewrote its description, which is the text the model reads security
- Tool “get_signals” rewrote its description, which is the text the model reads security
- “get_signal_stats” added an optional parameter “strategy” cosmetic
- “get_signals” added an optional parameter “strategy” cosmetic
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Sept 26 −1
- Stability: pass → fail ▼ security
- A breaking change shipped without a version bump: still 1.0.0 ▼ security
- Tool “get_my_account” was removed ▼ security
- The server rewrote its instructions, which are the text every model session reads security
- Resource “traderspy-account-app” was removed ▼ functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 17 Oct 2026 · Probed https://mcp.traderspy.app/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=traderspy.app | CN=WE1,O=Google Trust Services,C=US | 19 Sept 2026 | 18 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | 955e3b390964863f0ebabc6d2f2acfb2 |
| SANs: traderspy.app, *.traderspy.app | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.traderspy.app. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| app. | present | 23684 | 8 | Verified |
| traderspy.app. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://mcp.traderspy.app/.well-known/oauth-protected-resource/mcp", error="invalid_token", error_description="Authentication required", scope="mcp.read"
Bearer resource_metadata="https://mcp.traderspy.app/.well-known/oauth-protected-resource/mcp", error="invalid_token", error_description="Authentication required", scope="mcp.read"Protected resource metadata
| Document | https://mcp.traderspy.app/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.traderspy.app/mcp |
| Authorisation server | https://api.traderspy.app |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.traderspy.app/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.traderspy.app/mcp | HTTPS enforced | 301 | https://mcp.traderspy.app/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
backtest_condition ~429
What happened AFTER a condition in the past, on one symbol and timeframe — "how did BTC do after RSI dropped below 30 on 4h", "is a golden cross on ETH daily actually bullish", "what usually follows a −5% day on SOL". Runs an event study over the whole stored tape (up to 1000 candles: ~41 days on 1h, ~166 days on 4h, ~3 years on 1d): occurrences, average / median forward return, win rate, average best and worst excursion per horizon, the unconditional baseline over the same tape and the EDGE the condition adds over it, the last five episodes, and whether the condition is active on the latest bar. Same condition vocabulary as screen_symbols. Quote the edge and the sample size together — a 3-sample stat is an anecdote.
| Name | Type | Req | Description |
|---|---|---|---|
| conditions | array | yes | Up to 3 conditions, AND-ed. Examples: RSI oversold = {"metric":"rsi","op":"lt","value":30}; above the 200 EMA = {"metric":"priceVsEma","op":"gt","value":0,"period":200}; golden cross = {"metric":"ema… |
| horizons | array | – | Bars ahead to measure returns over (≤ 4). Default per interval ≈ 4h / 1d / 3d: 1h → [4, 24, 72], 4h → [6, 18, 42], 1d → [1, 3, 7]. |
| interval | string | – | Candle timeframe |
| symbol | string | yes | Trading pair, e.g. BTCUSDT (a bare "BTC" is read as its USDT perpetual) |
| Name | Type | Req | Description |
|---|---|---|---|
| activeNow | boolean|null | – | Conditions hold on the latest closed bar |
| bars | number|null | – | Candles the study ran on (the whole stored tape) |
| conditions | – | – | – |
| coverageHours | number|null | – | – |
| currentValues | – | – | Latest value of every metric involved |
| evaluableBars | number|null | – | – |
| from | – | – | – |
| horizonHours | – | – | – |
| horizons | – | – | Per look-ahead: { bars, samples, avgReturnPct, medianReturnPct, winRatePct, avgMaxUpPct, avgMaxDownPct, bestPct, worstPct, baselineAvgReturnPct, edgePct } — edge = avg − unconditional baseline |
| interval | string|null | – | – |
| lastOccurrence | – | – | { openTime, barsAgo, price } |
| occurrences | number|null | – | Episodes — the FIRST bar of each run where the conditions held |
| recent | – | – | Newest episodes first: { openTime, barsAgo, price, returnsPct { "<bars>": pct } } |
| symbol | string|null | – | – |
| to | – | – | – |
| warnings | – | – | – |
No examples provided.
get_candles ~85
Get OHLCV (Open, High, Low, Close, Volume) candle data for a crypto futures symbol. Useful for charting, price history, and technical analysis.
| Name | Type | Req | Description |
|---|---|---|---|
| interval | string | – | Candle interval/timeframe |
| limit | number | – | Number of candles to return |
| symbol | string | yes | Trading pair symbol, e.g. BTCUSDT |
| Name | Type | Req | Description |
|---|---|---|---|
| candles | – | – | Oldest first |
| interval | string|null | – | – |
| symbol | string|null | – | – |
No examples provided.
get_derivatives ~178
Funding rate, open interest and positioning for Binance USDⓈ-M perpetual futures — the derivatives questions candles cannot answer: is funding high (who is paying whom, annualized), is open interest building or unwinding (24h/4h change, and the OI×price regime: new longs, short covering, new shorts, long liquidation), and which way accounts lean (top-trader long/short by position, all-account ratio, taker buy/sell flow). Each symbol carries plain-language notes — quote those. Up to 5 symbols per call; data is 60s fresh.
| Name | Type | Req | Description |
|---|---|---|---|
| symbols | array | yes | Up to 5 Binance USDⓈ-M futures symbols, e.g. ["BTCUSDT", "ETHUSDT"]. A bare base asset ("BTC") is read as its USDT perpetual. |
| Name | Type | Req | Description |
|---|---|---|---|
| count | number|null | – | – |
| data | – | – | One entry per symbol: { symbol, markPrice, indexPrice, premiumPct, funding { rate, ratePct, annualizedPct, nextFundingTime, minutesToNextFunding, avg24hPct, avg3dPct, label }, openInterest { contract… |
No examples provided.
get_elite_leaderboard ~29
Use this when the user specifically asks for the elite leaderboard by SmartScore across exchanges.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| algorithmDetails | – | – | How each scoring component is weighted |
| algorithmVersion | string|null | – | – |
| key | string|null | – | – |
| lastRunAt | – | – | – |
| leaders | – | – | Ranked traders with score, scoreBreakdown, metrics, rationale[] and tier |
| source | string|null | – | – |
| summary | – | – | Coverage of the run: traders scored, trades counted |
| title | string|null | – | – |
| updatedAt | – | – | – |
No examples provided.
get_exchanges ~27
Use this when the user asks which exchanges are currently available in TraderSpy smart-money tracking.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | Tracked exchanges and whether each is currently enabled |
No examples provided.
get_market_stats ~57
Use this when the user asks for aggregate market stats (positions, PNL, win rate), optionally scoped by source and period.
| Name | Type | Req | Description |
|---|---|---|---|
| period | string | – | Time period for closed position stats |
| source | string | – | Exchange filter |
| Name | Type | Req | Description |
|---|---|---|---|
| avgRoi | number|null | – | – |
| byExchange | – | – | Per-exchange { totalPositions, openPositions }, keyed by exchange |
| closedInPeriod | number|null | – | – |
| openPositions | number|null | – | – |
| period | string|null | – | – |
| realizedPnl | number|null | – | – |
| totalPositions | number|null | – | – |
| winRate | number|null | – | Percentage of closed positions in profit; null when none closed |
No examples provided.
get_positions ~93
Use this when the user asks for current or historical smart-money positions, optionally filtered by status, source, or symbol.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Number of positions to return |
| offset | number | – | Offset for pagination |
| source | string | – | Exchange filter |
| status | string | – | Position status filter |
| symbol | string | – | Filter by trading pair, e.g. BTC, ETHUSDT |
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | Smart money positions across the tracked exchanges |
| pagination | – | – | – |
No examples provided.
get_price ~69
Get real-time price data for one or more crypto futures symbols. Returns current price, 24h high/low, volume, and 24h price change percentage.
| Name | Type | Req | Description |
|---|---|---|---|
| symbols | array | yes | List of symbols to get prices for, e.g. ["BTCUSDT", "ETHUSDT"] |
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | – |
No examples provided.
get_signal_details ~45
Use this when the user needs full details for one AI signal by ID, including review and resolution data.
| Name | Type | Req | Description |
|---|---|---|---|
| signalId | string | yes | The ID of the signal to retrieve |
| Name | Type | Req | Description |
|---|---|---|---|
| action | string|null | – | buy or sell |
| aiReview | – | – | – |
| coin | string|null | – | – |
| createdAt | – | – | – |
| history | – | – | – |
| howToRead | string|null | – | How the outcome was judged, in one sentence |
| id | string|null | – | Signal id — pass to get_signal_details |
| importance | string|null | – | high | medium | low |
| indicatorValues | – | – | Indicator readings at trigger time |
| livePrice | number|null | – | Current price, so the model can judge whether the signal still stands |
| price | number|null | – | Price when the signal triggered |
| resolutionStatus | string|null | – | pending | stop | tp1_hit | tp2_hit | tp3_hit | profit_locked | expired |
| signalStrength | string|null | – | weak | moderate | strong | very_strong |
| strategyName | string|null | – | Preset that produced the signal |
| targets | – | – | Take-profit and stop levels: { label, type, pct } |
| timeframe | string|null | – | Chart timeframe the preset evaluated, e.g. 4h |
| triggeredConditions | – | – | – |
No examples provided.
get_signal_stats ~102
Use this when the user asks for aggregate AI signal performance statistics over a specific period — overall, or for one strategy (preset) by name. The answer also breaks the period down per strategy (byStrategy), which is how to learn the strategy names for get_signals.
| Name | Type | Req | Description |
|---|---|---|---|
| period | string | – | Time period for statistics |
| strategy | string | – | Only the signals of one AI strategy (preset), matched by part of its name, case-insensitive. |
| Name | Type | Req | Description |
|---|---|---|---|
| byStrategy | – | – | The same counts per strategy (preset) that fired in the period, most signals first |
| highCount | number|null | – | High-importance signals |
| howToRead | – | – | How an outcome is judged and what winRate counts; quote it when the user asks how the statistics work |
| pending | number|null | – | Still open at the end of the period |
| stopped | number|null | – | – |
| strategy | string|null | – | The strategy filter that was applied, if any |
| targetHits | number|null | – | Signals that reached a take-profit or locked profit |
| total | number|null | – | Signals published in the period |
| warning | string|null | – | Set when a strategy filter could not be applied or matched nothing (with the closest preset names) |
| winRate | number|null | – | targetHits / resolved, as a percentage; null when nothing resolved |
No examples provided.
get_signals ~212
Use this when the user asks for recent public AI crypto trading signals, optionally filtered by coin, importance, strategy (the preset that produced them, by name) or pagination. When the user names a count ("last 5 signals"), pass it as `limit` — the card view renders exactly what was fetched, so over-fetching shows more cards than the user asked for.
| Name | Type | Req | Description |
|---|---|---|---|
| coin | string | – | Filter by coin symbol, e.g. BTC, ETH |
| importance | string | – | Filter by signal importance |
| limit | number | – | Number of signals to return |
| skip | number | – | Offset for pagination |
| strategy | string | – | Filter by the AI strategy (preset) that produced the signal — part of its name, words in order, case-insensitive, e.g. "ATR Squeeze" or "Triple Oversold". get_signal_stats (period 7d) lists the strat… |
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | Signals, newest first |
| pagination | – | – | – |
| warning | string|null | – | Set when a strategy filter could not be applied or matched nothing (with the closest preset names) |
No examples provided.
get_technical_indicators ~515
Technical analysis for a crypto futures symbol. 19 indicators: RSI, MACD, EMA, SMA, Bollinger Bands, ATR, ADX (+DI/−DI), Stochastic, OBV (with price divergence), VWAP, CCI, MFI, Williams %R, ROC, SuperTrend, Ichimoku, Keltner Channels, classic pivot points and swing support/resistance levels. Every indicator returns its current value, the previous bar, a rising/falling/flat direction, a short `series` history and — where it applies — zones and crossovers. EMA/SMA accept several periods at once (default 20/50/200); every period is overridable via `periods`. Pass `intervals` (up to 3) to get 1h/4h/1d in ONE call with a multi-timeframe `confluence` verdict. Each timeframe also carries a `summary` (bias, trend, momentum, volatility, volume, plain-language notes) computed from a fixed indicator set — quote its notes rather than the raw score. For several coins pass `symbols` (up to 3) instead of one call per coin: ONE call and one quota unit, one entry per symbol in `data`.
| Name | Type | Req | Description |
|---|---|---|---|
| history | integer | – | Prior values returned per indicator as `series` (oldest → newest, length history + 1). 0 = latest only. |
| indicators | array | – | Indicators to compute. `levels` = swing support/resistance from price structure, `pivots` = classic floor pivots from the previous day. |
| interval | string | – | Candle timeframe. Ignored when `intervals` is given. |
| intervals | array | – | Up to 3 timeframes in ONE call (one quota unit), e.g. ["1h","4h","1d"]. The response then carries per-timeframe results plus a `confluence` verdict. |
| periods | object | – | Optional period overrides, e.g. {"ema":[9,21,55,200],"rsi":7} |
| symbol | string | – | Trading pair symbol, e.g. BTCUSDT. For several pairs pass `symbols` instead. |
| symbols | array | – | Up to 3 trading pairs in ONE call (one quota unit), e.g. ["BTCUSDT","ETHUSDT","SOLUSDT"]. The response then carries one entry per symbol in `data`, each shaped like the single-symbol response. |
| Name | Type | Req | Description |
|---|---|---|---|
| candles | number|null | – | Closed candles the primary timeframe was computed on |
| confluence | – | – | Multi-timeframe agreement: { aligned, bias, byInterval } |
| count | number|null | – | Entries in `data` |
| data | – | – | Present when `symbols` was passed, and then the only place the results are: one entry per symbol, in the requested order, each exactly the single-symbol response above ({ symbol, interval, price, can… |
| indicators | – | – | Single-timeframe call only: requested indicators keyed by name. Each carries value, previous, direction, series and indicator-specific fields (zone, crossover, stack, levels…); { value: null, reason:… |
| interval | string|null | – | Primary timeframe (the first requested one) |
| lastCandleOpenTime | – | – | – |
| price | number|null | – | Latest close on the primary timeframe, or null when no candles are stored |
| settings | – | – | Echo of what was computed: indicators, history, resolved periods |
| summary | – | – | Single-timeframe call only: bias, score, trend, momentum, volatility, volume, notes[]. Omitted when `timeframes` is present. |
| symbol | string|null | – | – |
| timeframes | – | – | Present when several intervals were requested: one { interval, price, candles, indicators, summary } per timeframe, in the requested order. The top-level indicators/summary are omitted in that case. |
| warnings | – | – | – |
No examples provided.
get_top_traders ~97
Use this when the user wants ranked smart-money traders across supported exchanges with sorting and filtering.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Number of traders to return |
| order | string | – | Sort direction |
| rankingType | string | – | Ranking snapshot type |
| sortBy | string | – | Sort metric (defaults to ranking type) |
| source | string | – | Exchange to filter by |
| timeRange | string | – | Performance time range |
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | Ranked traders: source, topTraderId, traderName, roi, pnl, winRate, smartScore, rank, rankings[] |
No examples provided.
get_tracked_symbols ~27
List all crypto futures symbols currently tracked by TraderSpy with real-time candle data available.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| count | number|null | – | – |
| symbols | – | – | – |
No examples provided.
get_trader_position_history ~64
Use this when the user asks for closed trade history of a specific trader.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | number | – | Results per page |
| page | number | – | Page number |
| source | string | – | Exchange |
| traderId | string | yes | The trader ID |
| Name | Type | Req | Description |
|---|---|---|---|
| data | – | – | Closed positions, most recently closed first |
| pagination | – | – | – |
No examples provided.
get_trader_profile ~71
Use this when the user needs one trader profile, including metrics and latest positions.
| Name | Type | Req | Description |
|---|---|---|---|
| rankingType | string | – | Ranking snapshot type |
| source | string | – | Exchange the trader is on |
| timeRange | string | – | Performance time range |
| traderId | string | yes | The trader ID |
| Name | Type | Req | Description |
|---|---|---|---|
| aum | number|null | – | – |
| avatarUrl | string|null | – | – |
| mdd | number|null | – | Maximum drawdown |
| pnl | number|null | – | – |
| positions | – | – | Currently tracked positions |
| rank | number|null | – | – |
| rankingType | string|null | – | – |
| roi | number|null | – | – |
| smartScore | number|null | – | – |
| source | string|null | – | – |
| timeRange | string|null | – | – |
| topTraderId | string|null | – | – |
| traderName | string|null | – | – |
| winRate | number|null | – | – |
No examples provided.
screen_symbols ~507
Screen MANY crypto futures symbols at once on one timeframe — "which coins are oversold on 4h", "what is above its 200 EMA with rising volume", "show me squeezes". Give up to 3 AND-ed conditions from a fixed metric list (RSI, stochastic, CCI, MFI, Williams %R, ADX, ROC, MACD histogram, ATR%, volume ratio, Bollinger %B / width, price vs EMA, EMA spread, SuperTrend, change %, price) with lt / gt / crossAbove / crossBelow. Scans the most-traded symbols by 24h volume (default 50, max 100) or an explicit list; every row carries the metric values plus bias, trend, RSI, ADX, ATR% and 24h change. With NO conditions and explicit `symbols` it is a side-by-side comparison table ("compare BTC, ETH, SOL"). ONE quota unit however many symbols — always prefer this over calling get_technical_indicators in a loop.
| Name | Type | Req | Description |
|---|---|---|---|
| conditions | array | – | Up to 3 conditions, AND-ed. Examples: RSI oversold = {"metric":"rsi","op":"lt","value":30}; above the 200 EMA = {"metric":"priceVsEma","op":"gt","value":0,"period":200}; golden cross = {"metric":"ema… |
| interval | string | – | Candle timeframe to evaluate on |
| limit | integer | – | Rows to return |
| sortBy | string | – | volume (24h quote volume), change24h, or metric (the first condition's metric). Default: metric when conditions are given, else volume. |
| sortOrder | string | – | – |
| symbols | array | – | Explicit symbols to scan (≤ 100, e.g. ["BTC","ETH","SOL"]). Omit to scan the most-traded symbols instead. With no `conditions`, every listed symbol is returned as a comparison table. |
| universe | integer | – | How many of the most-traded symbols (by 24h volume) to scan when `symbols` is omitted (max 100) |
| Name | Type | Req | Description |
|---|---|---|---|
| conditions | – | – | Human-readable conditions, e.g. "RSI(14) < 30" |
| interval | string|null | – | – |
| matched | number|null | – | Symbols satisfying every condition (all scanned symbols when no conditions) |
| results | – | – | One row per matching symbol: { symbol, price, change24hPct, volume24hUsd, values { "<metric label>": value }, bias, trend, rsi14, adx14, atrPct, volumeRatio, squeeze } |
| returned | number|null | – | – |
| sortBy | string|null | – | – |
| sortOrder | string|null | – | – |
| universe | – | – | { source: top_by_volume | explicit, requested, scanned, missing[] } |
| warnings | – | – | – |
No examples provided.
How do I install the TraderSpy MCP server?
TraderSpy is a hosted endpoint at https://mcp.traderspy.app/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.traderspy.app
claude mcp add --transport http app-traderspy-traderspy 'https://mcp.traderspy.app/mcp'
What is the TraderSpy MCP server?
TraderSpy is an MCP server listed in the public MCP registry as app.traderspy/traderspy. AI crypto signals, whale positions, 19 technical indicators, derivatives, screener and backtests. This page covers its hosted endpoint (https://mcp.traderspy.app/mcp).
Is the TraderSpy MCP server safe to use?
TraderSpy scores 91 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the TraderSpy MCP server expose?
TraderSpy exposes 17 tools: get_signals, get_signal_details, get_signal_stats, get_top_traders, get_elite_leaderboard, and 12 more. Their descriptions and schemas cost roughly 2,607 tokens of context every time the server is loaded.
Does the TraderSpy MCP server require authentication?
Yes. TraderSpy asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the TraderSpy MCP server still maintained?
TraderSpy is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.