TraderSpy

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

Annotations already declare readOnlyHint=true/idempotent, so safety is covered; the description goes well beyond by disclosing the data tape limit (up to 1000 candles, with the concrete ~41d/166d/3y implication per interval) and the statistical caveat that a 3-sample stat is an anecdote. That is exactly the operational context an agent needs before quoting 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?

Opening sentence is strongly front-loaded with purpose and examples, and the closing instruction to quote edge alongside sample size is high-value. It is a dense single block rather than a leaky one, though the enumeration of return statistics overlaps with the output schema and could be trimmed.

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 4-parameter analytics tool with a full output schema and read-only annotations, the definition still covers the things structured fields cannot convey: the stored tape length per interval, the AND-ed multi-condition model, metrics in their own units, and the sample-size caveat. Nothing needed to invoke or interpret 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% — periods, defaults, enum semantics and the condition examples are all already documented in the schema. The description adds only the cross-reference that the condition vocabulary matches screen_symbols, which is mildly useful but does not deepen parameter meaning, so the 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 states a specific verb+resource (event-study backtest of a condition on one symbol/timeframe) and immediately anchors it with three concrete example questions. It also positions itself against the sibling screen_symbols by noting the shared condition vocabulary, so an agent can tell the two apart without opening either schema.

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 'what happened AFTER a condition in the past' framing plus the three example questions make the intended use case unambiguous. However, it never states when to avoid this tool (e.g. conditions with too few occurrences) or explicitly names screen_symbols as the alternative for the forward-looking counterpart, so the guidance is clear but not exhaustive.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without prose. The description adds no behavioral context beyond that — nothing about default interval/limit behavior, result ordering, or what happens when limit exceeds the maximum of 500 — so it contributes little beyond the structured fields.

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 filler: the resource and its expansion come first, then the use cases. Every clause earns its place and nothing is buried.

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 an output schema present, a fully described parameter set, and complete annotations, the description only needs to establish purpose, which it does. The one small gap is that it gives no hint of sibling routing for related price or indicator queries, but nothing required to call the tool 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 symbol, interval (enum with defaults), and limit (1–500, default 100) all documented inline, so the baseline of 3 applies. The description adds nothing about symbol format or interval semantics that the schema does not already carry.

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 — retrieve OHLCV candle data for a crypto futures symbol — and spells out what OHLCV means, so an agent knows exactly what kind of payload to expect. It is clearly distinct in kind from siblings like get_price or get_technical_indicators, though it never explicitly names them to reinforce the boundary.

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 offers implicit usage context ('charting, price history, and technical analysis') but gives no when-to-use versus when-not rules and does not point to get_price or get_technical_indicators as alternatives for related needs. An agent can infer a use case but must decide on its own when this beats a sibling.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds genuinely new operational context: a 60-second data freshness window and a hard batching ceiling of 5 symbols per call. It also instructs the agent to quote the plain-language per-symbol notes, which is behavioral guidance the annotations cannot supply. It does not detail auth or rate-limit behavior, keeping it just below the top.

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?

Front-loaded with the resource and scope, then the differentiating question-set. Dense but every clause earns its place; only the closing 'up to 5 symbols per call' is redundant with the schema.

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?

An output schema exists, so return values needn't be spelled out, yet the description still explains the OI×price regime taxonomy and the top-trader/taker-flow breakdown, which materially helps interpretation. Combined with the freshness and batching facts, an agent has everything needed to call it correctly; the only mild gap is unstated alternatives.

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 schema already documents the symbols array (max 5) and the bare-base-asset fallback ('BTC' → USDT perpetual). The description's 'up to 5 symbols per call' merely restates maxItems, adding no new syntax or format meaning, so the 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?

States a precise verb and resource — funding rate, open interest, and positioning for Binance USDⓈ-M perpetual futures — and explicitly carves out its territory against a named sibling ('the derivatives questions candles cannot answer'), so an agent can route between get_derivatives and get_candles without reading either schema.

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 framing 'the derivatives questions candles cannot answer' plus the enumerated use cases (is funding high, is OI building or unwinding, which way accounts lean) tells the agent when this tool is the right pick. It stops short of naming the other alternatives (get_market_stats, get_technical_indicators) or stating exclusions, so it is clear context rather than explicit when/when-not routing.

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, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is fully covered structurally. The description contributes almost nothing beyond that — only the scoring metric (SmartScore) and cross-exchange scope, with no mention of freshness, ranking size, or refresh behavior.

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 short sentence with the usage condition front-loaded and no filler. It is efficient, though it spends its only sentence on routing rather than stating what the tool does outright.

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 an output schema present, return values need not be described, and zero parameters keep the call surface trivial. However, the description never defines what makes the leaderboard 'elite' or what entities it ranks, so an agent must open the output schema to resolve ambiguity about scope and contents.

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 zero parameters, so there is no parameter semantics burden; the baseline for a no-arg tool is 4. The description appropriately adds no parameter discussion.

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 names a specific resource (the elite leaderboard) and its ranking basis (SmartScore across exchanges), so the agent knows what will be returned. It does not distinguish this tool from related siblings such as get_top_traders or get_signals, leaving overlap unresolved.

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 gives an explicit trigger — 'when the user specifically asks for the elite leaderboard' — which implies the tool is user-driven rather than proactive. Beyond that trigger, it names no alternative, no exclusion, and no conditions under which a different leaderboard/trader tool should be chosen instead.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only additional context is the TraderSpy smart-money scope, which is modest added value rather than behavioral disclosure about auth, limits, or freshness.

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 sentence, front-loaded with the usage trigger, with no redundant restatement of the tool name or title. Every clause 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?

With an output schema present, the description need not describe return values, and the rich annotations cover safety. For a zero-param read tool the trigger-plus-scope statement is nearly sufficient, though it could note what the exchange list is used for downstream.

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 takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool applies. The description correctly makes no claims about arguments it does not have.

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 the resource precisely ('which exchanges are currently available in TraderSpy smart-money tracking'), so an agent knows this returns the set of tracked exchanges. It does not explicitly contrast with the similar-sounding sibling get_tracked_symbols, but the domain qualifier 'smart-money tracking' is enough to distinguish scope.

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 a clear user-intent trigger ('when the user asks which exchanges are currently available'), which is a usable routing rule. It stops short of naming alternatives or when-not-to-use conditions, so it falls below the explicit-alternatives bar.

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 readOnly, idempotent, non-destructive, and non-open-world, so the safety profile is covered. The description only adds that the stats are 'aggregate' and scope-able, with no detail on what aggregation window or entity the figures cover, so it adds modest value.

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 tight sentence with the trigger front-loaded and the scope qualifier trailing. No wasted clauses, though the framing as a user-question trigger is slightly indirect.

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 an output schema present, return values need not be explained, and annotations carry the safety profile. The description is adequate for a 2-parameter, zero-required read tool, though it could say more about what 'aggregate' spans.

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 both parameters documented and enumerated. The description's note that results are 'optionally scoped by source and period' restates optionality already visible in the schema, adding little beyond 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?

States a specific verb+resource (aggregate market stats) and enumerates the concrete contents (positions, PNL, win rate). It does not differentiate from the close sibling get_signal_stats, so an agent must still infer which 'stats' tool applies.

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?

Gives a clear triggering condition ('when the user asks for aggregate market stats') with concrete examples of the metrics. However, it names no alternative or exclusion, so the agent gets no routing guidance against siblings like get_signal_stats or get_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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the filtering capabilities but says nothing about pagination behavior, default limits, or result ordering — gaps the annotations don't fill.

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 well-formed sentence with the usage cue front-loaded and no filler. It is appropriately sized for a simple read tool, though it stops short of the crispness of an ideal one-liner.

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 a full output schema, complete parameter descriptions, and annotations covering the safety profile, the description only needs to establish purpose and trigger. It does that, though the lack of any sibling disambiguation leaves a small completeness gap.

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%, so every parameter including the enums and the symbol format example is already documented inline. The description only echoes the filterable fields (status, source, symbol) without adding format or default guidance beyond the schema, so 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 names a specific resource (smart-money positions) and scope (current or historical), which is clearer than a generic 'get positions'. It does not, however, distinguish itself from nearby siblings like get_trader_position_history or get_top_traders, so an agent must infer the boundary.

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...' gives an explicit triggering context, which is better than most definitions. It offers no exclusions or alternative tools for adjacent needs (e.g., per-trader history), leaving the agent to infer when another tool is more appropriate.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that it returns a live snapshot for one or more symbols, but says nothing about latency, rate limits, staleness, or behavior when a symbol is unknown. No contradiction with 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?

Two sentences, both front-loaded and information-dense: the first gives scope, the second enumerates the returned fields. Nothing is padded or redundant.

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 rich annotations and an output schema present, the description needs only scope and payload summary, which it provides. It is essentially complete for a simple read tool, missing only sibling differentiation and any rate/limit caveat.

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 the single 'symbols' parameter is fully documented in the schema with an example and min/maxItems. The description's phrase 'one or more crypto futures symbols' only restates the array nature, adding no format, naming-convention, or batching guidance beyond the schema. 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?

States a specific verb and resource: 'Get real-time price data for one or more crypto futures symbols', plus the payload contents. This is clearly distinguishable from a generic fetch, but it never names or contrasts with siblings like get_candles (historical) or get_market_stats (aggregate), so an agent must infer the boundary from the word 'real-time' alone.

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?

Usage is only implied: 'real-time price data' suggests a live snapshot rather than historical series, which is a weak signal against get_candles. There is no explicit when-to-use, when-not-to-use, or named alternative, and no note on batching limits or appropriate call frequency.

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 fully covered by structured data. The description adds that the payload includes 'review and resolution data', which is useful context beyond the annotations, but it does not cover error cases, permissions, or lookup-miss behavior.

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 front-loaded sentence beginning with 'Use this when...' with no redundant or filler content. Every clause 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?

An output schema exists, so return values need not be described, and the single parameter is fully covered by the schema. The description is sufficient for correct invocation, though it could note the list-vs-detail choice more explicitly given the many sibling tools.

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 there is a single required 'signalId' parameter whose type and meaning are fully documented in the schema. The description adds no format or sourcing detail beyond what the schema already provides, so the baseline of 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?

States a specific verb and resource: retrieves full details for a single AI signal by ID, and the phrase 'one AI signal' implicitly distinguishes it from the sibling list tool get_signals. It does not name a sibling explicitly, so it falls just short of 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?

'Use this when the user needs full details for one AI signal by ID' gives a clear triggering condition tied to a single-ID lookup. It offers no explicit when-not guidance or named alternatives (e.g., get_signals for lists), so it is clear but not exhaustive.

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?

With annotations already covering read-only, idempotent, non-destructive and closed-world behavior, the description earns credit by adding a non-obvious rendering trait: the card view shows exactly what was fetched, so over-fetching surfaces extra cards. It does not address rate limits or default result size (schema does), but the UI-side effect is genuine value beyond structured fields.

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 filler. The activation condition is front-loaded and the higher-stakes subtlety (over-fetching in the card view) is placed immediately after the parameter it governs.

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?

An output schema exists, so return values need no explanation, and all five parameters are documented in-schema. The description covers triggering, filters, and the count-handling quirk, leaving only minor gaps such as pagination interaction with `skip`.

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 baseline is 3; the description goes beyond by explaining that `strategy` matches a preset name (words in order) and by prescribing the `limit` semantics for explicit user counts. That said, it repeats some schema content rather than adding syntax for `coin` or `importance`.

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 and resource ('recent public AI crypto trading signals') and enumerates the filterable dimensions, so an agent can distinguish it from singular-lookup siblings like get_signal_details or aggregate siblings like get_signal_stats. It stops short of explicitly naming what it is not, so it does not reach the sibling-exclusion standard 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?

Opens with an explicit trigger ('Use this when the user asks for recent public AI crypto trading signals') and gives concrete guidance for the count case ('last 5 signals' → pass as `limit`). It offers no when-not conditions, but the usage context is clear and actionable.

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 establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does: the response includes a per-strategy breakdown (byStrategy), and that breakdown can be exploited to discover valid strategy names for get_signals — genuinely useful behavior not conveyed by annotations or schema.

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 with no filler, front-loading the trigger condition before the secondary routing tip. Every clause earns its place, including the pointer to get_signals.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. With full schema coverage plus an explicit use trigger and a sibling routing tip, an agent has everything needed to select and invoke this tool 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 coverage is 100% and both parameters are documented in the schema (including the partial, case-insensitive strategy matching and the period enum), so the schema carries the parameter burden. The description restates that filtering can be overall or by strategy name but adds no syntax or format detail beyond the schema — 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?

States a specific verb and resource ('aggregate AI signal performance statistics') plus the scoping options (overall or one strategy by name), which cleanly separates it from the sibling get_signals that returns raw signals. The cross-reference to get_signals for strategy names further disambiguates the pair.

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?

Opens with an explicit triggering condition ('Use this when the user asks for aggregate AI signal performance statistics over a specific period'), which is strong when-to-use guidance. It implies but never states the inverse exclusion (e.g. don't use this to fetch individual signals), so it falls short of a full when/when-not/alternatives statement.

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 establish read-only, idempotent, non-destructive behavior, and the description adds genuinely non-obvious context on top: quota-unit consumption ('ONE call and one quota unit'), the multi-timeframe `confluence` verdict, per-indicator return shape (current value, prior bar, direction, series, zones, crossovers), and the caveat that the `summary` is derived from a fixed indicator set whose notes should be quoted over the score.

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?

Front-loaded with purpose, then capability, then batching/efficiency guidance, so an agent can stop reading early. The 19-indicator enumeration is somewhat redundant with the `indicators` enum and lengthens the block, but it aids capability discovery without opening the schema.

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 7-parameter, nested-schema tool with an output schema present, the description covers everything an agent needs: what is computed, how to batch symbols and timeframes, quota implications, and how to interpret the summary. Return-value structure is delegated appropriately to the output 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 coverage is 100%, so the 3 baseline applies, but the description adds real semantics beyond it: which indicators accept multiple periods at once (EMA/SMA, default 20/50/200), that every period is overridable via `periods`, and the batching behavior of `intervals`/`symbols` (up to 3 each, one quota unit, per-symbol/per-timeframe entries in `data`).

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?

Opens with a specific verb+resource ('Technical analysis for a crypto futures symbol') and immediately enumerates the 19 computed indicators, which cleanly separates it from siblings like get_candles (raw OHLC) and get_signals (trade signals). An agent can tell what this returns without opening the schema.

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?

Gives strong operational guidance: use `symbols` instead of one call per coin, use `intervals` instead of separate calls, and quote the `summary` notes rather than the raw score. It never explicitly routes the agent against tool-level siblings (get_candles, get_signals), so it stops short of the explicit when/when-not/alternatives bar 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description reinforces the read/ranking nature but adds no extra behavioral detail (e.g., what 'smart-money' means or how ranking snapshots differ). A 3 fits given the lower bar with annotations present.

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 filler. It is efficient, though its brevity leaves the minimal gaps noted elsewhere.

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?

An output schema exists and the schema documents all parameters, so the description needn't explain return values. For a read-only ranking tool with full schema and annotation coverage, the description is nearly sufficient, missing only sibling differentiation.

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%, so every parameter (limit, order, sortBy, source, timeRange, rankingType) is already documented in the schema. The description adds only that filtering and sorting exist, without new semantics. 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?

States a specific verb ('get') and resource ('top traders') scoped to 'ranked smart-money traders across supported exchanges with sorting and filtering.' This is clear, though it doesn't explicitly differentiate from the sibling get_elite_leaderboard, which likely serves a similar ranked-trader purpose.

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 wants ranked smart-money traders' gives a trigger context, but provides no exclusions or alternatives. With a closely related sibling like get_elite_leaderboard available, an agent gets no guidance on when to prefer one over the other.

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, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is covered. The description adds that these are symbols tracked by TraderSpy 'with real-time candle data available', which usefully constrains the result set. It does not, however, describe return format or why some symbols are tracked versus not.

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 filler; the tracked-symbol scope and the real-time-data qualifier both earn their place and arrive immediately.

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 parameters and an output schema present, the description need not explain return values, and the safety profile is covered by annotations. It is essentially complete for a simple list tool, though a note on what 'tracked' means or how many symbols to expect would add polish.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the scope of the listing, and it does not need to compensate for any schema gaps.

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 ('List') and a well-scoped resource ('crypto futures symbols currently tracked by TraderSpy'), which is distinct from siblings like screen_symbols, get_candles, and get_price. It does not, however, explicitly name or contrast with any sibling tool, so the agent must infer the boundary.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as screen_symbols or get_exchanges. The purpose implies discovery of available symbols, but nothing tells the agent when this call is preferable to another.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds almost nothing beyond that: no note about pagination behavior, the source/exchange dimension, result volume, or rate limits, and the 'closed' qualifier merely restates the purpose rather than disclosing new behavior.

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 zero filler and the trigger condition stated first. It is terse rather than padded, though the terseness is what leaves the other dimensions under-served.

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?

An output schema exists, so return values need not be described, and the schema documents all params. Still, for a paged history tool the description gives no hint about pagination, source selection, or how it differs from get_positions, leaving a modest gap for an agent deciding between siblings.

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 four documented params including a source enum, so the schema carries the parameter burden. The description adds no syntax, default, or filtering guidance beyond the schema, which is the baseline-3 case.

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 and resource ('closed trade history') scoped to 'a specific trader', which distinguishes it from siblings like get_positions (open positions) and get_trader_profile. It does not name a sibling explicitly, but the resource phrasing is specific enough to route correctly.

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 trigger is explicit: 'Use this when the user asks for closed trade history of a specific trader.' That is a clear context for invocation. No when-not conditions or named alternatives are given, 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the response bundles metrics with latest positions, but says nothing about whether the profile is live or snapshot-based, or about default-driven behavior for timeRange/rankingType.

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 filler, and the trigger condition comes first. It is arguably too terse for a tool with four parameters and an output schema, but nothing in it is wasteful.

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 an output schema present, the description need not explain return values, and annotations cover safety; it correctly focuses on the trigger and payload. The remaining gap is routing guidance among the many sibling retrieval tools, which leaves the definition slightly thin but functional.

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 clear descriptions and enums for source, timeRange and rankingType, so the schema carries the parameter burden. The description adds no syntax, defaults or interaction notes beyond what the schema already says, so 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?

States a specific verb and resource ('one trader profile') plus the payload contents ('metrics and latest positions'), which separates it from list-style siblings like get_top_traders and get_positions. It stops short of naming those siblings explicitly, so differentiation is inferable rather than stated.

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?

'Use this when the user needs one trader profile' gives a positive usage condition but no exclusions or alternatives. An agent must infer for itself when to prefer get_trader_position_history or get_top_traders over this tool.

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 read-only, idempotent, non-destructive safety. The description adds valuable behavioral context beyond that: scanning defaults (most-traded by 24h volume, default 50, max 100) and the quota cost advantage ('ONE quota unit however many symbols'). It does not detail pagination or rate limits beyond quota, hence 4.

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?

Front-loads purpose and example queries, then layers condition details, scanning behavior, and quota advantage. It is dense but appropriately sized for a complex screening tool, though a few sentences partly duplicate schema information (metric list, operators).

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 output schema exists and annotations cover safety, the description provides enough context for correct invocation: purpose, use cases, condition limits, default scanning universe, comparison mode, and quota advantage. Minor schema details like limit and sort defaults are left to the structured fields, which is appropriate.

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 86%, so the schema already documents parameters thoroughly, including defaults, enums, and examples. The description's metric list and operator summary largely restate schema content, though it usefully groups the fixed metric list and reiterates the three-condition limit.

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 (screen) and resource (crypto futures symbols) with clear scope (many symbols at once, one timeframe). Distinguishes itself from sibling get_technical_indicators by explicitly recommending itself for multi-symbol screening.

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 concrete example queries and explicitly says to prefer this tool over calling get_technical_indicators in a loop. Also clarifies the no-conditions + explicit-symbols comparison-table use case.

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