wallet-tracker

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, covering safety and data volatility. The description adds the 100-token limit and use-case context but doesn't disclose behavior like data freshness, rate limits, or what 'statistics' specifically includes. The description does not contradict 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 very concise—three short, bullet-like lines. The key capability (statistics for up to 100 tokens) is front-loaded, and every sentence adds value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only 3 parameters (2 required), full schema descriptions, annotations, and an output schema, the description is sufficient for most use cases. It covers the core constraint (max 100 tokens) and typical usage scenarios. It doesn't explain edge cases or error handling, but that is acceptable given the supporting structured fields.

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 lists parameters blockchain, mints, and wallet_type in a summary line, which adds little beyond the schema. It does not explain format constraints like token address length or blockchain-specific wallet availability, which are already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides statistics for up to 100 tokens in one request. It identifies the resource (tokens) and action (compare/get statistics). While it distinguishes from sibling compare_wallets, it doesn't explicitly differentiate from get_token_stats or get_analytics, which could also provide token statistics.

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 suggests two usage contexts: shortlists and following up on the most-traded analytics view. However, it lacks explicit guidance on when not to use this tool (e.g., for single token stats or historical data) and doesn't mention alternatives like get_token_stats or get_analytics.

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 declare readOnlyHint=true and openWorldHint=true, and the description aligns with these. It adds context beyond annotations, such as data trimming for longer periods and advising shortest window for best results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (few sentences plus parameter list) with no wasted words. It is front-loaded with purpose and usage, then parameter details.

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 an output schema exists (not shown), the description need not explain return values. It covers performance (cheaper than get_wallet_tracker), parameter constraints, and usage tips. Could mention comparative nature but output schema likely covers that.

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 adds meaning beyond schema by explaining wallet_type definitions, per-blockchain wallet availability, and period trimming behavior, which aids correct invocation.

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 compares up to 100 wallets in a single request, using specific words like 'statistics' and 'compare'. It also distinguishes from sibling tool 'get_wallet_tracker' by noting cost efficiency.

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 when the user names several wallets, or to follow up on a leaderboard', providing clear when-to-use context. It implies not to use for single wallets but does not explicitly state exclusions.

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 description goes beyond annotations (readOnlyHint, openWorldHint) by detailing the return contents ('confidence score and evidence...') and the underlying mechanism (Jito bundles). No contradictions 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?

The description is four sentences with no fluff: purpose, output, usage, parameter. Front-loaded and efficient. Every sentence 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?

With output schema present, the description doesn't need to repeat return structure. It covers purpose, usage, parameter, and expected output format. Complete enough for a simple single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the only parameter (mint) at 100%, and the description repeats the schema's description without adding new semantic details. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb ('Check whether KOL wallets bought...') and resource ('a Solana token through Jito bundles'), with a specific purpose that distinguishes it from sibling tools like get_wallet_holdings or get_token_holders.

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 advises when to use this tool ('when a user asks whether a launch was bundled, insider-heavy...') and includes an important constraint ('Solana only'). It does not mention alternatives or when not to use, but the context is clear enough for an agent.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds context that the tool returns aggregated metrics (trades, value, wallets) over a configurable window, and that wallet types have specific blockchain availability. It does not contradict 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 efficiently structured: results first, then usage guidance, then parameter list. Every sentence adds unique information with no 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 output schema exists, the description does not need to detail return values. It adequately covers the tool's purpose, parameters, constraints, and usage context for its complexity level.

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%, but the description adds significant value by explaining wallet type meanings (kol as influencer, smart as track record, whale as large holder) and blockchain-specific wallet availability, which goes beyond the schema descriptions.

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 counts of trades, value moved, and distinct wallets over a window. It explicitly says to use for market or single token busyness, distinguishing it from individual trade tools like get_recent_trades.

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 explicit when-to-use guidance: 'Use for how busy the market or a single token is, rather than for the individual trades.' It also lists parameter defaults and constraints, aiding 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 and openWorldHint=true. The description adds valuable behavioral context: trimming of large results, preference for shorter periods to avoid data loss, and blockchain-specific wallet type availability. These details go beyond the annotations and help the agent understand how the tool behaves.

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 highly concise: a two-sentence overview, a four-line mode list, and a five-line parameter list. Every sentence adds value; there is no redundancy or filler. The structure is front-loaded with purpose and then supported by parameter details.

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 complexity (5 parameters, 4 modes) and the presence of an output schema, the description covers the essential aspects: each mode's conceptual output, parameter defaults and constraints, and trimming behavior. It could mention pagination or rate limits, but overall it is sufficiently complete for an agent to use the tool effectively.

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 the baseline is 3. The description adds a summary of parameters and some usage tips (e.g., 'prefer the shortest window'), but the schema already explains each parameter well. The description adds minor value but does not significantly enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'four aggregate views over the tracked wallets' and lists each mode with a concise purpose (e.g., 'volume_trend shows activity over time'). It also differentiates from sibling tools by noting 'Use for the overall picture rather than one wallet or token.' This makes the tool's purpose and scope immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear guidance on when to use the tool ('overall picture rather than one wallet or token'), implying alternatives like per-wallet or per-token tools. It does not explicitly list when-not-to-use or specific alternatives, but the context is strong enough for an agent to discern appropriate usage.

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 openWorldHint=true. The description adds context about what information the tool provides (chains, wallet types, etc.) and its troubleshooting purpose, consistent with the hints and adding value beyond 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?

Two sentences, front-loaded with the core purpose, no redundant words. Highly efficient and easy to parse.

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 parameter-less health check tool with output schema, the description adequately covers purpose, use case, and data provided. No additional information is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and schema coverage is 100% (trivially). The description does not need to add parameter details. Baseline score of 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 provides 'service health and current coverage' including chains, wallet types, periods, limits, and tracked wallets per chain. This distinguishes it from sibling tools that focus on specific data queries (e.g., tokens, trades, signals).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a specific use case: 'Useful when a query returns nothing and it is unclear whether the data exists at all.' This provides clear context for when to use the tool, though it does not explicitly list alternatives or when not to use it.

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 openWorldHint, so the description does not need to restate safety. The description adds minimal behavioral context (e.g., ranking by performance) but does not disclose data freshness, pagination details, or default sorting direction. For a read-only query tool, this is adequate but not exceptional.

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 concise, with a clear front-loaded purpose, usage examples, and parameter list. Every sentence adds value without unnecessary repetition. It is well structured and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters with simple types, output schema present, annotations covering safety), the description covers the essential aspects: purpose, use cases, parameter constraints, and valid combinations. It lacks a definition of 'performance' (e.g., is it ROI, volume, or win rate?), which is a minor gap. Overall, it is sufficiently complete for an agent to use the tool effectively.

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 descriptions for all four parameters. The description adds some nuance (e.g., defining wallet types 'kol', 'smart', 'whale' and noting Robinhood Chain as an L2), but this largely mirrors the schema. The baseline is 3, and the added context does not significantly surpass it.

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 top wallets ranked by performance for a given chain, wallet type, and period. It provides concrete usage examples like 'best Solana KOLs today', which makes the purpose immediately understandable. However, it does not explicitly differentiate from similar tools like compare_wallets, and the ranking metric ('performance') is vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases ('Use for...') and explains parameter constraints (e.g., whale is Solana only, eth has kol only). It guides the agent on valid combinations. It does not mention when to avoid this tool or suggest alternatives, but the examples are sufficient for typical queries.

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 indicate readOnly and openWorld, which the description complements by specifying it returns realized PnL across tracked history. This adds behavioral context about the data scope and type, without contradicting 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 short and front-loaded with purpose, but it includes a redundant parameter listing that could be omitted. Overall efficient with minimal waste.

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 presence of an output schema and annotations, the description adequately covers the tool's behavior (daily/monthly PnL, streak spotting). It could mention time range defaults or pagination, but the context is sufficient for selection.

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 detailed parameter descriptions. The description only lists blockchain and address without adding extra nuance, so it provides no additional meaning beyond the schema, earning a baseline 3.

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 daily and monthly realized PnL for a wallet, with explicit use cases for profit/loss and streak spotting. It distinguishes itself by focusing on calendar-based PnL, which is unique among sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use for when a wallet made or lost money, and for spotting streaks,' providing clear context. It lacks explicit when-not-to-use or alternative tool mentions, but the context is sufficient.

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 openWorldHint=true. The description adds context about the live feed nature and wallet/blockchain constraints, but does not disclose additional behavioral traits like rate limits or result freshness beyond what is implied.

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 well-structured with a clear purpose line and a parameter list. It is concise but slightly verbose in parameter explanations. Every sentence adds value, though some schema information is repeated.

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 existence of an output schema, the description adequately covers the tool's purpose, parameters, and constraints. It is complete for a real-time filtered list tool with good annotations.

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 adds meaningful extra detail for parameters like wallet_type (explaining KOL, smart, whale) and blockchain (noting rh as Robinhood Chain L2), which adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a live feed of trades by tracked wallets, with a specific use case example. While it does not explicitly differentiate from sibling tools like get_signals or get_wallet_history, the purpose is specific and actionable.

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 an example use case ('what are KOLs buying at the moment') but does not explicitly state when not to use this tool or mention alternative tools. Usage context is implied but not fully delineated.

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 description adds behavioral context beyond annotations, such as limit trimming and wallet type meanings. It does not contradict the readOnlyHint and openWorldHint annotations, and provides useful details like blockchain-specific wallet availability.

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 concise and front-loaded with purpose, followed by a clear parameter list. Every sentence adds value with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the purpose, all parameters, and behavioral details like result trimming. With an output schema present, it adequately informs the agent without needing to describe return fields.

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?

Although schema coverage is 100%, the description adds significant value by explaining wallet type definitions (kol, smart, whale) and blockchain-specific notes (e.g., Rh is Ethereum L2). This goes beyond the schema descriptions.

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: 'Past signals, for checking whether a kind of signal has worked historically before acting on a live one.' It uses a specific verb-resource and explicitly mentions the use case, distinguishing it from siblings like get_signals (current signals) and get_analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for historical validation, implying it should be used before acting on a live signal. However, it does not explicitly say when not to use it or name alternatives, leaving some inference to the agent.

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?

Beyond annotations (readOnlyHint, openWorldHint), the description reveals critical behavioral traits: only first page reachable due to non-usable cursor, and smart money signals unavailable on eth. 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?

Well-structured with front-loaded summary, signal definitions, usage hint, caveat, and parameter list. Slightly verbose but every sentence earns its place. Good balance of detail and readability.

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?

Covers core purpose, usage, constraints, and all parameters. Warns about pagination limit. With an output schema present, return format explanation is not required. Minor gap: no guidance on handling empty results, but not critical.

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 covers 100% of parameters with descriptions; the description adds extra context (e.g., which wallet types per blockchain, default min_wallets server value of 3, Robinhood Chain explanation), enhancing understanding beyond schema alone.

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 signals of tracked wallet clusters acting on tokens, and explicitly positions it for 'what should I be looking at right now,' distinguishing it from historical signal tools like get_signal_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?

Provides clear usage context (current signals, 'what should I be looking at right now'), explains pagination limitation (raise limit instead of paginating), and notes unavailability on eth for smart money. Lacks explicit when-not-to-use alternatives but is otherwise strong.

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 openWorldHint: true, so the agent knows it's a safe read operation. The description adds context about content (key, pricing, docs) but doesn't contradict annotations. Slight deduction for not providing more detail on behavior beyond what annotations cover.

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 key purpose and usage. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description outlines the content (key, pricing, docs, data coverage) and usage context. Though it doesn't detail output format, the presence of an output schema likely handles that. Adequate for a simple onboarding 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 no parameters, so the description doesn't need to explain any. The baseline for zero params is 4. No additional value needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool provides information on getting a free API key, pricing, documentation, and data coverage. It clearly distinguishes from sibling tools by indicating it's for setup/onboarding, while siblings are for specific data queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Call this first if you do not have a key yet, or if another tool returned an auth error.' This clearly defines when to use this tool versus others.

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 description provides rich behavioral context beyond annotations (readOnlyHint, openWorldHint), including sorting by balance, inclusion of market cap and price, and chain-specific wallet type availability. No contradictions 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?

The description is concise, front-loaded with purpose, and every sentence adds value. 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 complexity (4 parameters, blockchain-specific behavior) and the existence of an output schema, the description covers all essential context: purpose, usage cues, parameter details, and return data characteristics.

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?

With 100% schema coverage, baseline is 3. The description adds significant value by explaining blockchain values, chain-specific wallet types, default limit, and the fact that large results are trimmed. This goes well beyond the schema descriptions.

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 function: retrieving tracked wallets holding a token, sorted by balance, with market cap and price. It explicitly distinguishes from sibling tools by specifying 'Use when the user asks who is still holding, rather than who ever traded it.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool (who is still holding) versus when not (trade history). While it doesn't name specific alternative tools, the guidance is sufficient for an AI agent to differentiate.

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 declare readOnlyHint and openWorldHint. The description adds behavioral details beyond annotations: the market cap endpoint returns empty, blockchain-specific wallet restrictions, and the 'open world' nature of merging all wallet types. No contradictions.

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 well-structured: first paragraph states purpose and output, second provides a critical caveat, third details parameters. It is concise with no redundant sentences, though slightly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple blockchains, wallet types, output with schema), the description covers all necessary information: purpose, caveats, parameter details, and blockchain-specific behavior. The output schema exists, so return values are implicitly covered.

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%, baseline 3. Description adds meaning: explains blockchain-specific wallet type availability (e.g., 'solana has kol, smart and whale wallets; bnb, base and rh have kol and smart') and clarifies wallet_type behavior when omitted.

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: identifying notable traders (KOLs, smart money, whales) holding a token, with details on bought/sold, buying pressure, and individual positions. It distinguishes itself from sibling tools by positioning as 'the main tool for is anyone notable in this token' and explicitly referencing get_token_holders for market cap.

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 usage context: when not to use it (market cap is empty, use get_token_holders instead) and blockchain-specific wallet type availability. It lacks explicit when-to-use directives but clearly implies its niche.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds that results are most recent first, large results are trimmed to fit context window, and blockchain-specific wallet type availability. This provides meaningful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is remarkably concise yet informative. It front-loads the core purpose, gives a usage example, then lists parameters with clear options. Every sentence adds value, and the structure is easy to scan.

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 presence of an output schema (not shown here), the description does not need to explain return values. It covers all 4 parameters, blockchain specifics, wallet type options, and limit behavior. It provides sufficient context for an AI agent to use the 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%, so baseline is 3. The description adds value by clarifying blockchain-specific wallet types and the default limit behavior. While schema already describes parameters, the description enhances usability with examples and constraints.

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 individual buys and sells by tracked wallets for one token, most recent first. It provides a usage example illustrating the sequence of events, distinguishing it from sibling tools like get_token_stats or get_token_holders.

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 includes a concrete use case ('Use for the sequence of events, for example whether KOLs bought before or after a price move') and lists parameters with available options, guiding when to use. It does not explicitly exclude scenarios or mention alternatives, but the context is clear.

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 description discloses key behaviors: it analyzes 'other tracked wallets that traded the same tokens as this one over the last 30 days' and ranks by overlap. This adds context beyond the readOnlyHint and openWorldHint annotations, which already indicate safe reading and dynamic results. The description enhances agent understanding of the tool's logic and scope.

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 concise: two sentences of purpose plus a parameter list. Every part is relevant, and the structure front-loads the key functionality. The parameter list is a minor redundancy with the schema but is brief and helpful for an agent scanning the description.

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 presence of an output schema, the description does not need to detail return values. It explains the input parameters, the criteria (token overlap over 30 days), ranking, and a practical use case. This covers essential context for an agent to decide when and how to use the 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 having detailed descriptions in the schema. The tool description adds a brief parameter list ('blockchain: solana, bnb, base, eth or rh', etc.), but this does not provide new information beyond the schema. The description merely summarizes the schema content without adding deeper semantic context, so 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 it returns 'other tracked wallets that traded the same tokens as this one over the last 30 days, ranked by overlap.' While it lacks a strong verb like 'get' or 'list,' the purpose is specific and well-defined. It distinguishes itself from siblings like 'compare_wallets' or 'detect_bundles' by focusing on token overlap, though not explicitly differentiating.

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 mentions the tool is 'useful for finding groups that move together, which can indicate coordination,' providing a clear use case. However, it does not specify when to use this tool versus alternatives (e.g., compare_wallets, get_wallet_history), nor does it state when not to use it. The guidance is implied but lacks explicit exclusions or comparisons.

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 indicate readOnlyHint and openWorldHint. Description adds behavioral details: pagination is inside the payload, and limit trimming behavior. No contradictions; provides useful extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: purpose first, then usage guidance, then parameter details. Could be slightly more concise, but every sentence adds value. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description doesn't need return details. Covers pagination, parameter constraints, and use case. Missing edge cases or error handling, but sufficient for a read-only tool with annotations.

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%, but description adds meaning: blockchain values with per-chain wallet types, address format details, cursor usage, and limit behavior (trimming beyond 1000). Slight discrepancy with schema max (200 vs 1000) but still informative.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it returns 'Lifetime trading history of a wallet: aggregate stats, a per-token overview and the individual trades.' It also distinguishes usage from 'how it is doing now,' clearly differentiating from siblings like get_wallet_holdings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: 'Use for what a wallet traded historically, rather than how it is doing now.' Explains pagination pattern. However, it lacks explicit when-not-to-use or alternative tool references.

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 description discloses that data is live (not cached), may take over a second, and may return a 'loading' state requiring a retry. This adds value beyond the annotations (readOnlyHint, openWorldHint) by explaining the retry behavior and performance characteristic.

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 extremely concise, using two clear sentences plus a parameter list. Critical information is front-loaded, and every sentence contributes to understanding the tool's behavior.

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 tool with an output schema (implied by 'has output schema: true'), the description covers essential context: live data, speed, loading state, supported blockchains, and address format. No obvious 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?

Schema description coverage is 100%, with both parameters already well-documented in the schema. The description only restates the parameter names and allowed values, adding minimal new meaning beyond what the schema 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 states the tool returns 'current onchain token holdings' that are 'live rather than derived from tracked trades'. It distinguishes itself from sibling tools by emphasizing real-time data and slower performance.

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 notes the tool is slower than other wallet tools and advises calling again if 'loading' is true. This provides context but does not explicitly specify when not to use it or suggest alternative 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 mark the tool as readOnlyHint=true and openWorldHint=true. The description adds behavioral details: longer periods return more data and are trimmed harder, and each blockchain has specific wallet categories. No contradictions 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?

The description is concise, using bullet-like structure for parameters and a clear purpose statement. Every sentence adds value without 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 has an output schema (covering return values) and clear annotations, the description sufficiently explains purpose, parameters, and behavioral nuances. No gaps remain for agent understanding.

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 the schema fully explains parameters. The description adds extra context for the blockchain parameter (wallet types per chain) and reinforces the period recommendation, providing value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides period statistics for ONE wallet including PnL, win rate, volume, etc., and explicitly calls it 'The main tool for "how is this trader doing".' This is specific, actionable, and distinguishes it from sibling tools like get_wallet_holdings or get_wallet_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 advises 'prefer the shortest period that answers it' and details blockchain-specific wallet types (e.g., solana has kol, smart, whale). It gives clear context for when to use this tool, though it does not explicitly list alternatives or when-not-to-use scenarios.

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 declare readOnlyHint and openWorldHint, which align with the 'Browse' verb. The description adds behavioral context: pagination via cursor, explanation of wallet types per chain (e.g., eth only has kol), and the warning about large result sets.

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 three sentences plus a parameter list. It is front-loaded with purpose and usage. The parameter list is somewhat redundant with the schema, but overall it remains compact and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description need not explain return values. It covers purpose, usage guidelines, parameter details, and pagination. No gaps remain for an agent to invoke the 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%, so baseline is 3. The description adds value by emphasizing the limit parameter ('Always pass a limit'), detailing which wallet types exist per blockchain, and clarifying the cursor's purpose. This goes beyond the schema descriptions.

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 browses wallets tracked by CabalSpy for a given chain and wallet type, specifically to check coverage of KOLs, smart money, or whale wallets. This verb ('Browse') and resource ('wallets') combination distinguishes it from sibling tools like compare_wallets or get_wallet_holdings.

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 advises to always pass a limit due to potentially large lists, and implies this tool is for browsing available wallets. While it doesn't explicitly state when not to use or name alternative tools, the context makes the intended use clear.

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 include readOnlyHint=true, indicating no side effects. The description adds useful context: it returns a label with specific attributes (name, Twitter, etc.) and warns about EVM chain behavior where the reported chain may not be the intended one. This goes beyond what annotations provide.

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?

Description is reasonably concise with a clear purpose, usage guidance, and a key caveat. However, it contains some redundancy (parameter description in both schema and description) and could be slightly more compact. Still efficient for the information it conveys.

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 (1 required parameter, read-only, explicit output schema exists), the description covers essential aspects: purpose, when to use, key limitation (EVM chain behavior), and parameter details. No major gaps for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the 'address' parameter including format details (Base58 for Solana, 0x-prefixed hex for EVM). The description repeats the parameter name but adds no additional semantics beyond the schema, so baseline score 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?

Description clearly states it identifies a wallet address and returns associated labels including name, Twitter, Telegram, wallet type, and chain. It distinguishes from sibling tools like list_wallets and get_wallet_holdings by specifying the exact lookup action.

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 says 'Start here when a user pastes an address and asks who it is,' providing clear guidance on when to use it. Also warns about EVM chain behavior where only the first match is returned, which informs when results might be ambiguous. Lacks explicit mention of alternatives but is sufficiently distinct from siblings.

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