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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: pagination ('25 per page'), default sorting ('net value transferred'), inclusion of CEX deposit addresses, and one-level-deeper analysis. However, it misses details like rate limits, error conditions, authentication needs, or whether it's read-only/destructive. The description does not contradict annotations (none provided).

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 front-loaded with core functionality but includes extensive notes and examples that add bulk. Sentences like 'Address structure / string is not important, but the relationship is!' are somewhat redundant. While informative, the structure could be more streamlined by separating usage notes from core 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 tool's complexity (analyzing wallet interactions with multiple parameters) and no annotations, the description does a decent job covering purpose, behavior, and parameters. With an output schema present, it need not explain return values. However, it could improve by addressing missing behavioral aspects like error handling or performance limits.

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 0%, so the description must compensate. It adds some parameter semantics: explains sorting options ('volOut, volIn, numTxOut, numTxIn, usdNetflow'), provides examples with parameters like 'addresses', 'entityId', 'sourceInput', 'groupBy', 'chain', 'timeRange', 'order_by', and 'order_by_direction'. However, it does not fully document all parameters (e.g., 'page' is mentioned only indirectly via 'per page'), leaving gaps in understanding the complete input 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's purpose: 'Get 25 (per page) addresses or entities with the most common interactions with input addresses' and 'Also returns the top 3 tokens transferred by count for each counterparty'. It specifies verb ('Get'), resource ('addresses or entities'), and scope ('most common interactions'), but does not explicitly differentiate from sibling tools like 'address_related_addresses' or 'address_transactions'.

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 implied usage guidance through examples and notes, such as 'To get related wallets: Focus on direct value transfers...' and examples for querying by addresses or entity. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'address_related_addresses') and does not mention prerequisites or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data, implying a read-only operation, but doesn't mention any behavioral traits such as rate limits, authentication needs, data freshness, or output format. For a tool with complex inputs and historical analysis, this is a significant gap in transparency.

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

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

The description is a single, efficient sentence: 'Get historical native coin & token balances of address.' It's front-loaded with the main purpose and contains no unnecessary words, making it highly concise and well-structured.

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 (historical balance analysis with multiple parameters) and the presence of an output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or parameter meanings. The output schema may cover return values, but the description doesn't provide enough context for effective tool selection and invocation.

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

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

The description mentions 'address' and 'historical', which loosely relates to parameters like 'addresses' and 'lookbackDays', but adds minimal semantic value beyond the schema. With 0% schema description coverage, the schema itself lacks parameter descriptions, so the description doesn't compensate effectively. However, it hints at the core inputs, justifying a baseline score.

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

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

The description clearly states the tool's purpose: 'Get historical native coin & token balances of address.' It specifies the action ('Get'), resource ('historical native coin & token balances'), and target ('address'). However, it doesn't explicitly differentiate from siblings like 'address_portfolio' or 'smart_traders_and_funds_token_balances', which might also involve balance-related 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 provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'address_portfolio', 'address_transactions', 'token_flows'), there's no indication of context, prerequisites, or exclusions. This leaves the agent guessing about appropriate use cases.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: output format ('pre-formatted markdown that should be presented exactly as returned'), data scope differences between wallet addresses and entities, and mode-specific inclusions (e.g., liquidation prices for Hyperliquid positions). However, it lacks details on error handling, rate limits, or authentication requirements, which are common for such tools.

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 and front-loaded with the core purpose, followed by detailed explanations and examples. While comprehensive, it is slightly verbose; some details (e.g., repeated mode explanations in examples) could be condensed. However, every sentence adds value, and the structure aids 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?

Given the tool's complexity (multiple modes, entity vs. wallet distinction) and the presence of an output schema, the description is complete. It covers all critical aspects: purpose, usage guidelines, parameter semantics, and output behavior. The output schema likely handles return value details, so the description appropriately focuses on input and behavioral context without redundancy.

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

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

The schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the input schema by explaining each mode in detail (e.g., 'fast-mode-default' skips defi, 'all' includes everything), clarifying entity vs. wallet address usage, and providing concrete examples. This transforms abstract parameter names into actionable guidance for users.

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

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

The description clearly states the tool's purpose: 'Get comprehensive portfolio overview for a wallet address or entity.' It specifies the verb ('Get'), resource ('portfolio overview'), and scope ('wallet address or entity'), distinguishing it from siblings like address_transactions or address_historical_balances by focusing on current holdings rather than historical data or transactions.

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 guidance on when to use this tool vs. alternatives. It details different modes (e.g., 'fast-mode-default', 'all') for specific use cases, explains entity vs. wallet address usage, and includes example usage scenarios. This helps users select the appropriate mode based on their needs, such as risk analysis with liquidation prices or focusing on specific portfolio aspects.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about the types of connections included and exclusions like exchange withdrawal addresses, which is helpful. However, it doesn't cover critical aspects such as rate limits, authentication needs, error handling, or performance characteristics (e.g., response time, data freshness). The description provides some behavioral insight but leaves gaps for a tool with no annotation support.

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 and appropriately sized, starting with the core purpose, followed by a note on included/excluded connections, an example, and return format. Each sentence adds value, such as clarifying connection types and providing usage notes. It could be slightly more front-loaded by moving the example later, but overall it's 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 complexity (analyzing address relationships), no annotations, and an output schema present (which handles return values), the description is fairly complete. It covers purpose, usage guidelines, parameter context, and output format. However, it lacks details on behavioral traits like rate limits or error cases, and parameter semantics are not fully elaborated, preventing a perfect score.

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

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

The schema description coverage is 0%, so the description must compensate. It mentions the 'request' parameter and provides an example with 'addresses' and 'chain', adding meaning beyond the bare schema. However, it doesn't fully explain all parameter semantics (e.g., what 'chain' values are valid beyond 'all' and 'evm', or pagination details implied in the request). The description adds value but doesn't fully bridge the coverage gap.

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

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

The description clearly states the tool's purpose: 'Get information about related addresses of an input address.' It specifies the verb ('Get information') and resource ('related addresses'), and distinguishes it from sibling tools like 'address_counterparties' by noting that this tool only includes 'special' connections, while counterparties are separate. However, it doesn't explicitly contrast with all siblings, keeping it from a perfect score.

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

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

The description provides clear usage guidance by specifying what types of connections are included (e.g., 'First Funder', 'Signer') and what is excluded (e.g., 'First funder exchange withdrawal address does usually NOT belong to the same entity'). It also directs users to 'address_counterparties' for related wallets, offering an alternative. However, it lacks explicit when-not-to-use scenarios or comparisons with other siblings beyond counterparties.

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?

No annotations are provided, so the description carries full burden. It discloses that it returns 20 most recent transactions per page and filters by date range, which is useful. However, it lacks critical behavioral details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior beyond 'per page', error handling, or what the output schema contains. For a tool with no annotations, this leaves significant gaps in understanding how to use it effectively.

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 two sentences that are front-loaded with key information (get transactions, 20 most recent per page). There's no wasted text, and it efficiently conveys the core functionality. However, it could be slightly more structured by explicitly naming parameters or usage contexts.

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

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

Given the tool's moderate complexity (fetching transactions with filtering), no annotations, 0% schema description coverage, but with an output schema present, the description is partially complete. It covers the basic purpose and some behavioral traits (pagination, date filtering) but misses parameter explanations, usage guidelines, and full behavioral transparency. The output schema mitigates the need to describe return values, but overall completeness is adequate only for minimal use.

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 0%, so the description must compensate. It mentions 'address' implicitly and hints at 'date range' and 'page', but doesn't explicitly list or explain any parameters. The input schema has 1 parameter ('request') that can be an object with properties like 'address', 'page', 'chain', and 'hideSpamToken', but the description fails to add meaning beyond what the bare schema provides, leaving parameters largely undocumented.

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 fetches transaction history for an address with specific constraints (20 most recent per page, latest transactions by date range). It uses the verb 'Get' with the resource 'transactions made by an address', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'transaction_lookup' or 'address_historical_balances', which might offer similar or overlapping functionality.

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 no guidance on when to use this tool versus alternatives. It mentions 'latest transactions according to the date range' but doesn't specify if date range is an input parameter or implicit behavior. There's no mention of prerequisites, alternatives like 'transaction_lookup' for single transactions, or when to choose siblings such as 'address_portfolio' for broader analysis.

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 no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it explains domain resolution capabilities, price delay limitations, NFT verification process, chain preference logic, and result fallback behavior. The only minor gap is lack of explicit rate limit or authentication requirements.

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 clear sections (purpose, exclusions, capabilities, args, usage guidance, important notes) but could be more concise. Some points are repeated (e.g., chain parameter usage mentioned multiple times), and the length is substantial though all content appears valuable.

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

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

Given the tool's complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is remarkably complete. It covers purpose, usage guidelines, parameter semantics, behavioral traits, limitations, and sibling tool relationships, leaving no significant gaps 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?

With 0% schema description coverage, the description fully compensates by providing extensive parameter semantics: it explains each parameter's purpose, provides examples (✅ CORRECT/❌ WRONG), lists valid chain values, explains result_type options with use cases, and clarifies default values and constraints like 'max: 25'.

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 this is the 'FIRST entry point' for searching tokens, entities, and addresses, distinguishing it from sibling tools like 'prediction_market_lookup' and 'token_ohlcv'. It clearly specifies the verb ('search') and resources ('tokens, entities, and addresses').

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 guidance on when to use this tool vs. alternatives: 'Do NOT use this tool for prediction markets... use `prediction_market_lookup` instead' and 'Use `token_ohlcv` for latest prices.' It also includes detailed 'How to choose result_type' and 'Important' sections with specific usage rules.

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?

No annotations are provided, so the description carries full burden. It mentions the tool retrieves rankings but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or whether it's a read-only operation. The description is minimal and lacks critical context for safe and effective use.

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 the core purpose. The two-sentence structure is efficient, though the second sentence about returns is somewhat redundant given the output schema. No wasted words, but it could be more 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 no annotations, 0% schema coverage, but an output schema exists, the description is incomplete. It covers the basic purpose and return format but misses parameter details, usage context, and behavioral transparency. For a tool with structured input/output, this is minimally adequate but leaves significant gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only states that the request contains 'parameters and pagination settings,' but doesn't explain what those parameters are (chain_type, time_frame) or their semantics. This leaves the agent with inadequate understanding beyond the schema's structure.

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

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

The description clearly states the tool's purpose: 'Get chain growth rankings by active addresses, transactions, gas fees and DEX volume.' It specifies the verb ('Get') and resource ('chain growth rankings') with concrete metrics. However, it doesn't explicitly differentiate from sibling tools, which focus on addresses, tokens, predictions, and wallets rather than chain-level growth rankings.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or sibling tools. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (trader performance rankings as markdown with specific columns), mentions sorting and filtering capabilities, and includes an example request. However, it lacks details on rate limits, authentication needs, or pagination behavior (though 'page' parameter is in 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?

The description is appropriately sized and front-loaded, starting with the core purpose, followed by returns, columns, sorting/filtering options, an example, and notes. Each section adds value without redundancy, and the use of markdown formatting enhances readability without wasting space.

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 (leaderboard with multiple filters and sorting), no annotations, and an output schema exists (so return values need not be explained), the description is complete. It covers purpose, usage, parameters via example, and behavioral aspects, making it sufficient for an agent to understand and 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?

The schema description coverage is 0%, so the description must fully compensate. It successfully adds meaning by explaining the columns returned, sorting/filtering options on specific fields (totalPnl, accountValue, roi), and provides a detailed example showing how to structure the request with date ranges and numeric filters, going well beyond the minimal 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's purpose with specific verbs ('Get') and resources ('Hyperliquid perpetual futures trader leaderboard with performance metrics'), distinguishing it from siblings like 'prediction_market_pnl_leaderboard' or 'token_pnl_leaderboard' by specifying it's for perpetual futures traders on Hyperliquid.

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 when to use this tool (for Hyperliquid perpetual futures trader rankings) and includes notes about its specific endpoint, but does not explicitly state when not to use it or name alternative tools for similar data on other platforms or asset types.

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 no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains key traits: the tool returns 'pre-scored buying recommendations' with a 'Performance Score ≥15' threshold, uses 'daily' data updated 'in batches', and includes dynamic indicator columns. However, it lacks details on rate limits, authentication needs, or error handling, which prevents a perfect 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?

The description is well-structured with clear sections (e.g., 'When to use this tool vs token_discovery_screener', 'Example queries', 'Scoring', 'Returns'), making it easy to parse. However, it includes some redundancy (e.g., repeating scoring thresholds and instructions to 'explain' them to users) and could be more front-loaded, slightly reducing efficiency.

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 (involving scoring thresholds, filtering, and dynamic outputs) and the presence of an output schema, the description is highly complete. It thoroughly explains the tool's purpose, usage guidelines, behavioral traits, scoring system, return format, and example queries, providing all necessary context for an AI agent to invoke it correctly without relying on annotations or schema details.

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

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

The input schema has 0% description coverage for its single parameter (marketCapGroup), but the description compensates by implicitly addressing parameters through context. It mentions filtering by 'market cap group' in the usage guidelines and explains the tool's default behavior ('returns tokens pre-filtered by: performance_score >= 15'), though it does not explicitly detail the parameter's semantics or enums. This partial compensation justifies a score above baseline.

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

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

The description clearly states the tool's purpose: 'Discover and filter a daily list of attractive tokens using Nansen Score Indicators weighted by coefficients (= Performance Score).' It specifies the verb ('discover and filter'), resource ('tokens'), and mechanism ('Nansen Score Indicators'), and explicitly distinguishes it from sibling tools like token_quant_scores and token_discovery_screener, making it highly specific and differentiated.

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 guidance on when to use this tool versus alternatives. It states: 'Use this tool when you don't know which tokens to buy and need recommendations based on backtested indicators' and includes a dedicated section comparing it to token_discovery_screener, detailing specific use cases and thresholds (e.g., 'pre-scored buying recommendations' vs. 'live data' or 'explore tokens by specific criteria'). This offers clear, actionable context for selection.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context that 'Blank PnL fields mean unavailable data, not zero' and clarifies field semantics (Position Size vs Value), but it omits operational details like caching behavior, rate limits, or data 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?

The description is appropriately compact with clear structure: a single declarative sentence followed by targeted bullet points clarifying output field interpretation. 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?

While the input schema lacks descriptions, the tool has an output schema (reducing the need for extensive output documentation). The description provides helpful field-level semantics for the output, but remains thin on input guidance given the 0% schema coverage and lack of parameter details.

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

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

Given 0% schema description coverage, the description partially compensates by implying the address parameter through 'Polygon wallet,' but it fails to mention the `page` parameter or pagination behavior entirely. The semantic mapping to input parameters is incomplete.

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 'Prediction market PnL breakdown for a Polygon wallet,' specifying both the resource (prediction market PnL) and scope (Polygon wallet). However, it does not explicitly differentiate from similar sibling tools like `wallet_pnl_summary` or `prediction_market_pnl_leaderboard`.

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

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

The description provides no guidance on when to use this tool versus alternatives such as `prediction_market_address_trades` (for transaction history) or `wallet_pnl_summary` (for overall portfolio PnL). There are no prerequisites, conditions, or explicit use-case scenarios mentioned.

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 no annotations, the description adequately implies read-only behavior by describing it as a summary tool, but does not explicitly state it is non-destructive or mention any side effects, rate limits, or permissions. The note about blank PnL/ROI is helpful but limited.

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 bold introductory line and clear sections for 'When to use' and 'Key fields'. It is concise (about 5 lines) and front-loaded with main purpose. A slight improvement could be integrating the key fields into a more streamlined format.

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 returns summary metrics and has an output schema (not shown), the description adequately covers when to use, what it returns, and data interpretation (blank fields). It is complete for a simple wallet-level tool, but could mention the optional page parameter for pagination.

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 description does not describe the input parameters beyond implying the wallet address. The schema coverage is 0% according to context, but the schema itself has descriptions for 'page' and 'address'. However, the tool description adds no value to parameter understanding; it focuses on output fields.

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 'Prediction market summary metrics for a Polygon wallet' with specific verb and resource. It distinguishes from siblings by stating 'First wallet-level Polymarket tool for a quick trader overview' and directing to use it before detailed trades/PnL 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?

Explicit guidance on when to use: 'Use before detailed address trades/PnL when the user asks for a general wallet profile, activity summary, or whether a wallet is active on Polymarket.' Also explains meaning of blank fields, providing clear context.

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

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

With no annotations provided, the description carries the full burden and adds valuable context by explaining output field semantics ('Share Size is quantity traded...') and USD value scoping. However, it omits operational details like pagination behavior, default date ranges (last 30 days), or whether the tool performs read-only operations.

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 optimally structured with the purpose front-loaded, followed by clearly labeled 'Key fields' and 'Pitfalls' sections. Every sentence delivers specific value regarding output interpretation or usage constraints 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?

Since an output schema exists, the description appropriately focuses on interpreting specific fields rather than return values. However, the lack of parameter documentation for a tool with nested date range logic and pagination leaves significant gaps in the overall contract.

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?

Given the 0% schema description coverage context, the description fails to compensate adequately. While it implicitly references the 'Polygon wallet' (address parameter), it completely omits explanation of the `dateRange` (with its complex token system) and `page` parameters, leaving critical inputs undocumented.

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 'Prediction market trade history for a Polygon wallet,' specifying the resource and scope. It distinguishes from the sibling `prediction_market_address_pnl` by stating it is for 'wallet trade activity, not profitability,' though it could explicitly name the alternative tool for clarity.

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 'Pitfalls' section provides explicit guidance on when NOT to use the tool ('not profitability'), preventing misuse for PNL analysis. However, it does not name the specific sibling tool (`prediction_market_address_pnl`) that should be used 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?

With no annotations provided, the description carries the full burden. It discloses critical domain behavior: the event/market hierarchy, that results include live pricing data ('current outcome prices, last trade price, and bid/ask'), search API characteristics ('natural language queries work well'), and strict output rules ('do not silently substitute'). Missing only generic technical details like rate limits or caching.

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?

Excellent information density with clear visual hierarchy (bold headers for 'PM building blocks', 'When to use', 'Query tips', 'Output rules'). Every sentence provides unique value—domain education, tool selection logic, or query optimization. No redundant fluff despite the length.

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

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

Given the tool's complexity (nested request object, domain-specific taxonomy, multiple sibling tools), the description provides comprehensive context. It explains the Polymarket data model (events vs. markets) necessary to interpret outputs, and notes that output schema exists so it doesn't redundantly describe return structure while still highlighting key returned 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 description coverage is 0% at the root level (the 'request' wrapper lacks a description), requiring the description to compensate. It successfully adds semantic context for key nested parameters: explaining 'queryVariant' as a 'cleaner short keyword version' and 'includeEventMarkets' as useful for 'event-level questions where market detail tools need the full market slate.'

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 opens with a precise action ('Search Polymarket for events and markets') and specific search vectors ('name, topic, URL, or slug'). It distinguishes itself from the sibling 'general_search' tool explicitly ('Do NOT use general_search for prediction markets') and clarifies the domain-specific distinction between events and markets.

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?

Contains an explicit 'When to use' section that defines the entry point for PM workflows ('First tool when the user asks...'). It names specific alternatives ('prediction_market_ohlcv' for price history) and provides clear inclusion/exclusion criteria (e.g., when to set 'includeEventMarkets' to true).

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 no annotations provided, the description carries the full burden. It discloses critical data semantics (Close represents share price, Yes/No shares are complementary) and behavioral constraints (responses are isolated to one marketId, empty results should not trigger estimation). It does not mention rate limits or auth requirements, preventing a perfect 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?

Structured with clear headers (When to use, Key fields, Pitfalls, Prerequisites) that front-load critical information. Every sentence provides distinct value—whether defining usage context, explaining data interpretation, or warning against misuse. No redundancy or filler present.

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?

Comprehensive given the presence of an output schema (which excuses detailed return value explanation). The description covers input prerequisites, output interpretation (Key fields), and operational pitfalls. It appropriately defers to the output schema for return structure while adding necessary semantic context. Minor gap in not clarifying pagination behavior.

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?

Given the context signal of 0% schema description coverage, the description partially compensates by explicitly referencing marketId (including where to obtain it) and the 'requested window' (implying dateRange). However, it omits guidance on pagination (page), sorting (orderBy, orderByDirection), or the dateRange token syntax, leaving significant gaps relative to the parameter complexity.

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 opens with a specific, actionable summary: 'Historical odds/volume candles for a Polymarket market.' It clearly identifies the resource (Polymarket OHLCV data) and implies the operation (retrieval), distinguishing it from sibling tools like prediction_market_trades (individual trades) or prediction_market_orderbook (current snapshot).

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 explicit 'When to use' criteria (current odds, price history, probability changes). Includes a 'Prerequisites' section naming the specific sibling tool prediction_market_lookup for ID resolution. The 'Pitfalls' section offers clear negative guidance (do not mix markets, do not estimate missing data), constituting comprehensive when/when-not coverage.

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?

No annotations are provided, so the description carries full burden. It comprehensively discloses domain-specific behavior: Yes/No price complementarity (Yes + No ≈ $1), share quantity vs USD distinctions, and interpretation logic (converting No-side prices to Yes-equivalent). Includes critical warnings about resistance/support misinterpretation.

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 markdown headers (When to use, Key fields, Pitfalls) that front-load critical information. While lengthy, the complexity of prediction market mechanics justifies the detailed domain explanations. Minor deduction for slight verbosity in the Yes/No relationship section.

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 appropriately focuses on input semantics and usage context rather than return values. It provides complete domain context for interpreting orderbook data correctly, including unit warnings and price relationship logic essential for this financial 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?

With schema description coverage at 0%, the description partially compensates by noting in Prerequisites that marketId should be obtained from prediction_market_lookup (or screener per schema). However, it does not describe the 'page' parameter or provide parameter constraints/format details within the description text itself.

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 opens with a specific, actionable statement ('Live orderbook for a Polymarket market') that clearly identifies the resource and distinguishes it from siblings like prediction_market_ohlcv or prediction_market_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?

Exceptional guidance with explicit 'When to use' (bid/ask depth), 'Prerequisites' (call prediction_market_lookup if marketId unknown), and 'Pitfalls' sections (don't use for current odds; use ohlcv instead). Explicitly names sibling tools as alternatives.

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

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

No annotations are provided, so the description carries the full burden. It successfully discloses data semantics ('Side Held reflects current side exposure') and critical data quality issues ('If PnL fields are blank, say profitability is unavailable'). It does not mention rate limits or caching behavior, but covers the essential behavioral constraints for correct usage.

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?

Excellent structure with clear headers (When to use, Key fields, Pitfalls, Prerequisites). Information is front-loaded with the purpose statement. Every sentence earns its place; no redundancy or filler text.

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 (per context signals), the description appropriately focuses on usage constraints and pitfalls rather than return values. It addresses prerequisites, distinguishes from siblings (top holders vs PnL), and documents data edge cases (blank fields), making it complete for a data retrieval tool of this complexity.

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

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

Context signals indicate 0% schema description coverage. The description mentions marketId in the Prerequisites section and notes it can be obtained from prediction_market_screener, adding valuable semantic context. However, it does not describe the page parameter or provide type/format details for marketId, providing only minimal compensation for the schema coverage gap.

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?

Opening line 'PnL leaderboard for a Polymarket market' provides a specific verb (PnL leaderboard) and resource (Polymarket market). It clearly differentiates from sibling tools like prediction_market_top_holders or prediction_market_address_pnl by focusing on market-level profit/loss ranking.

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?

Explicit 'When to use' section restricts usage to 'profitability claims' only. The 'Pitfalls' section provides clear when-not-to-use guidance ('do not substitute top holders'). The 'Prerequisites' section explicitly names the sibling tool prediction_market_lookup as a dependency when marketId is unknown.

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 no annotations provided, the description carries the full burden. It adds crucial behavioral context by explaining that 'Position Value USD is current marked value, not final payout' and that 'Cost Basis USD and Unrealized PnL USD apply to the displayed row only — not the wallet's total PM activity.' This scope clarification prevents misinterpretation of the data.

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 optimally structured with a clear opening statement, bulleted Key fields section, and Prerequisites callout. Every sentence serves a purpose—defining the operation, explaining output field semantics, or specifying tool sequencing. No redundant text is present.

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

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

Given that an output schema exists, the description appropriately focuses on explaining the semantic meaning of key output fields (e.g., distinguishing marked value from final payout) rather than return structure. It covers the critical workflow prerequisite. It could slightly improve by explicitly mentioning pagination behavior, but remains complete 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?

Given the context signal indicates 0% schema description coverage, the description partially compensates by referencing `marketId` in the prerequisites section and explaining it can be obtained from `prediction_market_screener`. However, it fails to mention the `page` parameter for pagination, leaving a gap in parameter documentation.

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

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

The description opens with 'Detailed position breakdown for a Polymarket market,' providing a specific verb (breakdown) and resource (Polymarket market position). It clearly distinguishes this tool from siblings like prediction_market_lookup (finding markets) and prediction_market_screener (listing markets) by focusing on position-level detail.

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 an explicit Prerequisites section stating: 'If `marketId` is unknown, call `prediction_market_lookup` first.' This provides clear sequencing guidance and identifies the specific sibling tool to use as an alternative when the required parameter is missing.

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?

No annotations provided, so description carries full burden. Discloses literal-style matching (not fuzzy), query construction constraints (short fragments, no topic bundling), and output interpretation rules (superlatives must match shown metric, don't infer rankings from titles). Does not mention rate limits or error states, but covers core behavioral logic thoroughly.

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 clear markdown sections (When to use, Query tips, Output rules). Front-loaded purpose statement. Every sentence provides actionable guidance without redundancy. Appropriate length for the complexity of the tool.

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 presence of output schema (per context signals), description appropriately avoids explaining return values. Covers discovery modes, query syntax constraints, and output interpretation rules sufficiently for a screening tool. Would benefit from brief mention of pagination behavior or rate limits, but otherwise complete.

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

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

Context signal indicates 0% schema description coverage (top-level 'request' parameter lacks description). Description partially compensates by mapping concepts to parameters: mentions markets/events/categories (mode), query tips (query), and sorting (orderBy). However, does not explain 'page' or 'status' parameters explicitly, relying on the nested schema descriptions which may not be visible to the agent.

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 specific verbs 'Browse and sort' and clear resource 'Polymarket markets, events, or categories.' Explicitly distinguishes from sibling tool `prediction_market_lookup` in the 'When to use' section, clarifying this is for broad discovery versus single-market resolution.

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?

Contains explicit 'When to use' section with clear affirmative case ('Broad discovery, screening, and ranked browsing') and negative case ('Do NOT use this to resolve one named market...'). Explicitly names the correct alternative tool (`prediction_market_lookup`) for the excluded use case.

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 no annotations provided, the description carries the full burden. It excels by explaining semantic nuances of the output (**Key fields** clarifies positions vs. notional, marked value vs. payout) and limitations (**Pitfalls** warns about partial row visibility and source of truth). Deducted one point for not mentioning if data is real-time or cached.

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?

Excellent structure with bold headers (**Key fields**, **Pitfalls**, **Prerequisites**) enabling rapid scanning. Every sentence serves a distinct purpose—defining scope, explaining output interpretation, or guiding prerequisites. No redundant or filler text.

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 appropriately focuses on explaining output field semantics and interpretation pitfalls rather than return values. It covers the critical prerequisite chain for the required parameter. Minor deduction for not addressing potential rate limits or authentication requirements that might affect behavior.

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?

Context signals indicate 0% schema description coverage. The description partially compensates by providing prerequisite guidance for `marketId` (where to obtain it), but fails to explain pagination (`page`) or sorting (`orderBy`, `orderByDirection`) semantics in the description text, leaving a significant gap given the reported lack of schema coverage.

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 opens with a specific, unambiguous statement: 'Largest current holders for a Polymarket market.' This clearly identifies the verb (holders/largest), resource (Polymarket market), and distinguishes it from siblings like `token_current_top_holders` (generic) and `prediction_market_address_pnl` (address-centric).

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 states prerequisites: 'If `marketId` is unknown, call `prediction_market_lookup` first,' providing a clear decision tree. The **Pitfalls** section further guides interpretation by warning against inferring risk or smart-money status without explicit data, preventing misuse.

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 no annotations provided, the description carries the full burden. It adds valuable behavioral context through '**Key fields:**' (explaining that `Share Size` is quantity and `Value USD` applies per row/leg) and '**Pitfalls:**' (warning that large visible trades don't indicate smart money). It lacks explicit mention of read-only safety or rate limits, but the content provided is substantive behavioral guidance.

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 uses markdown headers effectively ('When to use', 'Key fields', 'Pitfalls', 'Prerequisites') to structure information densely without fluff. Every sentence serves a specific purpose—defining scope, distinguishing siblings, explaining data semantics, or warning about misinterpretation. 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 presence of an output schema, the description appropriately focuses on usage guidelines and data interpretation rather than return values. It successfully covers prerequisites, sibling differentiation, and field-level semantics. A minor gap remains regarding pagination behavior or potential rate limiting, but overall it provides sufficient context for a data retrieval tool of this complexity.

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

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

Context signals indicate 0% schema description coverage. The description compensates partially by referencing `marketId` in the Prerequisites section and explaining it should be obtained from `prediction_market_screener`. However, it fails to mention the `page` parameter or explain the complex date range tokens (NOW, XMIN_AGO, etc.) available in the `dateRange` parameter, leaving significant semantic gaps despite the schema's default handling.

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 'Recent trades for a Polymarket market' and distinguishes itself from sibling `prediction_market_ohlcv` by explicitly stating 'Do not overwrite recent trade prices with older OHLCV candles.' It also references related siblings (`prediction_market_lookup`, `prediction_market_screener`) to establish workflow context.

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 '**When to use:**' section explicitly defines when to use this tool ('Source of truth for recent fills') and when not to use it (vs. OHLCV candles). The '**Prerequisites:**' section provides clear sequencing guidance to call `prediction_market_lookup` first if the marketId is unknown, offering explicit alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read operation (implied by 'Get'), specifies data source (Hyperliquid perpetual futures), notes limitations (recent trades only, no date filtering), and details the output format (columns returned). However, it doesn't mention potential rate limits, authentication needs, or pagination details (though 'page' parameter hints at it), leaving some gaps.

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 and appropriately sized, with clear sections (purpose, usage note, columns, sorting, examples). Most sentences add value, such as distinguishing from alternatives and explaining limitations. It could be slightly more concise by integrating the 'Note' into the main text, but overall it's efficient and front-loaded with key information.

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

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

Given the tool's complexity (multiple parameters, no annotations, but has output schema), the description is largely complete. It covers purpose, usage, behavioral traits, and parameter examples, and the output schema handles return values. However, it lacks details on error handling, rate limits, or full parameter explanations, which could enhance completeness for a tool with 0% schema coverage.

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

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

The schema description coverage is 0%, so the description must compensate. It adds significant value by explaining sorting options with examples (e.g., 'order_by' and 'order_by_direction'), providing filter examples (e.g., 'action', 'side', 'includeSmartMoneyLabels'), and listing columns returned, which clarifies output semantics. However, it doesn't detail all parameters like 'valueUsd' range filtering or 'traderAddress', leaving some schema elements uncovered.

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

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

The description clearly states the tool's purpose: 'Get recent Hyperliquid perpetual futures trades from Smart Traders and Funds across all tokens.' It specifies the verb ('Get'), resource ('trades'), and scope ('recent', 'Hyperliquid perpetual futures', 'Smart Traders and Funds', 'across all tokens'), and distinguishes it from sibling tools like token_discovery_screener by noting this provides granular activity versus a big picture view.

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 provides usage guidelines: it states when to use this tool (for granular smart trader and funds activity) and when to use an alternative (token_discovery_screener for a big picture view). It also notes limitations like 'Hyperliquid-only' and 'no date filtering available,' helping users understand its context and constraints.

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 no annotations provided, the description carries full burden for behavioral disclosure. It mentions aggregation (not per wallet) and chain-level data, which is useful. However, it doesn't describe pagination behavior (though 'page' parameter exists), rate limits, authentication requirements, error conditions, or what 'aggregated' means precisely (sums, averages?). For a data query tool with complex filtering, this leaves significant gaps.

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 appropriately concise (two sentences) and front-loaded with core functionality. The first sentence covers purpose, scope, and key constraints; the second mentions filtering. No wasted words, though it could be slightly more structured (e.g., bullet points for exclusions).

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 (1 top-level parameter with 8+ nested fields, no annotations, but with output schema), the description is minimally adequate. It covers what data is returned (aggregated balances and 24h change) and basic scope (chains, exclusions), but lacks details on parameter semantics, behavioral traits, and relationship to sibling tools. The output schema existence means return values needn't be described, but other gaps remain.

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 0%, so the description must compensate. It mentions chains parameter (default ['all'], specific chains) and filtering, but doesn't explain any of the 8+ nested parameters (page, orderBy, minHolders, includeStablecoin, etc.) or the SMLabel enum values. The description adds minimal value beyond what's inferable from parameter names 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 the tool's purpose: 'Get aggregated... smart trader and fund token balances and 24h change per chain.' It specifies what is included (smart traders and funds) and excluded (whales, large holders, influencers), and mentions filtering capabilities. However, it doesn't explicitly differentiate from sibling tools like 'smart_traders_and_funds_perp_trades' or 'token_current_top_holders' beyond the exclusion list.

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 some usage context by mentioning default behavior (['all'] chains) and that filters can narrow results. It excludes certain entity types (whales, etc.), which helps define scope. However, it doesn't explicitly state when to use this tool versus alternatives like 'token_current_top_holders' or 'smart_traders_and_funds_perp_trades', nor does it mention prerequisites or typical use cases.

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 no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It specifies pagination limits (25 per page), mode-specific behaviors, sorting options, error conditions (native token restrictions), and explicitly lists what data is returned in each mode. The only minor gap is it doesn't mention rate limits or authentication requirements.

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 clear sections (Note, Modes, Columns, Sorting, Examples, Restrictions), but it's quite long with extensive examples that could be trimmed. While informative, some redundancy exists (e.g., multiple similar examples), and the core purpose gets somewhat buried. Every sentence adds value, but the overall length reduces scannability.

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 (two distinct modes, many parameters, no annotations), the description is remarkably complete. It covers purpose, usage, parameters, output format (detailed column lists), restrictions, and provides comprehensive examples. With an output schema present, it appropriately focuses on explaining what the tool does rather than return value details. No significant 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?

With 0% schema description coverage and 1 parameter (a complex nested object), the description comprehensively compensates. It explains all key parameters through examples, details mode-specific behaviors, documents default values, lists sorting options, and provides extensive examples showing how to use filters and different configurations. This adds substantial meaning beyond the bare 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's purpose: 'Get upto 25 (per page) top holders information for a specific token.' It specifies the resource (token holders), scope (top holders, paginated), and distinguishes from siblings by focusing on current holdings rather than historical data, flows, or portfolio analysis.

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 guidance on when to use alternatives: it warns against using 'labelType: smart_money' as a proxy for market view and specifies when it's appropriate. It also distinguishes between two modes (onchain_tokens vs perps) with clear use cases, and mentions restrictions for native tokens that guide when not to use certain parameters.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns markdown-formatted DEX trading activity, returns an empty string if no trades are found, details common and mode-specific columns, and explains sorting options. It also clarifies default values (e.g., mode defaults to 'onchain_tokens', chain defaults to 'ethereum' for onchain_tokens). However, it does not mention rate limits, authentication needs, or error handling.

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 sections for modes, arguments, returns, columns, sorting, and examples. It is front-loaded with the core purpose, but it is lengthy due to detailed examples and column descriptions. Every sentence adds value, but it could be more concise by reducing example verbosity while maintaining clarity.

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 modes, many parameters), no annotations, and 0% schema description coverage, the description is highly complete. It covers purpose, usage, parameters, output format, and behavioral details. With an output schema present, it appropriately focuses on explaining the markdown return format and columns without needing to detail return values exhaustively.

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 0% description coverage, so the description must compensate fully. It does so excellently by explaining the 'request' parameter's structure, detailing modes, providing comprehensive examples with parameter usage, and describing filtering and sorting options. This adds significant meaning beyond the bare schema, making parameters understandable and actionable.

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

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

The description clearly states the tool's purpose: 'Get DEX trades for a specific token.' It specifies the verb ('Get'), resource ('DEX trades'), and target ('specific token'), and distinguishes itself from siblings by focusing on DEX trades rather than other token or address analyses like 'token_ohlcv' or 'address_transactions'.

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 usage context by detailing two modes ('onchain_tokens' and 'perps') with examples, but it does not explicitly state when to use this tool versus alternatives like 'smart_traders_and_funds_perp_trades' or 'token_who_bought_sold'. The examples imply use cases like 'whale watching' and 'price analysis', offering practical guidance.

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

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

With no annotations provided, the description carries full burden and delivers extensive behavioral disclosure. It explains result limits (max 25 results), chain limits (max 5, excess trimmed), timeout risks, Hyperliquid special case behavior, filter/orderBy field support differences, default sorting, and critical warnings about filter usage. It also describes the two-section return format when mixing Hyperliquid with other chains.

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 clear sections (purpose, important notes, examples, warnings, returns, filtering/sorting details) but is quite lengthy. While every section adds value, some redundancy exists between examples and filtering explanations. It could be more concise while maintaining clarity.

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 (many parameters, special cases, filtering logic) and the presence of an output schema, the description is exceptionally complete. It covers purpose, usage guidelines, behavioral constraints, parameter semantics, return format explanation, and edge cases. The output schema handles return structure, allowing the description to focus on operational guidance.

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?

Despite 0% schema description coverage, the description comprehensively documents parameter semantics. It provides detailed filtering options with numeric ranges and categories, sorting options with valid fields, critical warnings about invalid filters, and 7 practical input examples showing parameter usage. The description fully compensates for the schema's lack of parameter 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: 'Get comprehensive token screening data across multiple blockchain networks with advanced filtering' and 'helps with token discovery and finding trending tokens by combining different metrics'. It specifies the resource (token screening data) and distinguishes it from siblings by focusing on multi-chain token discovery with filtering/sorting capabilities.

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 usage guidance including when to use specific filters (e.g., 'Use ONLY when user explicitly asks for "smart money"'), when to avoid certain configurations (e.g., 'To avoid timeouts, it's recommended to use 4 chains or less'), and clear alternatives for achieving goals (e.g., 'priceChange' is NOT a valid filter - use orderBy instead). It also distinguishes Hyperliquid perps from spot tokens.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it does not support native tokens in 'onchain_tokens' mode, explains the two modes ('onchain_tokens' and 'perps') and their differences (e.g., 'In perps mode: Shorts that are added will show with a negative sign'), and notes it tracks 'Smart Money' holders. However, it lacks details on rate limits, authentication needs, or error handling.

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 clear sections (e.g., 'Modes:', 'Args:', 'Returns:', 'Notes:') and uses bullet points for readability. It is appropriately sized, but some sentences could be more concise (e.g., the note on 'smart_money' is verbose). Overall, it efficiently conveys necessary information without excessive fluff.

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

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

Given the tool's complexity (multiple modes, segments, and an output schema), the description is largely complete. It explains the tool's purpose, usage guidelines, behavioral traits, parameters, and output format. The presence of an output schema reduces the need to detail return values, but the description still adds valuable context about modes and segments. Minor gaps include lack of error handling or rate limit info.

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

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

The schema description coverage is 0%, so the description must compensate. It adds significant semantic context: it explains the 'holder_segment' options (Top 100 holders, Whale, Public Figure, Smart Money, Exchange) and their implications, describes the two 'mode' options and their behaviors, and outlines the columns returned in the output. While it doesn't detail all parameters (e.g., 'chain' or 'dateRange' formats), it provides essential context beyond the bare 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's purpose: 'Get hourly aggregated token flows for a specific segment of holders over a date range.' It specifies the action ('Get'), resource ('token flows'), and scope ('hourly aggregated,' 'specific segment of holders,' 'date range'). It explicitly distinguishes itself from sibling tool 'token_recent_flows_summary' by noting it is 'more granular' and provides 'TOTAL flows over the entire time frame broken down by segment.'

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 guidance on when to use this tool versus alternatives. It states it is 'more granular' than 'token_recent_flows_summary' and warns against using 'smart_money' as a proxy for overall market view, specifying to use it only if explicitly requested or combined with other data. It also notes that 'token_recent_flows_summary' is a sibling tool, implying an alternative for less granular data.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains what data is returned in each mode, mentions the return format (markdown), and clarifies parameter usage differences between modes. It could improve by addressing potential limitations like rate limits or data 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?

The description is well-structured with clear sections (purpose, modes, returns, fields, examples, notes) and front-loads the core functionality. While comprehensive, some redundancy exists (e.g., field lists could be more concise), and every sentence earns its place by adding value.

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

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

Given the tool's complexity (dual modes with different data types), no annotations, and the presence of an output schema, the description provides complete context. It thoroughly explains both operational modes, parameter usage, return data structure, and includes practical examples—compensating fully for the lack of annotations and schema descriptions.

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?

Despite 0% schema description coverage, the description comprehensively explains all parameter semantics: it clarifies that 'mode' selects between two analysis types, 'chain' specifies blockchain network, 'timeframe' controls lookback period, and 'tokenAddress' accepts either contract addresses or symbols depending on mode. The examples provide concrete usage patterns.

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 with specific verbs ('Get token information') and distinguishes between two distinct modes (on-chain tokens and Hyperliquid perps). It explicitly differentiates from siblings by focusing on comprehensive token/perpetual futures stats rather than transactions, balances, or other token-related operations.

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 when to use each mode (on-chain tokens vs. perps) with specific parameter requirements (contract addresses vs. symbols). However, it doesn't explicitly state when NOT to use this tool or mention alternatives among the many sibling tools, which prevents a perfect score.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the automatic resolution logic based on date ranges, details the columns returned (including additional market cap columns when includeMarketCap=true), provides format specifics like timestamp format, and includes multiple concrete usage examples. This gives comprehensive behavioral context beyond basic functionality.

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 comprehensive but lengthy, with multiple sections (purpose, chain limitations, usage mandate, resolution rules, columns, examples). While all content is valuable, it could be more front-loaded; the critical 'YOU MUST USE THIS' guidance appears after chain limitations. The examples section is particularly extensive but provides necessary concrete usage patterns.

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 (automatic resolution logic, multiple output columns, chain restrictions) and the absence of annotations, the description provides complete context. It explains behavioral characteristics, output format, parameter usage with examples, and important limitations. The existence of an output schema reduces the need to fully document return values, and the description adequately covers what's needed for effective tool invocation.

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

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

The schema description coverage is 0%, so the description must compensate. It provides substantial parameter context: explains the date range parameter usage with specific examples ('5MIN_AGO', 'NOW', '7D_AGO'), mentions chain and tokenAddress parameters in examples, and explains the includeMarketCap parameter's effect on additional columns. However, it doesn't explicitly document all parameter names or their required status.

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

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

The description clearly states the tool's purpose: 'Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution.' It specifies the exact resource (token price data) and operation (get OHLCV), and explicitly distinguishes it from sibling 'general_search' by noting that tool provides delayed/incorrect prices.

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 usage guidance: 'YOU MUST USE THIS over `general_search` to get prices' and 'To get LATEST price set from to '5MIN_AGO' and to to 'NOW'.' It also specifies chain limitations: 'chain=Hyperliquid is a perps chain AND IS NOT supported' and 'ENDPOINT ONLY SUPPORTS EVM CHAINS AND SOLANA.' This gives clear when-to-use and when-not-to-use instructions.

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 no annotations provided, the description carries full burden and does an excellent job disclosing key behavioral traits: it specifies the 25-result limit ('ONLY RETURNS TOP 25 RESULTS'), explains return format ('Returns empty string if no trading data found'), describes output format ('Trader performance rankings as markdown'), and notes important constraints ('does not support native tokens', 'does not support hyperevm as chain'). It could improve by mentioning rate limits or authentication requirements, but covers most critical behavioral aspects.

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 clear sections (Modes, Returns, Columns, Sorting, Filtering, Examples, Notes) but is quite lengthy. While every section adds value, some redundancy exists (e.g., repeating 'currency formatted' multiple times). The core purpose is stated upfront, and technical details are organized logically, but it could be more concise by removing some formatting repetitions.

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 modes, extensive filtering/sorting options) and 0% schema description coverage, the description provides exceptional completeness. It covers purpose, usage scenarios, behavioral constraints, parameter details with examples, output format with column descriptions, and important limitations. The presence of an output schema means the description doesn't need to explain return values in depth, and it appropriately focuses on usage guidance and constraints.

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 0% schema description coverage and only 1 parameter ('request'), the description must fully explain parameter semantics, which it does comprehensively. It details the two modes, explains filtering and sorting options with specific field names, provides multiple complete examples showing parameter usage, and clarifies constraints like chain support and token address formats. The description adds substantial value beyond the bare 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's purpose: 'Upto 25 results (per page) of trader PnL for a token' - specifying the verb (finding/ranking), resource (trader PnL), and scope (for a specific token). It distinguishes from siblings like 'hyperliquid_leaderboard' (which appears to be platform-specific) and 'wallet_pnl_for_token' (which focuses on individual wallets rather than rankings).

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 guidance on when to use this tool: 'Useful for identifying successful traders and copying strategies' and 'Both ascending and descending sorts provide valuable insights (winners vs losers).' It also distinguishes from alternatives by specifying modes ('onchain_tokens' vs 'perps') and explicitly notes what it doesn't support (native tokens, hyperevm chain). The examples show concrete use cases for different 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (risk/reward indicators as markdown with interpretation guidance) and includes important notes on limitations (e.g., 'Not all indicators available for every token/chain combination'). However, it lacks details on potential errors, rate limits, authentication needs, or data freshness, which are critical for a data-fetching tool.

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 and front-loaded with the core purpose, followed by usage guidelines, return details, and notes. Most sentences add value, such as explaining indicator types and percentiles. However, some sections (e.g., listing all indicator types) could be more concise, and the 'Returns:' header is slightly 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?

Given the tool's complexity (fetching detailed quantitative scores), no annotations, and an output schema exists (which likely covers return structure), the description does a fair job by detailing returned fields and limitations. However, it lacks crucial context like parameter explanations, error handling, and data sources, making it incomplete for safe and effective use.

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

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

The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description does not mention or explain the parameters ('request' with 'chain' and 'tokenAddress'), leaving their semantics unclear. It fails to compensate for the schema gap, as users must infer usage from context 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 the tool 'Get[s] Nansen Score Indicators for a token - quantitative risk and reward signals,' specifying the verb ('Get'), resource ('Nansen Score Indicators'), and purpose ('quantitative risk and reward signals'). It distinguishes from siblings like 'token_info' or 'token_ohlcv' by focusing on risk/reward metrics, though it could more explicitly contrast with 'nansen_score_top_tokens' (which likely lists tokens rather than details for one).

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 guidance on when to use the tool: 'when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions.' This clearly defines the context and use cases. However, it does not specify when not to use it or name alternatives (e.g., 'token_info' for basic data), which prevents a perfect score.

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 no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains what the tool returns (categorized token flow analysis as markdown with specific metrics), defines positive/negative flow meanings for different segments, describes how values are aggregated over lookback periods, and includes important limitations (Bitcoin/Hyperliquid not supported). The only minor gap is lack of explicit rate limit or authentication requirements.

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 clear sections (purpose, usage guidance, returns format, notes). While comprehensive, some sentences could be more concise (e.g., the returns format explanation is somewhat verbose). The information is front-loaded with the core purpose and key differentiators from token_flows appearing early.

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 (analyzing token flows across multiple segments), no annotations, 0% schema description coverage, but with an output schema present, the description provides excellent contextual completeness. It explains the tool's purpose, when to use it versus alternatives, what it returns, how to interpret results, and important limitations. The output schema handles return value structure, so the description appropriately focuses on semantic context.

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 0% schema description coverage and only 1 parameter (though nested with chain, tokenAddress, and lookbackPeriod), the description adds significant value by explaining the lookback period concept: 'The values provided are aggregated over the specific lookback period (last 5min, 1d, 7d etc) specified.' However, it doesn't explain the chain or tokenAddress parameters, leaving some semantic 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?

The description explicitly states the tool's purpose: to get total token flows per segment (Public Figures, Top PnL Traders, etc.) with aggregated inflow/outflow data over a lookback period. It clearly distinguishes from sibling 'token_flows' by specifying this tool provides aggregated summaries while token_flows offers granular hourly breakdowns with exact date filtering.

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 guidance on when to use this tool versus alternatives. It states: 'If you have SPECIFIC date ranges in mind, use `token_flows` instead' and 'Use `token_flows` for more granular data as it can filter between exact dates and provides HOURLY breakdowns.' It also includes exclusion notes about Bitcoin and Hyperliquid not being supported.

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 no annotations provided, the description carries full burden and excels. It discloses pagination behavior (25 per page), sorting options, default values, native token exclusion, column details, and filter behaviors. It thoroughly describes what the tool returns and how filters work, covering all critical behavioral aspects.

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 comprehensive but lengthy, with extensive examples and filter documentation that could be streamlined. While well-structured with sections (Columns, Sorting, Examples, Filters), it includes repetitive details that might overwhelm. Every sentence adds value, but overall length reduces conciseness.

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 filters, sorting, pagination) and lack of annotations, the description is exceptionally complete. It covers purpose, usage, parameters, behavior, and output details. With an output schema present, it appropriately focuses on input semantics and operational context, leaving return values to the schema.

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

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

Schema description coverage is 0%, so the description must compensate fully. It does so excellently: it explains all parameters (chain, tokenAddress, dateRange, filters like fromAddress, transferOriginCategories, etc.), provides detailed examples, clarifies default values, and documents complex objects like transferValueUsd ranges. No parameter meaning is left unexplained.

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

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

The description clearly states the tool's purpose: 'Get 25 token transfers (per page) for a specific token based on the sort order.' It specifies the verb ('Get'), resource ('token transfers'), and key constraints (pagination, token-specific). It distinguishes from siblings like 'token_flows' or 'token_dex_trades' by focusing on transfers rather than trades or flows.

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 usage with examples and filters, but does not explicitly state when to use this tool versus alternatives like 'address_transactions' or 'token_dex_trades'. It mentions 'This tool does not support native tokens', which is a useful exclusion, but lacks direct sibling comparison.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it aggregates trading activity within a time range, returns data as markdown, specifies columns and sorting options, and notes that it returns an empty string if no data is found. However, it lacks details on rate limits, authentication needs, or error handling, which are important for a data query tool.

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 and front-loaded with the core purpose. It uses bullet points for returns and notes efficiently, but includes some redundancy (e.g., repeating 'Aggregates' in Notes after stating it earlier). Overall, it's concise with minimal waste, though could be slightly tighter.

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 (querying DEX trading data) and no annotations, the description does a good job covering purpose, usage, output format, and key behaviors. With an output schema present, it appropriately avoids detailing return values. However, it could improve by addressing parameters more thoroughly and mentioning potential limitations like data availability.

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

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

The schema description coverage is 0%, so the description must compensate. It mentions the 'buy_or_sell' parameter and implies a time range, but does not detail other parameters like 'chain', 'tokenAddress', or optional filters. While it adds some context (e.g., filtering for net buyers/sellers), it does not fully explain the parameter set, leaving gaps in understanding.

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

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

The description clearly states the tool's purpose: 'Get TOTAL amount of tokens bought/sold by address for a token on DEX (Decentralised Exchanges) ONLY.' It specifies the verb ('Get'), resource ('tokens bought/sold by address'), and scope ('on DEX ONLY'), distinguishing it from siblings like token_transfers or token_flows that might cover broader transaction types.

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

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

The description explicitly states when to use this tool: 'Use this tool to find out WHO is buying or selling a token (on DEX) AND then you can check if they are liquidating profits or accumulating more.' It provides a clear use case and distinguishes it from alternatives by focusing on DEX-specific trading analysis, unlike siblings such as token_info or token_ohlcv.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive transaction details' and 'token transfers,' but fails to describe key traits: whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what 'comprehensive' entails. For a tool with no annotations, this is a significant gap in transparency.

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 appropriately sized and front-loaded, with the core purpose stated first. The 'Args' and 'Returns' sections add structure, though 'Args' could be more concise by integrating with the purpose statement. There's no wasted text, but minor improvements in flow could enhance clarity.

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 (single parameter, no annotations, but with an output schema), the description is partially complete. It covers the purpose and return format, but lacks behavioral context and usage guidelines. The output schema existence means it doesn't need to detail return values, but other gaps prevent a higher score.

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 description references 'TransactionLookupRequest containing parameters and pagination settings,' but the input schema only shows one required parameter ('transaction_hash') with 0% schema description coverage. This adds minimal semantics beyond the schema, implying pagination settings that aren't in the schema, which could be confusing. With low schema coverage, the description doesn't adequately compensate, resulting in a baseline score.

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

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

The description clearly states the tool's purpose: 'Get comprehensive transaction details including token transfers.' It specifies the verb ('Get') and resource ('transaction details'), and distinguishes it from siblings like 'address_transactions' or 'token_transfers' by focusing on a single transaction's details. However, it doesn't explicitly differentiate from 'prediction_market_lookup' or other lookup tools, keeping it from a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a transaction hash), exclusions, or compare it to sibling tools like 'address_transactions' (for address-level data) or 'token_transfers' (for token-specific transfers). This leaves the agent without context for tool selection.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool does (get PnL stats) but lacks details on behavioral traits such as required permissions, rate limits, data freshness, error handling, or what the output contains. For a tool with no annotations and an output schema, this leaves significant gaps in understanding how it behaves beyond basic functionality.

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 appropriately sized and front-loaded, with two sentences that directly state the purpose and usage. There is no wasted text, and it efficiently conveys the core information. However, it could be slightly more structured by explicitly listing key parameters or differentiating from siblings, which prevents a perfect score.

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 (involving PnL calculations for tokens), no annotations, and an output schema, the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral aspects and parameter semantics. The presence of an output schema means return values are documented elsewhere, but the description doesn't fully compensate for missing annotations and low schema coverage.

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 description does not add any meaning beyond what the input schema provides. It mentions 'specific token', 'input address', and 'date range', but these are already covered by the schema's parameters (e.g., 'tokenAddress', 'walletAddress', 'dateRange'). With a schema description coverage of 0%, the description fails to compensate for the lack of schema documentation, leaving parameters semantically unclear.

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

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

The description clearly states the tool's purpose: 'Get PnL stats for a specific token traded by the input address during a specific date range.' It specifies the verb ('Get'), resource ('PnL stats'), and scope ('specific token', 'input address', 'date range'). However, it doesn't explicitly differentiate from sibling tools like 'wallet_pnl_summary' or 'token_pnl_leaderboard', which prevents a perfect score.

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

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

The description provides implied usage guidance: 'Use this tool for analysing the performance of the wallet for the specific token over a time period.' This suggests when to use it (for token-specific wallet performance analysis) but doesn't explicitly state when not to use it or name alternatives among siblings (e.g., 'wallet_pnl_summary' for aggregated PnL). It offers basic context 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool returns aggregate stats (not detailed transactions), focuses on realized PnL only, and requires a time period. However, it lacks details on permissions, rate limits, data freshness, or error conditions. The description doesn't contradict annotations (none exist), but could be more comprehensive for a tool with financial implications.

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 reasonably concise (4 sentences) but has structural issues. The first sentence clearly states the purpose, but the second and third sentences are repetitive about unrealized PnL. The last two sentences reiterate 'analyze performance' without adding new information. Some sentences could be merged or eliminated for better front-loading.

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 (financial analysis tool), lack of annotations, and 0% schema coverage, the description is moderately complete. It covers the core purpose and exclusions but lacks parameter details, error handling, and output expectations. The presence of an output schema helps, but the description should do more to guide usage in this data-rich context.

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 0%, so the description must compensate. It mentions 'input address' and 'time period,' which map to the required parameters (walletAddress and dateRange), but provides no details on parameter formats, constraints, or the optional 'chain' parameter. The description adds minimal semantic value beyond what's implied by the tool name and context.

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

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

The description clearly states the tool's purpose: 'Get aggregate stats of overall realized PnL for the input address.' It specifies the verb ('Get'), resource ('aggregate stats'), and scope ('realized PnL'), distinguishing it from tools like 'wallet_pnl_for_token' which focuses on token-specific PnL. However, it doesn't explicitly differentiate from all sibling tools beyond the PnL context.

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 when to use this tool: 'Use this tool for analysing the performance of the wallet over a time period.' It explicitly excludes unrealized PnL and suggests alternatives ('For unrealized PnL you need to check change in token prices of the current holdings.'). However, it doesn't specify when to choose this over other wallet analysis tools like 'address_portfolio' or 'address_historical_balances'.

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