AI-generated crypto futures signals with entry, target and stop levels, plus smart money whale positioning across Binance, Hyperliquid, Bybit and OKX. Also live prices, candles and 13 technical indicators — every tool is read-only.
Scored across 18 tools
Most tools are clearly distinct (e.g., get_candles vs get_technical_indicators vs backtest_condition), but some overlap exists between get_market_stats and get_signal_stats (both aggregate performance but for different domains), and get_trader_position_history vs get_positions could be confused (one trader vs smart-money). Overall, descriptions clarify the boundaries well.
Names follow a clear verb_noun pattern: get_* for data retrieval, screen_symbols, backtest_condition. Minor inconsistency: backtest_condition uses a verb_noun but with 'condition' as a noun, which is acceptable. No camelCase or mixed conventions. Slight deviation with 'screen_symbols' (verb_screen + noun) but still consistent with the pattern.
18 tools is on the higher end but well-scoped for a comprehensive crypto analysis server covering market data, technical indicators, smart-money tracking, signals, and backtesting. Each tool serves a distinct purpose and the count is justified by the breadth of features.
The surface is fairly complete for read-only analysis: candles, indicators, screening, backtesting, signals, and trader data. However, there are gaps: no tool for historical OHLCV beyond the last 1000 candles (backtest_condition is limited to a fixed window), no direct comparison between symbols beyond simple screening, and no tool for combining multiple conditions across timeframes. Some dead ends like get_elite_leaderboard are listed but no related drill-down for individual elite traders.
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 | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair, e.g. BTCUSDT (a bare "BTC" is read as its USDT perpetual) | |
| horizons | No | 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 | No | Candle timeframe | 4h |
| conditions | 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":"emaSpread","op":"crossAbove","value":0,"period":50,"period2":200}; MACD bullish cross = {"metric":"macdHistogram","op":"crossAbove","value":0}; dumped 5% in a day = {"metric":"changePct","op":"lt","value":-5,"period":24}. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| bars | No | Candles the study ran on (the whole stored tape) |
| from | No | |
| recent | No | Newest episodes first: { openTime, barsAgo, price, returnsPct { "<bars>": pct } } |
| symbol | No | |
| horizons | No | Per look-ahead: { bars, samples, avgReturnPct, medianReturnPct, winRatePct, avgMaxUpPct, avgMaxDownPct, bestPct, worstPct, baselineAvgReturnPct, edgePct } — edge = avg − unconditional baseline |
| interval | No | |
| warnings | No | |
| activeNow | No | Conditions hold on the latest closed bar |
| conditions | No | |
| occurrences | No | Episodes — the FIRST bar of each run where the conditions held |
| horizonHours | No | |
| coverageHours | No | |
| currentValues | No | Latest value of every metric involved |
| evaluableBars | No | |
| lastOccurrence | No | { openTime, barsAgo, price } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it runs over the entire stored tape (up to 1000 candles), computes specific statistics (average/median forward return, win rate, best/worst excursion, baseline, edge), and includes a critical caveat about quoting edge with sample size (a 3-sample stat is an anecdote). This goes beyond annotations and is useful for proper interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence earns its place. It front-loads the core question and examples, then details the analysis output and caveat. It is not overly verbose; the length is justified by the complexity of the tool. However, it could be slightly more concise by trimming some redundant phrasing, but overall it is well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a complex tool. It covers what the tool does, what it returns (occurrences, forward returns, win rate, excursions, baseline, edge, last five episodes, active status), the sample size limitation, and gives usage examples. It even mentions the output includes an unconditional baseline and the edge, which are crucial for interpretation. With an output schema present, it doesn't need to detail return format, but the description gives a full conceptual overview. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions, so baseline is 3. The tool description adds value by explaining default horizons per interval, the concept of 'edge' over the baseline, and providing concrete condition examples (RSI oversold, golden cross, etc.) that clarify how to structure conditions. It also clarifies the meaning of the edge statistic, which is not in the schema. This is meaningful added semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it runs an event study on historical data to answer 'what happened AFTER a condition in the past' for a given symbol and timeframe. It uses a specific verb (backtest), a resource (condition on a symbol/timeframe), and provides concrete examples (RSI, golden cross, -5% day) that distinguish it from siblings like screen_symbols, which is implied to be for current screening. The phrasing 'Same condition vocabulary as screen_symbols' further clarifies its relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: for historical performance analysis of a condition, contrasting with screening current conditions via screen_symbols (implied by the vocabulary mention). It gives examples of questions it answers, but it does not explicitly state 'use screen_symbols for current screening' or list when not to use this tool. The guidance is clear from context but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OHLCV (Open, High, Low, Close, Volume) candle data for a crypto futures symbol. Useful for charting, price history, and technical analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of candles to return | |
| symbol | Yes | Trading pair symbol, e.g. BTCUSDT | |
| interval | No | Candle interval/timeframe | 1h |
| Name | Required | Description |
|---|---|---|
| symbol | No | |
| candles | No | Oldest first |
| interval | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the OHLCV data type and use cases but does not disclose additional behavioral traits like pagination, rate limits, or return format. This matches the baseline where annotations carry the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states what the tool does and why it is useful. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, fully described schema, and output schema presence, the description is nearly complete. It could explicitly note that this returns historical data versus a current price, which would improve differentiation from get_price, but the OHLCV mention largely covers this. Slightly more contextual guidance would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all three parameters (symbol, interval, limit) fully described, including defaults, enums, and ranges. The description adds no parameter-specific meaning beyond saying 'OHLCV', so the schema already does the heavy lifting; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('OHLCV candle data') and scope ('for a crypto futures symbol'). It also lists concrete use cases ('charting, price history, and technical analysis'), which distinguishes it from siblings like get_price (likely current price) and get_technical_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool ('Useful for charting, price history, and technical analysis'), implying these scenarios. However, it does not explicitly mention alternatives or when not to use it, such as 'for current price, use get_price'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| symbols | 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 | Required | Description |
|---|---|---|
| data | No | One entry per symbol: { symbol, markPrice, indexPrice, premiumPct, funding { rate, ratePct, annualizedPct, nextFundingTime, minutesToNextFunding, avg24hPct, avg3dPct, label }, openInterest { contracts, valueUsd, change4hPct, change24hPct, priceChange24hPct, regime }, positioning { globalLongShortRatio, globalLongPct, topTraderLongShortRatio, topTraderLongPct, takerBuySellRatio, label }, notes[] } — or { symbol, error, message } when the symbol is not a Binance USDⓈ-M futures pair |
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by noting data is 60 seconds fresh and that each symbol carries plain-language notes that should be quoted, giving the agent clear expectations about output style and data timeliness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat dense with rhetorical questions and parentheticals, but it remains purposeful and front-loaded with the core resource and data types. The repetition of 'Up to 5 symbols per call' is slightly redundant with the schema, but the overall structure is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single-parameter schema, an output schema, and rich annotations, the description is complete enough for correct invocation. It covers what data is returned, how the parameter behaves, output note guidance, freshness, and usage limits, leaving no critical gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description fully explains the single `symbols` parameter, including the array limit of 1–5, concrete examples like 'BTCUSDT' and 'ETHUSDT', and the rule that a bare base asset like 'BTC' is interpreted as its USDT perpetual. This exceeds basic parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns funding rate, open interest, and positioning data for Binance USDⓈ-M perpetual futures, and explicitly frames it as 'the derivatives questions candles cannot answer.' This makes the resource and data scope unambiguous and distinguishes it from price/candle-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases—checking whether funding is high, whether open interest is building/unwinding, and how accounts lean—and notes the 5-symbol limit and 60-second freshness. It does not explicitly name alternative tools beyond 'candles,' but the use-case framing is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user specifically asks for the elite leaderboard by SmartScore across exchanges.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| key | No | |
| title | No | |
| source | No | |
| leaders | No | Ranked traders with score, scoreBreakdown, metrics, rationale[] and tier |
| summary | No | Coverage of the run: traders scored, trades counted |
| lastRunAt | No | |
| updatedAt | No | |
| algorithmDetails | No | How each scoring component is weighted |
| algorithmVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only and idempotent behavior. The description adds useful scoping context ('by SmartScore across exchanges') without contradicting annotations. It doesn't detail edge cases or rate limits, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the trigger condition and the tool's purpose. No wasted words, perfectly scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with a clear output schema and simple trigger, the description fully covers the necessary context. There are no gaps in usage preconditions or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. Schema coverage is trivially 100%, and there are no parameter details missing—the description doesn't need to explain parameters that don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource—'get the elite leaderboard'—and adds the scoping detail 'by SmartScore across exchanges,' which clearly differentiates it from sibling tools like get_top_traders. It tells the agent exactly what the tool does and when to consider it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear trigger condition ('when the user specifically asks for'), giving explicit context for when to use the tool. However, it does not mention alternatives or state when not to use it, which is a minor gap relative to the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which exchanges are currently available in TraderSpy smart-money tracking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | No | Tracked exchanges and whether each is currently enabled |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds only context about the data source. It does not describe return format or dynamic behavior, which is acceptable given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant content, perfectly sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no params, strong annotations, and an output schema present, the description adequately covers the tool's purpose and use case. Could slightly benefit from mentioning the output nature, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so the baseline is 4. The description appropriately avoids parameter details since none exist; schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns available exchanges in TraderSpy smart-money tracking, using a clear resource (exchanges) and context, distinguishing it from sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance ('when the user asks which exchanges are currently available'), but does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for aggregate market stats (positions, PNL, win rate), optionally scoped by source and period.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for closed position stats | |
| source | No | Exchange filter | all |
| Name | Required | Description |
|---|---|---|
| avgRoi | No | |
| period | No | |
| winRate | No | Percentage of closed positions in profit; null when none closed |
| byExchange | No | Per-exchange { totalPositions, openPositions }, keyed by exchange |
| realizedPnl | No | |
| openPositions | No | |
| closedInPeriod | No | |
| totalPositions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool computes aggregate stats and supports optional filters, but it does not describe any additional behavioral traits such as exactly which stats are computed or how period affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that immediately states when to use the tool and what it does. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read-only aggregation tool with two optional parameters, a rich input schema with enums and defaults, and an output schema, the description is sufficient. It tells the agent what the tool offers and how the optional filters apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions (period for closed position stats, source as exchange filter). The description's mention of scoping by source and period is consistent but does not add meaningful semantics beyond an already well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the one for aggregate market stats (positions, PNL, win rate), and the optional source/period scoping adds useful specificity. It doesn't explicitly contrast with sibling tools, but 'aggregate' and the stat types help differentiate it from get_positions, get_my_account, and get_signal_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear invocation guidance: use when the user asks for aggregate market stats, optionally scoped by source and period. It does not name alternative tools or explicitly say when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about THEIR OWN TraderSpy account: Hyperliquid balance, open positions, unrealized PnL, or paper-trading account. Read-only — this connector cannot place, close or modify orders, and cannot withdraw. Requires a personal MCP connection (key from traderspy.app Settings).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| paper | No | Paper trading account, when enabled |
| trading | No | Connector capabilities: read-only. States that this connector cannot place orders or withdraw, and where the user trades instead |
| balances | No | { accountValueUsd, withdrawableUsd } |
| setupUrl | No | Where to create a wallet, returned only when hasWallet is false |
| hasWallet | No | False when the user has not created a Hyperliquid wallet yet |
| positions | No | Open Hyperliquid positions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false. The description adds explicit behavioral detail beyond that: 'cannot place, close or modify orders, and cannot withdraw' and the connection requirement. This goes beyond merely restating the annotation, providing practical constraints an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: usage scope, behavioral limitation, and prerequisite. No redundancy, and the key information is front-loaded in the first sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, the description covers all necessary context: when to use, what it returns, limitations, and prerequisites. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. Per the rubric, 0 params gets a baseline of 4. The description doesn't need to explain parameters, and it doesn't—no missed opportunity since there's nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the user's own TraderSpy account information (balance, positions, PnL, paper-trading). It explicitly scopes to 'THEIR OWN' account, distinguishing it from sibling tools like get_positions that are not account-specific. The verb 'get' plus the resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence gives an explicit usage condition: 'Use this when the user asks about THEIR OWN TraderSpy account.' It also notes read-only limitations and the prerequisite of a personal MCP connection. This clearly tells an agent when to invoke this tool vs alternatives, though it doesn't name specific sibling tools, the condition is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for current or historical smart-money positions, optionally filtered by status, source, or symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of positions to return | |
| offset | No | Offset for pagination | |
| source | No | Exchange filter | all |
| status | No | Position status filter | all |
| symbol | No | Filter by trading pair, e.g. BTC, ETHUSDT |
| Name | Required | Description |
|---|---|---|
| data | No | Smart money positions across the tracked exchanges |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the historical/current scope and filter capabilities, but does not describe return format or pagination behavior. Given the annotations cover the safety profile, the added context brings it to a moderate level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the trigger ('Use this when') and fills in scope and filters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (all params with descriptions), strong annotations, and presence of an output schema, the description covers the essential purpose and use context. It lacks an explicit contrast with get_trader_position_history, which would make it more complete in a sibling-rich environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The description repeats the filter dimensions (status, source, symbol) without adding new meaning or format details, so it lands at the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves smart-money positions, with scope (current/historical) and filter dimensions (status, source, symbol). This distinguishes it from the more specific sibling get_trader_position_history, though it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when the user asks for current or historical smart-money positions, with optional filters. It lacks explicit exclusions or named alternatives, but the trigger condition and scope are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | List of symbols to get prices for, e.g. ["BTCUSDT", "ETHUSDT"] |
| Name | Required | Description |
|---|---|---|
| data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description aligns with these (fetches data, no writes). It adds behavioral detail about what data is returned (current price, high/low, volume, change), which is useful. However, it does not disclose details like rate limits, potential symbol validation, or handling of invalid symbols. With annotations covering the safety profile, the description adds some value but isn't rich on edge-case behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main purpose, and wastes no words. Every sentence provides value: the first defines the action, the second lists return data. It is appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema exists), the description is complete enough for selection and invocation. It lists key return data. It does not describe all output schema fields, but the output schema likely covers that. Minor gap: no mention of error handling or symbol format beyond the example, but this is minor for a price-query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the one parameter ('symbols') with a description and example. The tool description adds context about what the data is used for (real-time price data) but does not add meaning beyond the schema's parameter description. Given high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get real-time price data for one or more crypto futures symbols.' It specifies the resource (price data), the action (get), and the scope (one or more symbols). It also lists the returned data points (current price, 24h high/low, volume, 24h change). This distinguishes it from siblings like get_candles or get_market_stats, which likely focus on different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching current prices, but does not explicitly state when to use this tool versus alternatives. For example, it doesn't say 'use this for live spot-price queries, use get_candles for OHLC history' or reference siblings. The context of 'real-time' and '24h' data gives some implicit guidance, but explicit differentiation or when-not-to-use scenarios are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs full details for one AI signal by ID, including review and resolution data.
| Name | Required | Description | Default |
|---|---|---|---|
| signalId | Yes | The ID of the signal to retrieve |
| Name | Required | Description |
|---|---|---|
| id | No | Signal id — pass to get_signal_details |
| coin | No | |
| price | No | Price when the signal triggered |
| action | No | buy or sell |
| history | No | |
| targets | No | Take-profit and stop levels: { label, type, pct } |
| aiReview | No | |
| createdAt | No | |
| livePrice | No | Current price, so the model can judge whether the signal still stands |
| timeframe | No | Chart timeframe the preset evaluated, e.g. 4h |
| importance | No | high | medium | low |
| strategyName | No | Preset that produced the signal |
| signalStrength | No | weak | moderate | strong | very_strong |
| indicatorValues | No | Indicator readings at trigger time |
| resolutionStatus | No | pending | stop | tp1_hit | tp2_hit | tp3_hit | profit_locked | expired |
| triggeredConditions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that it includes 'review and resolution data', which is useful but does not describe handling of missing IDs or response structure. This is comparable to the calibration example, where annotations cover safety and the description adds minimal behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that immediately states purpose and includes the key constraint (by ID). Zero waste, effective for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one param (100% schema coverage), read-only annotations, and an output schema available. The description tells the agent exactly what it returns (full details, review and resolution data) and the condition (by ID), which is complete for this type of lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'signalId' described as 'The ID of the signal to retrieve'. The description reinforces that it's an ID-based lookup but does not add new semantics beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('retrieve'), the resource ('one AI signal by ID'), and the scope ('full details... including review and resolution data'). It clearly distinguishes from listing signals, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description opens with 'Use this when the user needs full details for one AI signal by ID', which is a clear usage trigger. However, it does not explicitly name alternative tools for listing signals or when to use them, though the phrasing implies a single-item retrieval by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for recent public AI crypto trading signals, optionally filtered by coin, importance, 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 | Required | Description | Default |
|---|---|---|---|
| coin | No | Filter by coin symbol, e.g. BTC, ETH | |
| skip | No | Offset for pagination | |
| limit | No | Number of signals to return | |
| importance | No | Filter by signal importance | all |
| Name | Required | Description |
|---|---|---|
| data | No | Signals, newest first |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds key behavioral context beyond this: it explains the tool fetches 'recent public AI crypto trading signals' and crucially, it reveals a rendering constraint—the card view displays exactly what was fetched, which affects how parameters should be passed. This trades on the annotation safety profile while adding genuine value about the UI coupling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff. The first sentence explains what the tool does and its filter options; the second explains a subtle parameter-mapping requirement with a concrete example ('last 5 signals' → limit). Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read-only, filtered-list tool with excellent annotations (readOnlyHint, idempotentHint, destructiveHint), a 100%-documented schema, and a clear sibling landscape (get_signal_details, get_signal_stats, get_market_stats). The description fills the one remaining gap—the UI coupling to the limit parameter—making this complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter already documented in the schema. The description adds value for the `limit` parameter by explaining that when the user names a count, it should be passed as `limit`—context not present in the schema. While it doesn't enumerate all parameters, the schema already does that job well, so the description appropriately focuses on the semantically important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Use this when the user asks for recent public AI crypto trading signals, optionally filtered by coin, importance, or pagination.' It includes specific filter dimensions and is distinguishable from sibling tools like get_signal_details and get_signal_stats by referring to 'public AI crypto trading signals'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this when the user asks for recent public AI crypto trading signals...' It also provides a critical exclusion/edge case: when the user names a count, pass it as `limit` to avoid over-fetching, since 'the card view renders exactly what was fetched'. This behavior is unique to this tool and not covered by siblings, making the guidance highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for aggregate AI signal performance statistics over a specific period.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for statistics | 24h |
| Name | Required | Description |
|---|---|---|
| total | No | Signals published in the period |
| pending | No | Still open at the end of the period |
| stopped | No | |
| winRate | No | targetHits / resolved, as a percentage; null when nothing resolved |
| highCount | No | High-importance signals |
| targetHits | No | Signals that reached a take-profit or locked profit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'aggregate' and 'over a specific period' scoping, which is useful. However, it doesn't mention any additional behavioral details such as return format aggregation level, or performance implications. Given the annotations cover the safety profile, the description adds modest value beyond the structured data, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the usage trigger. It earns its place by providing the primary use case. It could have been slightly more explicit about the output being aggregates, but it's efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional parameter with enum), full schema coverage, and presence of an output schema, the description is sufficient to complete the tool's documentation. The output schema likely explains the return structure, so the description doesn't need to. The only minor gap is explicit differentiation from get_signal_details, but overall the tool is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'period' is fully documented with enum and default). The description mentions 'specific period' but doesn't add format or usage details beyond the schema. The baseline for full coverage is 3, and the description doesn't meaningfully exceed it. The parameter is simple and self-explanatory from the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving aggregate AI signal performance statistics for a specific period. It uses a specific verb-resource combination ('get ... signal performance statistics') and is distinguishable from siblings like get_signal_details (which likely returns individual signal details) and get_signals (which likely lists signals). However, it doesn't explicitly name a sibling alternative when to use another tool, so it doesn't maximize differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with explicit guidance: 'Use this when the user asks for aggregate AI signal performance statistics over a specific period.' This clearly tells the agent the trigger condition. It doesn't specify when not to use it or name alternatives like get_signal_details for individual signals, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading pair symbol, e.g. BTCUSDT | |
| history | No | Prior values returned per indicator as `series` (oldest → newest, length history + 1). 0 = latest only. | |
| periods | No | Optional period overrides, e.g. {"ema":[9,21,55,200],"rsi":7} | |
| interval | No | Candle timeframe. Ignored when `intervals` is given. | 1h |
| intervals | No | 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. | |
| indicators | No | Indicators to compute. `levels` = swing support/resistance from price structure, `pivots` = classic floor pivots from the previous day. |
| Name | Required | Description |
|---|---|---|
| price | No | Latest close on the primary timeframe, or null when no candles are stored |
| symbol | No | |
| candles | No | Closed candles the primary timeframe was computed on |
| summary | No | Single-timeframe call only: bias, score, trend, momentum, volatility, volume, notes[]. Omitted when `timeframes` is present. |
| interval | No | Primary timeframe (the first requested one) |
| settings | No | Echo of what was computed: indicators, history, resolved periods |
| warnings | No | |
| confluence | No | Multi-timeframe agreement: { aligned, bias, byInterval } |
| indicators | No | 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: "insufficient_data" } when the tape is too short. Omitted when `timeframes` is present — read them there. |
| timeframes | No | 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. |
| lastCandleOpenTime | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description further details the return shape (current value, previous bar, rising/falling/flat direction, series history, zones/crossovers) and the multi-timeframe behavior producing a `confluence` verdict and per-timeframe `summary`. This meaningfully extends the annotation-only picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-arranged: purpose front-loaded, then return format, then parameter flexibility, then multi-timeframe guidance. Every sentence carries information, though the 19-indicator enumeration could arguably be compressed since the schema also lists them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 indicators, 6 params, and nested objects, the description covers return structure, period overrides, multi-timeframe behavior, and interpretation guidance (quote summary notes). An output schema exists, so return-value details needn't be in the description; what's present is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining that EMA/SMA accept multiple periods at once (default 20/50/200), that every period is overridable via `periods`, and that `intervals` yields a multi-timeframe confluence result in one quota-efficient call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Technical analysis for a crypto futures symbol') and enumerates 19 concrete indicators, from RSI/MACD to swing levels. An agent can immediately understand what this tool computes and how it differs from siblings like get_price or get_candles, which handle raw prices rather than analyzed indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers clear usage context: using `intervals` gets multiple timeframes in one call with a confluence verdict, and instructs the agent to 'quote its notes rather than the raw score' for the per-timeframe summary. However, it stops short of explicitly naming sibling alternatives or stating when NOT to use this tool versus get_price/get_candles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants ranked smart-money traders across supported exchanges with sorting and filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of traders to return | |
| order | No | Sort direction | DESC |
| sortBy | No | Sort metric (defaults to ranking type) | |
| source | No | Exchange to filter by | all |
| timeRange | No | Performance time range | 30D |
| rankingType | No | Ranking snapshot type | ROI |
| Name | Required | Description |
|---|---|---|
| data | No | Ranked traders: source, topTraderId, traderName, roi, pnl, winRate, smartScore, rank, rankings[] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no behavioral details beyond what annotations provide, but it doesn't contradict them. With annotations present, a baseline of 3 is appropriate; the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the purpose and usage in a compact way. No fluff, no redundancy, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return details are covered. The description covers the core use case with sorting/filtering mentioned. It's complete enough for a straightforward read-only query tool, though it could optionally note the ranking types or exchange scope, but these are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters fully documented including enums, defaults, and descriptions. The description itself adds no parameter details beyond what's in the schema, so baseline 3 is correct. It doesn't compensate further but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns ranked smart-money traders with sorting and filtering, which is a specific verb+resource. It distinguishes from siblings like get_elite_leaderboard by focusing on 'smart-money traders' and 'sorting and filtering', but it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition ('Use this when the user wants ranked smart-money traders...'), which is clear usage context. However, it doesn't provide when-not-to-use guidance or explicitly mention alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all crypto futures symbols currently tracked by TraderSpy with real-time candle data available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | |
| symbols | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that symbols are 'currently tracked' and have 'real-time candle data available,' which indicates the data is live and relevant to candle-related tools. This adds value beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's function. It is front-loaded with the verb and resource, and contains no unnecessary words or redundant information. Perfectly appropriate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description fully covers what the agent needs to know: that it lists tracked symbols with real-time candle data. The sibling tools are distinct, and the output schema handles return values. The description is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any. Per the rubric, with 0 params the baseline is 4. The description adds no parameter specifics, but none are needed since the schema is empty and schema description coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'List all crypto futures symbols currently tracked by TraderSpy with real-time candle data available.' It uses a specific verb (list) and resource (crypto futures symbols), and adds a distinguishing qualifier (tracked by TraderSpy, real-time candle data). This differentiates it from sibling tools like get_candles or get_price, which focus on specific symbols or data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need an overview of tracked symbols, but it does not explicitly mention when to use this tool instead of alternatives like get_candles or get_market_stats. No exclusions or alternative recommendations are provided. The one-sentence description gives context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for closed trade history of a specific trader.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| source | No | Exchange | binance |
| traderId | Yes | The trader ID |
| Name | Required | Description |
|---|---|---|
| data | No | Closed positions, most recently closed first |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering most safety-relevant behavior. The description adds minimal behavioral context beyond the 'closed' trade history distinction, so it does not significantly enhance transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. It states the exact trigger and scope efficiently, making it easy for an agent to quickly understand applicability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive input schema with 100% description coverage, output schema, and safety annotations, the single-sentence description is largely sufficient for a straightforward read-only paginated endpoint. It lacks explicit mention of pagination or ordering, but these are adequately covered by the structured schema data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the input schema, including the meaning of traderId, page, limit, and source exchange. The description itself adds no parameter-level details, so the schema carries the full burden; the high schema coverage supports the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for retrieving closed trade history for a specific trader, providing a clear resource and scope. It distinguishes itself from sibling tools like get_positions (open positions) and get_trader_profile, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this when...' gives clear contextual guidance for when to invoke the tool (closed trade history of a specific trader). It does not provide explicit exclusions or alternatives, but the context is specific enough to discourage misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs one trader profile, including metrics and latest positions.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Exchange the trader is on | binance |
| traderId | Yes | The trader ID | |
| timeRange | No | Performance time range | 30D |
| rankingType | No | Ranking snapshot type | ROI |
| Name | Required | Description |
|---|---|---|
| aum | No | |
| mdd | No | Maximum drawdown |
| pnl | No | |
| roi | No | |
| rank | No | |
| source | No | |
| winRate | No | |
| avatarUrl | No | |
| positions | No | Currently tracked positions |
| timeRange | No | |
| smartScore | No | |
| traderName | No | |
| rankingType | No | |
| topTraderId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scoping context ('metrics and latest positions') but doesn't go beyond what the annotations and output schema already convey. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It efficiently communicates both the trigger condition and the tool's primary output scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, rich output schema, and strong annotations, the description is adequate and complete for selection. It could optionally note the relationship to get_trader_position_history, but that sibling already appears in the tool list and the description still covers key information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all four parameters, so coverage is 100%. The description does not add extra parameter semantics, merely echoing the general content (metrics and positions) without detailing how parameters map to results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving a single trader profile including metrics and latest positions. The phrase 'one trader profile' distinguishes it from sibling list/leaderboard tools like get_top_traders and get_elite_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with 'Use this when the user needs one trader profile,' providing an explicit usage context. However, it does not mention exclusions or directly name alternative tools for other scenarios, so it falls just short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return | |
| sortBy | No | volume (24h quote volume), change24h, or metric (the first condition's metric). Default: metric when conditions are given, else volume. | |
| symbols | No | 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. | |
| interval | No | Candle timeframe to evaluate on | 4h |
| universe | No | How many of the most-traded symbols (by 24h volume) to scan when `symbols` is omitted (max 100) | |
| sortOrder | No | desc | |
| conditions | No | 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":"emaSpread","op":"crossAbove","value":0,"period":50,"period2":200}; MACD bullish cross = {"metric":"macdHistogram","op":"crossAbove","value":0}; dumped 5% in a day = {"metric":"changePct","op":"lt","value":-5,"period":24}. |
| Name | Required | Description |
|---|---|---|
| sortBy | No | |
| matched | No | Symbols satisfying every condition (all scanned symbols when no conditions) |
| results | No | One row per matching symbol: { symbol, price, change24hPct, volume24hUsd, values { "<metric label>": value }, bias, trend, rsi14, adx14, atrPct, volumeRatio, squeeze } |
| interval | No | |
| returned | No | |
| universe | No | { source: top_by_volume | explicit, requested, scanned, missing[] } |
| warnings | No | |
| sortOrder | No | |
| conditions | No | Human-readable conditions, e.g. "RSI(14) < 30" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior, so the description's job is lighter. It adds useful behavioral context: scans top symbols by 24h volume with a default of 50 and max of 100, 'ONE quota unit however many symbols', and a description of what each row carries. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense paragraph, but every sentence carries distinct information: purpose/examples, condition syntax, universe and row contents, comparison mode, and quota/alternative. It is front-loaded with the core purpose and not bloated, though it could be broken into clearer sentences or bullets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested conditions, metric options), the description covers the essential operational aspects: both usage modes, default universe, row contents, quota cost, and the preferred alternative. The output schema and annotations fill the remaining details such as sorting, limit, and safety, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (86%), so the baseline applies. The description largely restates what the schema already documents: the metric list, lt/gt/crossAbove/crossBelow operators, and the comparison-table behavior are all in the schema. It adds little new per-parameter meaning beyond what an agent would already see in the structured spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Screen MANY crypto futures symbols at once on one timeframe'. It further specifies the metric list, operators, and example queries, making the tool's purpose unmistakable. It also clearly differentiates from the sibling get_technical_indicators by emphasizing multi-symbol screening versus per-symbol loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative and gives a preference rule: 'always prefer this over calling get_technical_indicators in a loop'. It also defines when the comparison-table mode applies ('With NO conditions and explicit `symbols`'), giving agents clear conditions for selecting between modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
backtest_conditionscreen_symbolsget_derivativesget_technical_indicators3 fields changedOutput schema / properties / indicators / descriptionPrevious value: -"Requested indicators keyed by name (primary timeframe). Each carries value, previous, direction, series and indicator-specific fields (zone, crossover, stack, levels…); { value: null, reason: \"insufficient_data\" } when the tape is too short."New value: +"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: \"insufficient_data\" } when the tape is too short. Omitted when `timeframes` is present — read them there."Output schema / properties / summary / descriptionPrevious value: -"Interpretation layer: bias, score, trend, momentum, volatility, volume, notes[]"New value: +"Single-timeframe call only: bias, score, trend, momentum, volatility, volume, notes[]. Omitted when `timeframes` is present."Output schema / properties / timeframes / descriptionPrevious value: -"Present when several intervals were requested: one { interval, price, indicators, summary } per timeframe"New value: +"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."get_technical_indicators17 fields changedInput schema / properties / historyAdded value: +{
+ "default": 5,
+ "description": "Prior values returned per indicator as `series` (oldest → newest, length history + 1). 0 = latest only.",
+ "maximum": 20,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / indicators / descriptionPrevious value: -"Technical indicators to compute"New value: +"Indicators to compute. `levels` = swing support/resistance from price structure, `pivots` = classic floor pivots from the previous day."Input schema / properties / indicators / items / enumPrevious value: -[
- "rsi",
- "macd",
- "ema",
- "sma",
- "bollinger",
- "atr",
- "adx",
- "stochastic",
- "obv",
- "vwap",
- "cci",
- "mfi",
- "williamsR"
-]New value: +[
+ "rsi",
+ "macd",
+ "ema",
+ "sma",
+ "bollinger",
+ "atr",
+ "adx",
+ "stochastic",
+ "obv",
+ "vwap",
+ "cci",
+ "mfi",
+ "williamsR",
+ "roc",
+ "supertrend",
+ "ichimoku",
+ "keltner",
+ "pivots",
+ "levels"
+]Input schema / properties / indicators / maxItemsPrevious value: -13New value: +19Input schema / properties / interval / descriptionPrevious value: -"Candle interval/timeframe"New value: +"Candle timeframe. Ignored when `intervals` is given."Input schema / properties / intervalsAdded value: +{
+ "description": "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.",
+ "items": {
+ "enum": [
+ "1m",
+ "5m",
+ "15m",
+ "1h",
+ "4h",
+ "1d"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / periodsAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional period overrides, e.g. {\"ema\":[9,21,55,200],\"rsi\":7}",
+ "properties": {
+ "adx": {
+ "description": "ADX period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "atr": {
+ "description": "ATR period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "bollinger": {
+ "description": "Bollinger period (default 20)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "bollingerStdDev": {
+ "description": "Bollinger std-dev multiplier (default 2)",
+ "maximum": 5,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "cci": {
+ "description": "CCI period (default 20)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "ema": {
+ "description": "EMA periods, up to 4 (default [20, 50, 200])",
+ "items": {
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ "keltner": {
+ "description": "Keltner EMA period (default 20)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "keltnerAtr": {
+ "description": "Keltner ATR period (default 10)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "keltnerMultiplier": {
+ "description": "Keltner ATR multiplier (default 2)",
+ "maximum": 10,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "macdFast": {
+ "description": "MACD fast EMA (default 12)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "macdSignal": {
+ "description": "MACD signal EMA (default 9)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "macdSlow": {
+ "description": "MACD slow EMA (default 26)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "mfi": {
+ "description": "MFI period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "obv": {
+ "description": "OBV averaging window (default 20)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "roc": {
+ "description": "Rate-of-change period (default 12)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "rsi": {
+ "description": "RSI period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "sma": {
+ "description": "SMA periods, up to 4 (default [20, 50, 200])",
+ "items": {
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "maxItems": 4,
+ "minItems": 1,
+ "type": "array"
+ },
+ "stochastic": {
+ "description": "Stochastic %K period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "stochasticSignal": {
+ "description": "Stochastic %D smoothing (default 3)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "supertrend": {
+ "description": "SuperTrend ATR period (default 10)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "supertrendMultiplier": {
+ "description": "SuperTrend ATR multiplier (default 3)",
+ "maximum": 10,
+ "minimum": 0.5,
+ "type": "number"
+ },
+ "vwap": {
+ "description": "Rolling VWAP window in bars (default 48)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ },
+ "williamsR": {
+ "description": "Williams %R period (default 14)",
+ "maximum": 500,
+ "minimum": 2,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}Output schema / properties / candlesAdded value: +{
+ "description": "Closed candles the primary timeframe was computed on",
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / confluenceAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Multi-timeframe agreement: { aligned, bias, byInterval }"
+}Output schema / properties / indicators / descriptionPrevious value: -"Requested indicators keyed by name; shape differs per indicator"New value: +"Requested indicators keyed by name (primary timeframe). Each carries value, previous, direction, series and indicator-specific fields (zone, crossover, stack, levels…); { value: null, reason: \"insufficient_data\" } when the tape is too short."Output schema / properties / interval / descriptionAdded value: +"Primary timeframe (the first requested one)"Output schema / properties / lastCandleOpenTimeAdded value: +{
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "format": "date-time",
+ "type": "string"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / price / descriptionPrevious value: -"Latest close, or null when no candles are stored"New value: +"Latest close on the primary timeframe, or null when no candles are stored"Output schema / properties / settingsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Echo of what was computed: indicators, history, resolved periods"
+}Output schema / properties / summaryAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Interpretation layer: bias, score, trend, momentum, volatility, volume, notes[]"
+}Output schema / properties / timeframesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present when several intervals were requested: one { interval, price, indicators, summary } per timeframe"
+}Output schema / properties / warningsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}get_my_account1 field changedOutput schema / properties / trading / descriptionPrevious value: -"Whether agent trading is enabled, plus the server-side caps that apply"New value: +"Connector capabilities: read-only. States that this connector cannot place orders or withdraw, and where the user trades instead"get_candlesget_elite_leaderboardget_exchangesget_market_statsget_my_accountget_positionsget_priceget_signal_detailsget_signal_statsget_signalsget_technical_indicatorsget_top_tradersget_tracked_symbolsget_trader_position_historyget_trader_profile
