TraderSpy

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 need not repeat these. The description adds the context of 'crypto futures symbol' which is helpful, but does not disclose additional behavioral details such as sorting order, pagination, or timezone handling. With annotations covering the safety profile, this is adequate but not rich.

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 core purpose ('Get OHLCV candle data') followed by a brief use case. Every word earns its place with no filler or redundancy.

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, the presence of a detailed output schema, and strong parameter documentation, the description is sufficient for an agent to understand what to expect. It clarifies the trading context (crypto futures) and typical use cases. While it could mention default intervals or limit behavior, these are already defined in the schema, so the description does not need to repeat them.

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 input schema has 100% description coverage for all parameters (symbol, interval, limit), so the schema already documents their meaning. The description adds the context of 'crypto futures' which is marginal but not essential. Per the rubric, a baseline of 3 is appropriate when schema coverage is high and description adds little extra.

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 retrieves OHLCV candle data for crypto futures symbols, specifying the resource (candles) and the format (OHLCV). It does not explicitly differentiate from siblings like get_price or get_technical_indicators, but the focus on candle data distinguishes it enough. The mention of charting and technical analysis adds context without explicit alternative references.

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 context on when to use the tool ('charting, price history, and technical analysis') but does not explicitly state when not to use it or mention alternative tools. No exclusions or pointers to get_price or get_technical_indicators are given, so the guidance is implied rather than explicit.

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

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

The annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, establishing a safe read operation. The description adds minimal incremental behavioral context (the SmartScore scoping) but doesn't disclose return semantics or the meaning of 'elite'; the annotations carry the transparency load.

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 16-word sentence that immediately tells the agent when to fire, with zero filler or restatement of the tool name. 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?

For a 0-parameter, read-only lookup with a provided output schema, the description covers the essentials. It could arguably have clarified what qualifies as 'elite,' but the low complexity and strong annotations make the description sufficient.

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 trivially 100% schema description coverage, so there is nothing for the description to clarify. Per the rubric, zero-parameter tools receive a baseline of 4, and the description makes no errors or omissions.

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 purpose with a specific resource ('elite leaderboard by SmartScore across exchanges') and references the get action. It effectively differentiates from sibling tools like get_top_traders and get_signals by naming the exact data domain and filter.

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 the user specifically asks' provides clear usage context and implies the tool should not be used for other leaderboard types ('by SmartScore'). However, it stops short of explicitly naming alternatives or exclusions—e.g., it could have noted 'for other rankings, use get_top_traders'—which keeps this at a 3.

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

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 minimal behavioral context ('currently available' implies a live query) but does not disclose return format, limitations, or other behavioral traits. With annotations present, this meets the baseline.

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 directly states when to use the tool. No wasted words or redundant information.

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, read-only tool with an output schema, the description is sufficient. It covers the trigger condition and the resource. It does not enumerate return fields, but the output schema likely covers that. Minor gap: no mention of output format or any caveats, but not critical for such a simple 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 tool has zero parameters, so schema coverage is 100% by default. The description does not need to explain parameters. Baseline for 0 parameters is 4, and there is no missing parameter information.

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: to get exchanges currently available in TraderSpy smart-money tracking. It uses a specific verb ('get') and resource ('exchanges'), and the context 'currently available' distinguishes it from static reference 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 explicitly tells the agent when to use this tool: 'when the user asks which exchanges are currently available.' It does not explicitly exclude alternatives or mention sibling tools, but the context is clear enough for a simple list endpoint.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the return content (positions, PNL, win rate) and optional scoping, which goes beyond the annotations. There's no contradiction, and the read-only behavior is consistent. It would earn a 5 if it mentioned potential edge cases or data ranges, but it's solidly above baseline.

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 zero waste. It immediately states when to use the tool and what it returns, followed by optional scoping. 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?

For a simple, read-only aggregate tool with a rich output schema, two well-documented parameters, and comprehensive annotations, the description is entirely sufficient. It covers purpose, scope, and usage without redundancy, and the output schema handles return-value expectations.

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%, and both parameters (period and source) have adequate descriptions. The tool description only says 'optionally scoped by source and period,' which merely restates what the schema already conveys. It adds minimal extra meaning, so the baseline of 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 provides aggregate market stats (positions, PNL, win rate) and mentions optional scoping by source and period. This is specific and uses a clear verb+resource pattern. However, it does not explicitly differentiate from sibling tools like get_signal_stats or get_positions, which could overlap, so it stops short of a 5.

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 the user asks for aggregate market stats' directly tells the agent when to invoke this tool, providing clear context. It doesn't specify exclusions or point to alternative tools, so it lacks the when-not guidance needed for a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds concrete value by specifying what the tool cannot do (place, close, or modify orders, withdraw) and the required connection, which is beyond annotation coverage. 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?

Two sentences, front-loaded with the primary usage condition, then supplemental constraints. Every sentence contributes useful information with no redundancy or filler.

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), the presence of an output schema (so return format is covered), and clear usage/constraint statements, the description is complete. It covers when to use, limitations, and prerequisites, leaving no significant gaps.

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 is the sole source of behavioral context. It clearly describes the account attributes covered (balance, positions, PnL, paper-trading), which is sufficient for an empty schema. Given no parameters, baseline 4 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 clearly states it retrieves the user's own TraderSpy account details (balance, positions, PnL, paper-trading), with the verb 'get' and resource 'my account'. It distinguishes itself from sibling tools like get_positions and get_trader_profile by emphasizing 'THEIR OWN' account, making it 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?

Explicitly instructs when to use: 'Use this when the user asks about THEIR OWN TraderSpy account.' It also provides constraints (read-only, cannot place/modify orders, cannot withdraw) and a prerequisite (personal MCP connection), leaving no doubt about appropriate invocation.

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

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 well established. The description adds the scope of 'current or historical' and mentions filter options, but it does not disclose response ordering, pagination behavior beyond schema, or any other operational details. For a read-only tool with strong annotations, this is adequate but not rich.

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 communicates the purpose and key features without any fluff. It is front-loaded with the trigger condition and immediately conveys the core functionality.

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 that an output schema exists and the input schema covers all parameters, the description provides sufficient context for an agent to invoke the tool correctly. It explains the purpose and typical use case. It could be slightly improved by pointing to an alternative for retrieving positions of a specific trader, but that is not essential for completeness.

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%, and each parameter (limit, offset, source, status, symbol) has a clear description in the schema. The tool description simply mentions that filtering by status, source, or symbol is optional, which aligns with the schema but does not add new meaning beyond it. 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 returns smart-money positions (current or historical) with optional filters for status, source, or symbol. It uses a specific verb (get) and resource (positions), and the mention of filters distinguishes it from other tools like get_trader_position_history or get_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 explicitly states when to use it ('when the user asks for current or historical smart-money positions'), providing clear context. It does not mention any exclusions or alternatives, but that is acceptable given the sibling tool names are quite distinct (e.g., get_trader_position_history for a specific trader).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it returns real-time data including specific fields, which is useful but doesn't go much beyond annotations. It could mention rate limits or that data is for futures symbols, but the annotations carry the safety burden, so adds a bit of value for the return 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 two sentences, front-loaded with the purpose and specific data fields. Zero wasted words, all info is relevant and valuable.

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 there's an output schema and good annotations, the description doesn't need to explain return values in detail. It explains the scope (real-time price data for futures symbols) and gives the key fields, which is sufficient for a simple read-only tool with one parameter. It's complete enough for the complexity.

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% and the parameter 'symbols' is well-described in the schema. The description does not add extra meaning about the symbols beyond what the schema provides—it just mentions 'one or more crypto futures symbols', which matches the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool gets real-time price data for crypto futures symbols, with a specific list of returned data (current price, 24h high/low, volume, 24h change). It distinguishes from siblings like get_candles and get_technical_indicators, which have different scopes.

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?

It states the tool is for getting real-time price data for one or more symbols, which implies it's the go-to for current price snapshots. It doesn't explicitly mention when not to use it or name alternatives, but the sibling list and clear purpose provide adequate context. Lacks explicit exclusions like 'use get_candles for historical data'.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add value beyond that. It adds 'including review and resolution data' — clarifying the return content — which is genuinely useful behavioral info about what the response covers. No contradiction with the annotations, and the description supplements rather than duplicates 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?

One well-formed sentence that front-loads the trigger condition ('Use this when...'), specifies the task, and clarifies response scope. Zero filler words, no repetition of schema data, maximum information density.

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 100% parameter schema coverage, full annotations (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), and an output schema present, the description's job is minimal. It correctly adds the 'including review and resolution data' detail that the schema doesn't convey. It could mention edge cases (e.g., invalid/nonexistent ID), but with the output schema and robust annotations, coverage is sufficient.

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% — the single 'signalId' parameter is fully documented in the schema with type and description. The description adds the 'full details... by ID' context and mentions 'review and resolution data' in the return, which loosely reinforces that signalId refers to a signal. Per the rubric, with coverage at 100%, the baseline is 3, and the description doesn't add parameter semantics beyond schema (which 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 verb ('Use this when the user needs'), the resource ('full details for one AI signal'), and the scope ('by ID, including review and resolution data'). 'One... by ID' explicitly distinguishes this from the plural get_signals sibling, and it precisely names the return-content focus via 'review and resolution 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 begins with 'Use this when the user needs...', which is an explicit usage-trigger instruction. The singular 'one AI signal by ID' implicitly contrasts with list-style siblings like get_signalsversus get_signal_stats, though it does not name the alternative directly. A named alternative would have made this a 5, but the 'Use this when' framing provides a clear decision rule.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds non-obvious behavior: the card view renders exactly what was fetched, so not passing a user-specified count as `limit` leads to over-fetching and displaying more cards than requested. This is valuable context beyond the annotations that affects invocation.

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, no fluff. The first sentence establishes purpose, the second delivers a critical usage tip with a rationale. 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?

For a read-only GET-like tool with four optional, well-documented parameters and an output schema, the description covers the essential aspects: when to use, what it does, and a significant edge-case instruction. No critical gaps are apparent given the available metadata.

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 significantly enhances understanding of the `limit` parameter by explaining the rendering consequence, which helps the agent correctly translate user requests like 'last 5 signals' into a `limit` argument. No such addition is made for other parameters, but the coverage is already strong.

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 it returns recent public AI crypto trading signals with filters for coin, importance, and pagination. This distinguishes it from sibling tools like get_signal_details by focusing on 'recent public' signals and listing specific filter dimensions.

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 opening phrase 'Use this when the user asks for recent public AI crypto trading signals' explicitly indicates when the tool is appropriate. However, it does not mention when not to use it or suggest any alternative tools, though this is a minor gap given the clear context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it provides aggregate statistics over a period, which is useful but doesn't go beyond the annotation's safety profile. There's no contradiction, but the description doesn't add significant behavioral context beyond what annotations already imply, such as whether results are cached or computation occurs.

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, short sentence that is front-loaded with the key purpose. It's concise and contains no waste, though it could have included a bit more specificity about what 'aggregate statistics' includes.

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 is simple (one parameter, no required fields, output schema exists), and the description adequately covers the purpose. With rich annotations and an output schema, the description doesn't need to explain return values or structures. It's mostly complete, though a bit more detail on what metrics are included could help.

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% for the single 'period' parameter, with a clear description and enum values. The description itself doesn't add parameter-level details, but the schema fully covers it. Baseline 3 is appropriate since the schema handles the parameter semantics.

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 it provides aggregate AI signal performance statistics over a specific period, using specific verb (get) and resource (signal performance statistics). It's distinguishable from siblings like get_signal_details (which likely returns individual signal details) and get_market_stats (market-wide stats), though it doesn't explicitly differentiate.

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 a clear when-to-use context ('when the user asks for aggregate AI signal performance statistics over a specific period'). However, it doesn't explicitly mention alternatives or when not to use this tool, so it lacks exclusionary guidance that would help differentiate from other statistics tools.

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

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 that it computes indicators but does not mention potential rate limits, data availability, or that it might use historical candles. 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 sentence that is concise and front-loaded with the verb 'Compute'. It lists the main indicators and the key inputs (symbol, timeframe), providing no superfluous information. Every word adds value.

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 moderate complexity (13 indicators, output schema present), the description is adequate but could mention that the agent can request any subset via the 'indicators' parameter. However, the output schema likely clarifies the return format, so this is not a major gap. Slightly incomplete regarding when to use it relative to get_candles.

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%, providing descriptions for all three parameters. The description adds no new parameter information, but the schema already documents symbol, interval, and indicators thoroughly, including enums and defaults. Therefore, the description adds little but does not detract.

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 computes technical indicators for a crypto futures symbol at a specific timeframe, listing the supported indicators. It distinguishes itself from siblings like get_candles (which fetches raw candle data) and get_price (current price), though it does not 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 implies the tool is for computing indicators on historical price data, but does not state when to use it versus get_candles (which might be needed for raw data) or how it relates to other market data tools. No explicit guidance on prerequisites or alternatives.

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

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 context about ranking/filtering but does not disclose additional behavioral traits such as pagination, data freshness, or exchange-specific quirks. There is no contradiction with 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, front-loaded sentence that immediately states the use case and primary capabilities. Every word earns its place, with no repetition of the tool name or schema content.

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 no required parameters, a rich input schema, strong annotations, and an output schema, so the description does not need to explain return values. The main gap is the lack of explicit differentiation from get_elite_leaderboard, which may be an equally relevant option for similar user requests.

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%, and each of the 6 parameters has clear descriptions, enums, and defaults. The description's phrase 'sorting and filtering' broadly maps to parameters like sortBy, order, and source, but it adds no parameter-level detail beyond what the schema already provides.

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 what the tool returns ('ranked smart-money traders across supported exchanges') and highlights its key capabilities ('sorting and filtering'). However, it does not explicitly distinguish itself from the closely related sibling tool get_elite_leaderboard, so it does not fully earn the top score.

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 usage trigger: 'Use this when the user wants ranked smart-money traders...' This gives the agent solid context for when to select the tool. It does not mention when not to use it or point to a specific alternative, which would have made it a 5.

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

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the important scope 'closed trade history' but does not disclose pagination behavior, result ordering, or any potential data freshness limitations. With annotations, this is an average but acceptable 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, front-loaded sentence that directly states the use case. There is no redundant phrasing, filler, or unnecessary repetition of information.

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 full parameter documentation, clear annotations for identity and safety, and an output schema present, the description adequately complements the structured data. The use-case sentence is sufficient for an agent to competently decide and call this 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 description coverage is 100%, with each parameter already clearly described ('traderId', 'page', 'limit', 'source'). The description does not add any parameter-level nuance beyond the structured schema, so it does not elevate above the baseline.

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's purpose as retrieving closed trade history for a specific trader, which distinguishes it from siblings like get_positions or get_trader_profile. It lacks an explicit verb such as 'get' or 'returns', but the use-case phrasing makes the intent 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 explicitly states when to use the tool: 'when the user asks for closed trade history of a specific trader.' This provides clear context for selection, though it does not mention alternatives or explicitly state when not to use it, such as for open positions.

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

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 scope context ('metrics and latest positions') but does not go deeper into behavior around missing traders, exchange-specific behavior, or data freshness, though the output schema likely covers return shape.

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 immediately tells the agent when to use the tool and what to expect from the result, making it highly efficient.

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 tool complexity, rich annotations, fully documented input schema, and presence of an output schema, this description is complete enough. It communicates the tool's singular purpose and primary result contents without needing to restate the structured field details.

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%, and each parameter already has meaningful descriptions, enums, and defaults. The tool description does not add any extra parameter-level semantic value beyond what the schema provides, so the baseline score of 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 identifies the resource as 'one trader profile' and states it includes metrics and latest positions. The singular framing distinguishes it from sibling tools like get_top_traders and get_elite_leaderboard, and 'latest positions' helps separate it from get_trader_position_history.

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 explicitly says 'Use this when the user needs one trader profile...', providing a clear trigger condition. However, it does not mention alternatives or when not to use this tool, such as when only positions or historical positions are needed.

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