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

Given the absence of annotations, the description compensates well by disclosing key behavioral traits: pagination (25 per page), default sort by net value, top 3 tokens per counterparty, and the 365-day time range clamp with reporting. It also details sorting fields and directions. Minor omissions include error handling, authentication needs, and rate limits, but the core behavior is transparent.

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

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

The description is well-structured with a clear main purpose statement, a note section, sorting options, and two examples. It is front-loaded but slightly verbose in the note section. However, all content is relevant and earns its place, making it efficient for an agent to parse.

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

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

The description covers the essential aspects of the tool: input parameters, relationship between counterparties, pagination, sorting, time range constraints (with clamping), and examples. With an output schema available, the return value details are covered. It lacks only rare edge cases and error scenarios, but overall it is complete for an agent to use 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?

Despite the input schema having property descriptions, the tool description adds substantial meaning beyond the schema. It explains the purpose of each parameter (e.g., 'address' vs 'entity_id', time range tokens), provides default values and sorting options, and includes comprehensive examples that demonstrate usage. This compensates for any lack of schema description 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 clearly states the tool's purpose: 'Get 25 (per page) addresses or entities with the most common interactions with input addresses'. It specifies the resource (addresses/entities), the action (get counterparties), and the scope (most common interactions). The inclusion of default sorting and top 3 tokens further clarifies the output. The examples provide concrete use cases, distinguishing it from siblings like 'address_related_addresses' by focusing on counterparties based on interaction volume.

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 'Note' section provides explicit guidance on when and how to use the tool, including strategies for exploring related wallets and emphasizing relationship over address structure. Sorting options and examples help the agent choose appropriate parameters. However, it does not explicitly contrast with sibling tools like 'address_related_addresses' or 'address_transactions', so the agent must infer when this tool is preferred over 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 describes output columns, sorting options, and filtering by valueUsd range. It includes a concrete example. However, it does not explicitly mention pagination behavior, rate limits, or what happens if no trades are found, which would make it more transparent.

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 well-structured: it starts with a clear purpose, then covers chain guidelines, output columns, sorting/filtering options, and ends with an example. Every sentence adds necessary information without redundancy.

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

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

Given the tool's complexity (multiple parameters, chain nuances, output columns), the description provides complete context. It covers all key behaviors: single-chain requirement, auto-detection for non-EVM, column details, sorting and filtering, and a representative example. The output schema exists but the description still clarifies what the data looks like.

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 adds meaning beyond the schema by explaining the chain parameter with EVM/non-EVM rules, sort order interpretation, and filtering context. The schema already has good descriptions for most parameters, but the description provides practical usage examples and clarifies default behavior. The 0% schema coverage statistic seems inconsistent with the actual schema content; regardless, the description adds value.

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 a wallet's individual DEX trades (token swaps) on a single chain' with specific details about bought/sold token pair, amounts, and USD value. It also distinguishes from sibling tool token_dex_trades by labeling it as wallet-centric vs token-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?

The description provides explicit usage guidelines: it explains when to use this tool (wallet-centric), contrasts with token_dex_trades, specifies chain limitations (one per call, 'all'/'evm' unsupported), and gives instructions for EVM vs non-EVM wallets. It also advises to call once per chain for multiple networks.

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 must disclose behavioral traits. It only states the return type (balances) but does not mention that the tool is read-only, any authentication needs, rate limits, or restrictions on address count. This is insufficient for complex parameters.

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

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

The description is a single sentence of 6 words, making it concise. However, it is so brief that it sacrifices essential information, which is under-specification rather than effective 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 parameter options, filtering, lookback period), the description is highly incomplete. While an output schema exists, the description fails to cover key aspects like entity ID support or suspicious token filtering.

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?

Per context, schema description coverage is 0%. The description adds no parameter semantics, failing to explain that users can specify a single address, multiple addresses, or an entity_id, nor does it mention the lookbackDays or suspiciousFilter options. Without schema descriptions, this is a critical 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 verb 'Get' and the resource 'historical native coin & token balances' for an address, distinguishing this tool from siblings like address_portfolio or address_transactions. However, it could be more specific about the scope (e.g., 'for a given address over a specified lookback period').

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 address_portfolio or address_transactions. No mention of prerequisites, exclusions, or 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?

The description clearly states that output is pre-formatted markdown to be presented exactly as returned, and it mentions that hyperliquid positions include liquidation prices. It also describes the behavior for different modes. No annotations are provided, so the description carries the full burden.

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

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

The description is well-structured with a clear purpose, bulleted modes, and examples. It is front-loaded and informative, though slightly verbose. Every sentence adds value, but it could be trimmed slightly without loss.

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 of the tool (multiple modes, mutual exclusions, output format), the description is comprehensive. It covers all major behaviors and constraints, and the examples cover the key usage patterns. The output schema exists, so return values need no further explanation.

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 adds extensive meaning beyond the schema: it explains each mode in detail, the mutual exclusivity of walletAddress and entity_id, and provides concrete examples with multiple request shapes. This compensates fully for the schema's lack of 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 portfolio overview for a wallet address or entity.' It details the different modes and what each returns, distinguishing it from sibling tools that focus on specific aspects like trades 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 explains the modes and the difference between wallet and entity queries, but it does not explicitly guide when to use this tool vs. alternative address-related tools. It implies usage but lacks explicit when-not-to-use or alternative recommendations.

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 responsibility. It discloses the specific connection types included and a key caveat about exchange withdrawal addresses. However, it does not mention potential error cases, rate limits, or what happens if no related addresses are found. The behavioral context is partially transparent but could be more comprehensive.

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 the main purpose and then provides a detailed note on included connections and caveats. It is mostly concise, though the note has minor typos ('the the', 'does usually NOT'). The structure is logical and information is well-organized.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers the scope, limitations, and alternative tools. However, it lacks information on how the tool handles addresses with no related special connections, and the complex input schema (anyOf) is not clarified. Overall, fairly complete.

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

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

Schema description coverage is 100%, with the input schema detailing the 'request' parameter including 'chain' and 'address'. The tool description adds no extra semantic information beyond what the schema provides. Baseline is 3, and the description does not enhance parameter understanding further.

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 information about related addresses of an input address, and provides a detailed list of the specific 'special' connections included. It distinguishes itself from the sibling tool 'address_counterparties' by mentioning that for other related wallets, one should check counterparties. The purpose is specific and actionable.

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

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

The description explicitly tells when to use this tool (for special connections) and when not to rely on it (first funder exchange withdrawal addresses often not belonging to same entity). It also directs the user to the sibling tool 'address_counterparties' for broader related wallets. This provides clear guidance on alternatives and limitations.

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 the description carries the full burden. It discloses pagination (20 per page) and date range filtering, but does not mention rate limits, error handling for invalid addresses, or that it is a read-only operation. Additional context would improve 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?

Two sentences with no redundant information, front-loading the key details (20 most recent, per page, date range).

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 does not need to explain return values. It covers the essential behavior (pagination, date filtering), but could mention default ordering (descending) or that the date range defaults to last 30 days (though that is in the schema).

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

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

The input schema has 0% description coverage per context, so the description adds value by clarifying the pagination limit (20 most recent) and that results are filtered by date range. This compensates for missing schema documentation.

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

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

The description clearly states the tool retrieves the 20 most recent transactions per page for a given address, using a date range. This verb+resource+scope distinguishes it from siblings like address_dex_trades or address_counterparties.

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?

No guidance on when to use this tool versus alternatives (e.g., address_dex_trades for DEX trades, transaction_lookup for a single transaction). The description does not mention exclusions or prerequisites.

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 fully discloses capabilities: it can check token existence, return price/volume/contract/market cap, search entities, resolve domains. It also clarifies limitations (no NFTs) and that it's for general search, not specialized queries.

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

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

The description is somewhat lengthy but well-structured with bullet points and clear sections. It front-loads the crucial exclusion of prediction markets. Every sentence adds value, though minor trimming could improve 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, high sibling count, and presence of an output schema, the description covers purpose, usage, parameter details, and exclusions comprehensively. An agent can confidently decide when to invoke this tool.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds extra context: chain parameter usage rules, max_results default and max, and clarifies that query should not include chain name. This value justifies a 4.

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 searches onchain data for tokens, entities, and addresses. It explicitly distinguishes itself from 'prediction_market_lookup' for prediction markets and notes it does not support NFTs, providing clear differentiation from sibling tools.

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

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

Provides explicit when-to-use (first entry point for general queries) and when-not-to-use (for prediction markets, use alternative). Also advises checking for NFTs despite no official support, and gives parameter guidance like not including chain name in the query string.

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 must fully disclose behavioral traits. It only states 'Get...' without detailing data freshness, pagination, aggregation methods, or any side effects. This is insufficient for a tool that likely performs data aggregation.

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

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

The description is a single sentence that conveys the core purpose without any unnecessary words. It is front-loaded and efficiently uses the 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 presence of an output schema (indicated), the description is adequate for a simple ranking retrieval tool. However, it lacks information about filtering, sorting, or interpretation of the metrics, which could be useful for an agent.

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

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

Schema coverage is 100%, so the schema already documents the parameters 'chain_type' and 'time_frame'. The description does not add additional meaning beyond listing the metrics in the output. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves chain growth rankings by active addresses, transactions, gas fees, and DEX volume. This is specific and distinguishes it from sibling tools that focus on individual addresses, tokens, 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 implies usage for growth rankings but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use it or context for preferred usage over siblings like 'token_discovery_screener' or 'address_transactions'.

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 exist, so the description carries full burden. It discloses the output format (markdown), column details, and sorting/filtering capabilities. It does not mention auth needs or rate limits, but as a read-only data retrieval, this is acceptable. Adds value beyond schema by listing columns and usage examples.

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 (Returns, Columns, Sorting/Filtering, Example, Notes). It is front-loaded with the purpose. While somewhat long, all content is relevant and earns its place.

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

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

Given the complexity of the schema (nested filtering objects) and the presence of an output schema, the description covers the main aspects: return format, column details, sorting/filtering, and an example. It does not explain the 'page' parameter or default behavior, but overall it is fairly complete.

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

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

Schema description coverage is effectively 100% (the schema includes descriptions for all properties of the 'request' object). The description adds meaning beyond the schema by explaining the columns returned, how to sort and filter (including an example), and the currency/percentage formatting. It provides context that aids parameter usage.

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

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

The description clearly states it retrieves the Hyperliquid perpetual futures trader leaderboard with performance metrics. It specifies the resource (Hyperliquid perp leaderboard) and the action (get), and distinguishes it from sibling tools like token_pnl_leaderboard by noting 'Hyperliquid-specific endpoint (perpetual futures only)'.

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 explains sorting and filtering options and provides an example, but does not explicitly state when to use this tool versus alternatives (e.g., when to use token_pnl_leaderboard instead). No when-not-to-use guidance is given.

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, but description discloses batch updates, pre-filtering threshold (performance_score >= 15), scoring ranges, and instructs AI to explain thresholds. Could add update frequency, but covers core safety and behavior well.

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-organized with headings and bullet points. Front-loaded with purpose. Slightly long but each section adds value; no wasted sentences.

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?

Output schema is described in detail (core fields, dynamic indicators). Instructions for AI to explain thresholds to user. Covers all aspects needed for a recommendation tool with good annotations absence.

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?

Only one parameter 'request' with optional marketCapGroup filter; description does not explain the full structure beyond example usage. Schema coverage is low, but description adds context that the request can be empty or with filter. Adequate given simplicity.

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?

Clearly states 'Discover and filter a daily list of attractive tokens using Nansen Score Indicators weighted by coefficients (= Performance Score).' Distinguishes from siblings by naming token_quant_scores and token_discovery_screener with explicit differentiators.

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

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

Explicitly says 'Use this tool when you don't know which tokens to buy' and contrasts with token_discovery_screener for live data or custom criteria. Provides example queries and clear when-to-use logic.

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 the description carries the burden. It adds value by clarifying that blank PnL fields mean unavailable data (not zero) and differentiating position size from value. However, it omits basic behavioral traits like whether the tool is read-only, has any side effects, or requires authentication.

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

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

The description is short and front-loaded with purpose. The key fields section is helpful but slightly verbose for a concise tool definition. Overall, every sentence contributes meaning without significant waste.

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

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

Given the presence of an output schema (as indicated by context signals), the description provides adequate explanation of return fields (blank semantics, position vs value). However, it completely ignores the input parameters, leaving a gap in understanding how to invoke the tool correctly.

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

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

The input schema has 0% parameter description coverage. The description does not mention the 'request' parameter or its nested properties (address, page). It provides no guidance on input format, leaving the schema to do all the work, which it does poorly due to lacking 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 provides a 'Prediction market PnL breakdown for a Polygon wallet' and explains key fields like market-by-market PnL, blank field semantics, and position size vs value. It distinguishes itself from sibling tools like prediction_market_address_summary or prediction_market_address_trades by focusing specifically on PnL.

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 lacks any guidance on when to use this tool versus its siblings. No mention of prerequisites, use cases, or when alternative tools like prediction_market_address_summary or prediction_market_address_trades would be more appropriate.

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

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

No annotations are provided, so the description must carry full burden. It discloses that blank PnL or ROI fields mean unavailable data, not zero, which is helpful. However, it omits other behavioral traits like required permissions, rate limits, data freshness, or error handling. Given the tool's simplicity, the disclosure is adequate but not rich.

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

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

The description is brief and well-structured, with two clear sections: a one-line purpose statement, a bulleted 'When to use' list, and a bulleted 'Key fields' list. Every sentence adds value without redundancy, and the most critical information is front-loaded.

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

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

The description covers usage guidelines and key return fields, but the lack of parameter explanation creates a gap. With an output schema present, return details are less critical, but an agent still needs to know how to form the request. The description does not fully equip an agent to call the tool correctly, leaving it moderately incomplete.

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 and a complex 'request' parameter. The description does not explain the structure of the request (e.g., that 'address' is required, 'page' is optional). It adds no meaning beyond the schema, which is inadequate for a tool with a parameter that has a nested object. The tool description should compensate for the low schema coverage but does not.

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,' using specific verbs and resources. It distinguishes from sibling tools by positioning itself as the 'first wallet-level Polymarket tool for a quick trader overview,' explicitly differentiating from detailed tools like prediction_market_address_trades.

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

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

The description includes a dedicated 'When to use' section with two explicit criteria: use as the first wallet-level tool for a quick overview, and use before detailed trades/PnL when a general profile is requested. This provides clear context for when to invoke this tool versus 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 full responsibility. It discloses behavioral details like 'Share Size is quantity traded' and 'Value USD applies to that row only', but omits pagination behavior (page parameter) and data freshness, which would improve transparency for a data retrieval 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 extremely concise (3-4 sentences) with no filler. Key fields and pitfalls are highlighted, and every sentence adds value. It is well-structured with a clear lead sentence.

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

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

Given the presence of an output schema and the schema's parameter descriptions, the tool description completes the picture with purpose, key fields, and common pitfalls. It could mention pagination or the requirement for an address, but the title implies address-level. Overall, it is sufficiently complete for this low-complexity tool.

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

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

The description does not explain input parameters; all parameter descriptions are in the schema. With 0% tool-description coverage of parameters, the baseline is 3, and the description adds no meaning beyond the schema.

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

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

The description clearly states it provides 'prediction market trade history for a Polygon wallet', specifying the resource (trade history), scope (wallet-level), and blockchain (Polygon). It distinguishes from siblings like prediction_market_address_pnl by noting 'not profitability'.

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 directs usage for 'wallet trade activity' and warns against using it for profitability, providing clear context. However, it does not name alternative tools (e.g., prediction_market_address_pnl), so it lacks explicit when-not-to-use guidance with 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, description fully details behavior: results include current prices, last trade, bid/ask; output rules like not silently substituting; query limitations. No contradiction.

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

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

Well-structured with sections (PM building blocks, When to use, Query tips, Output rules), front-loaded with main purpose. Every sentence adds value, no fluff.

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

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

Covers purpose, usage, limitations, behavioral expectations, result content, and output rules. Has output schema. Complete for the tool's complexity.

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

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

Schema descriptions are good, but description adds value by explaining queryVariant as a cleaner short keyword version, includeEventMarkets for child markets, and clarifying limits. Adds contextual tips beyond 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?

Clearly states it searches Polymarket for events and markets by name, topic, URL, or slug. Distinguishes between event and market and explicitly says not to use general_search. Very specific verb+resource.

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 provides when to use (first tool when user asks about PM topic without marketId), when not to use (not general_search), and alternatives (for price history use prediction_market_ohlcv). Includes query tips and output 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?

With no annotations provided, the description carries full burden. It discloses that the tool returns historical candles, warns about empty results and mixing markets, and mentions the complementarity of binary shares. However, it does not explicitly state whether the operation is read-only, mention rate limits, or describe other side effects.

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, when to use, key fields, pitfalls, prerequisites). It is about 12 sentences, each adding value. Slightly verbose but no redundant information.

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

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

Given the complexity of the tool (multiple parameters, no annotations, an output schema exists), the description covers purpose, usage context, pitfalls, and prerequisites. It lacks deeper parameter explanations but overall provides sufficient context for initial 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?

Although the input schema has parameter descriptions, the tool description itself provides minimal parameter guidance—only mentioning marketId in prerequisites. The description does not explain page, orderBy, dateRange, or orderByDirection, which is a gap especially given the schema description coverage is reported as 0%.

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 'Historical odds/volume candles for a Polymarket market', which is a specific verb+resource. It clearly distinguishes this tool from siblings like prediction_market_orderbook (current order book) and prediction_market_trades (trade 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 a 'When to use' section listing concrete use cases (current odds, price history, probability changes). It also includes pitfalls and prerequisites, guiding when to use alternatives like prediction_market_lookup. However, it does not explicitly state when not to use this tool.

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

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

With no annotations, the description fully carries the burden. It explains that order size is share quantity (not USD), the complementary relationship between Yes and No prices, and how to interpret No-side bids as resistance for Yes. It also warns about misinterpreting share depth, providing robust behavioral context.

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

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

The description is well-structured with sections, front-loads the purpose, and every sentence adds value. However, it is somewhat verbose; a shorter version could retain clarity. Nonetheless, it earns its length for a complex topic.

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 of prediction market orderbooks and the lack of annotations, the description covers usage, pitfalls, data interpretation, and prerequisites comprehensively. An output schema exists, so return values need not be explained. The description integrates with sibling tools (lookup, ohlcv) for full 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 coverage is 0% for the top-level 'request' parameter. The description adds that a marketId is needed (via prerequisites) but does not systematically describe the parameter structure (e.g., acceptable fields, pagination). The schema itself provides descriptions for nested fields, but the description should clarify the anyOf semantics.

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

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

The description clearly states 'Live orderbook for a Polymarket market,' specifying the resource (Polymarket market) and the data type (orderbook). It distinguishes from siblings by focusing on bid/ask depth, liquidity, and order structure, which are unique to this tool among prediction market tools.

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

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

The 'When to use' section explicitly lists use cases (bid/ask depth, liquidity, order structure) and the 'Pitfalls' section warns against using no-share prices as bearish odds, directing to prediction_market_ohlcv for odds. Prerequisites instruct to call prediction_market_lookup if marketId is unknown, providing clear guidance on when and when not to use.

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 disclosing behavioral traits. It mentions blank fields and substitution pitfalls but does not explicitly state if the tool is read-only or safe. While it adds some context, it lacks a direct statement about idempotency or lack of side effects.

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

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

The description is extremely concise, using bullet points under bold headings. It covers purpose, when to use, key fields, pitfalls, and prerequisites in a compact, scannable format without superfluous 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?

The tool has an output schema, so return values are documented. The description covers usage guidelines, prerequisites, and pitfalls. It does not elaborate on the leaderboard's exact content (e.g., top traders, metrics), but overall it provides sufficient context for safe and correct usage given the tool's relative simplicity.

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 two possible shapes with descriptions for marketId and page, but the description does not add meaning beyond those. The 'Key fields' mention 'Side Held,' which likely refers to output, not input parameters. Therefore, the description contributes little to parameter semantics.

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

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

The description clearly states 'PnL leaderboard for a Polymarket market,' specifying the exact resource (Polymarket market PnL leaderboard) and action (checking). It distinguishes from siblings like token_pnl_leaderboard by focusing on prediction 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?

The description provides explicit when-to-use guidance: 'Only for profitability claims.' It also includes a prerequisite: 'If marketId is unknown, call prediction_market_lookup first.' Pitfalls are addressed: 'If PnL fields are blank... do not substitute top holders or position size.' This clearly delineates appropriate usage.

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

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

No annotations are provided, so the description carries the burden. It explains key fields (Position Size is shares, Position Value is current marked value, Cost Basis and Unrealized PnL apply to the displayed row only). This clarifies behavioral traits beyond a simple query.

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

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

The description is concise with a clear structure: purpose, key fields list, and prerequisites. Every sentence adds value, no fluff, and the most important info is front-loaded.

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

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

For a detailed position tool, the description covers key fields, prerequisites, and pagination. It does not detail the output schema but that is acceptable. Slightly more could be said about pagination handling, but overall complete.

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

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

Schema description coverage is 0%, but the description adds meaning: it explains that marketId is numeric with example '654412', directs users to prediction_market_screener for obtaining it, and mentions the page parameter for pagination. This compensates for the schema 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 it provides a 'detailed position breakdown for a Polymarket market,' with specific fields listed. It distinguishes from siblings by noting prerequisites and referencing prediction_market_lookup for obtaining marketId.

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

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

The description includes a prerequisites section guiding users to call prediction_market_lookup if marketId is unknown. This helps in deciding when to use this tool versus alternatives, though explicit exclusions are absent.

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 carries the full burden of behavioral disclosure. It explains matching behavior (literal-style, not fuzzy), query structuring (prefer short topic, avoid bundling), and output constraints (superlatives must match metric, no inference from titles). This provides comprehensive behavioral context beyond the 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 well-structured with clear sections for usage, query tips, and output rules. It is concise, front-loaded with the purpose, and every sentence adds value. No wasted words.

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

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

Given the presence of an output schema and detailed parameter descriptions in the schema, the description provides sufficient additional context. It covers usage guidance, do's and don'ts, and distinguishes from siblings, making it complete for effective tool selection.

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

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

The schema coverage is 0%, meaning the description does not describe parameters. However, the schema itself contains detailed parameter descriptions. The description adds some contextual tips (e.g., preferring short query fragments) but largely repeats information already present in the schema. Hence, it meets the baseline of 3.

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

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

The description clearly defines the tool's purpose as browsing and sorting Polymarket markets, events, or categories. It uses specific verbs and resource names, and distinguishes from sibling tool 'prediction_market_lookup' by explicitly stating when not to use this tool.

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 guidelines: when to use (broad discovery, screening, ranked browsing) and when not to use (for resolving a named market, use lookup). It also includes query tips and output rules that help an AI agent select and invoke the tool correctly.

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 fully discloses behavioral traits: positions are share balances, value is marked not payout, output is based on shown rows only, and large positions don't imply smart money without Nansen labels. This exceeds expectations.

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, well-structured with sections, bullet points, and front-loaded with the main action. Every sentence adds value without redundancy.

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

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

Given the output schema exists, the description doesn't need to explain return values. It covers key fields, pitfalls, and prerequisites. Everything an agent needs to use the tool correctly is provided.

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%, meaning the tool description does not describe parameters in detail. It only mentions marketId in prerequisites. The input schema itself contains descriptions for page, orderBy, etc., so the description adds minimal value beyond that, but the prerequisite note is helpful.

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

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

The description clearly states it returns 'Largest current holders for a Polymarket market', using a specific verb and resource. While it distinguishes from sibling tools like 'token_current_top_holders', it does not explicitly differentiate from other prediction market tools like 'prediction_market_position_detail' or 'prediction_market_address_summary'.

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 prerequisite: if marketId is unknown, call 'prediction_market_lookup' first. Includes pitfalls advising against inferring risk or smart money. However, it lacks explicit guidance on when NOT to use this tool versus 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 provided, so description carries full burden. It explains that each row is one trade leg, Value USD applies per row, and warns about pitfalls (large trades not identifying smart money). Could mention rate limits or data freshness, but not essential for a read-only data 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?

Well-structured with sections (When to use, Key fields, Pitfalls, Prerequisites). Each sentence adds value, no redundancy. Front-loaded with main purpose.

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 tool complexity and presence of output schema, description fully covers prerequisites, usage, and data interpretation. No gaps identified.

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

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

Schema covers parameter descriptions (marketId, page, dateRange), so baseline is 3. Description adds value by clarifying key fields like 'Share Size is quantity' and 'Value USD is dollar value' per row, which aids understanding beyond 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 'Recent trades for a Polymarket market' and distinguishes itself from siblings like prediction_market_ohlcv and prediction_market_orderbook. It also specifies it's the 'source of truth for recent fills and latest trade-tape pricing.'

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 guidance: 'Source of truth for recent fills' and warning not to overwrite with OHLCV. Also states prerequisite: if marketId unknown, call prediction_market_lookup first.

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 carries full burden. It discloses key behaviors: Hyperliquid-only, recent trades, no date filtering, columns returned, and sorting options. However, it does not cover pagination behavior (page parameter exists but no details on limit per page), rate limits, or auth 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: a clear opening sentence, followed by context, column list, sorting info, and examples. It front-loads purpose. While somewhat lengthy, each section serves a purpose. Could be slightly trimmed but overall effective.

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) and the presence of an output schema, the description covers essential aspects: scope, filters, columns, sorting, and use case differentiation. It lacks pagination details and rate limits, but for a data retrieval tool, it is reasonably 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?

The schema already includes descriptions for most parameters (e.g., side, action, orderBy). The description adds value through column listing, sorting field names, and examples. However, it does not fully compensate for all parameters; e.g., 'traderAddress' and 'valueUsd' are only briefly mentioned. Schema description coverage is reported as 0%, so the description's additional guidance is helpful but not exhaustive.

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 'Get recent Hyperliquid perpetual futures trades from Smart Traders and Funds across all tokens.' It uses a specific verb ('get'), resource ('trades'), and scope ('Hyperliquid perpetual futures'). Additionally, it distinguishes from sibling tools like 'token_discovery_screener' by explicitly noting the difference in granularity.

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: it is Hyperliquid-only, returns recent trades with no date filtering, and offers an alternative ('For a big picture view... use token_discovery_screener'). It also includes examples. However, it lacks explicit 'when not to use' conditions beyond the date limitation.

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 must cover behavioral traits. It discloses aggregation (not per wallet), exclusion of certain categories, and default chain behavior. However, it does not mention pagination, sorting, or other behavioral details beyond filters.

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

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

Two sentences efficiently convey main purpose and key constraints (aggregated, excludes whales, per chain). Front-loaded with core function. Could be more structured but no wasted words.

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

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

Given the tool's complexity (nested request object with many parameters) and presence of an output schema, the description is incomplete. It fails to explain the request structure, return format, or how filters interact. More context is needed for 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?

Schema description coverage is 0%, meaning the description adds minimal parameter information beyond generic 'filters'. The schema itself has descriptions for some parameters, but the description does not amplify or clarify them further.

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 gets aggregated smart trader and fund token balances and 24h change per chain, specifying exclusions (not whales, etc.) and aggregation level. It distinguishes from sibling tools like smart_traders_and_funds_perp_trades and token_current_top_holders.

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

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

The description says 'Use filters to narrow down the results' but does not explicitly state when to use this tool versus alternatives like perp trades or individual wallet tools. It implies usage for smart money token balances but lacks clear contextual 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?

Discloses key behaviors: returns up to 25 per page, column details per mode, sorting restrictions, and limitations (e.g., native tokens, SOL). Lacks mention of rate limits or authentication, but since no annotations exist, description carries full burden and does well.

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 sections and front-loaded main purpose. However, length is high due to detailed column lists and multiple examples. Could be slightly more concise, but organization 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?

Covers all aspects: modes, columns, sorting, filters, restrictions, native tokens, and error conditions. Output schema exists and description complements it with column explanations. Examples cover common use cases. No gaps identified.

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 description must compensate. It enormously enriches parameter meaning: explains mode implications, column differences, sorting options, filter usage, and native token constraints. Examples illustrate parameter combinations clearly.

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?

Clearly states 'Get upto 25 (per page) top holders information for a specific token.' Describes two modes (onchain_tokens and perps) with distinct use cases. Distinguishes from sibling tools like token_dex_trades and token_transfers by focusing specifically on top holders.

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

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

Explicitly advises against using smart_money as a proxy for overall market view unless user requests it. Provides mode selection guidance, restrictions for native tokens, and alternatives like perps mode for SOL. Includes concrete examples 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description explains the two modes and a constraint on native tokens, which is helpful. However, it does not mention whether the tool is read-only, whether pagination is supported (though the schema includes 'page'), rate limits, or authentication requirements. The presence of an output schema partially compensates, but the description itself lacks depth on behavioral traits.

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

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

The description is concise: two short paragraphs plus a note. It front-loads the purpose and then uses bullet points for modes. Every sentence adds value. However, it could be slightly more structured (e.g., separating usage guidelines from behavioral notes), but overall it is efficient.

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

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

Given the tool's complexity (two modes, many parameters, output schema present), the description covers the main functionality and mode differentiation well. It addresses the important nuance about native tokens not supported in onchain_tokens mode. However, it does not explain error cases (e.g., invalid token address) or discuss the pagination/default values beyond what the schema provides. With output schema present, the description is fairly complete but misses a few edge-case details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the mode parameter with its default and the note about native tokens. However, it does not go beyond the schema for other parameters (e.g., 'tokenAddress' is required but not highlighted; the description says 'for a specific token' but doesn't specify that tokenAddress is the key identifier). The schema already provides adequate descriptions, so the description adds minimal extra semantic value.

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 begins with a clear action: 'Get DEX trades for a specific token.' It then contrasts two modes ('onchain_tokens' vs 'perps'), which clearly distinguishes this tool from sibling tools like 'address_dex_trades' (which focuses on trades for an address) and 'token_transfers' (different resource). The title 'Checking latest DEX trades' combined with the first sentence leaves no ambiguity about the tool's purpose.

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

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

The description explicitly explains the two modes and provides a concrete usage note: 'In onchain_tokens mode, only ETH is supported among native tokens. For other native tokens (SOL, BTC, BNB, etc.), use perps mode instead.' This gives clear context on when to choose each mode. However, it does not compare with sibling tools like 'smart_traders_and_funds_perp_trades' or explain when not to use this tool, so it's not a full when/when-not guide.

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 excellently discloses behavioral traits: max 25 results, max 5 chains (excess trimmed), Hyperliquid special behavior (perps vs spot, two result sections, supported filters), timeout warnings, and that priceChange is not a valid filter. It also details output columns and special columns for perps, providing full 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?

Despite being long, the description is well-structured with headings, bullet points, examples, and warnings. Every section earns its place, given the complexity of the tool (multiple chains, perps, many filters). It front-loads the purpose and key constraints, making it easy to scan. The length is appropriate for the subject matter.

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 and lack of annotations, the description is complete. It covers purpose, filtering, sorting, special cases (Hyperliquid), result format (columns explained), timeout warnings, and notes on interpreting outputs (e.g., positive net flow). The output schema exists but the description still clarifies return values comprehensively.

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 provides extensive parameter semantics: lists all filtering options (numeric ranges, categories, trader type) with explanations of when to use each, sorting options with available fields, and clarifies that some fields are for filtering only. Examples further illustrate parameter usage. This adds immense 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 gets comprehensive token screening data across multiple chains with advanced filtering. The title 'Discovering trending tokens' and the opening line 'Get comprehensive token screening data across multiple blockchain networks with advanced filtering' provide a specific verb and resource. The description further clarifies it helps with token discovery and finding trending tokens, distinguishing it from sibling tools like token_info or token_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 through examples and special case handling (Hyperliquid), and includes warnings about chain limits and timeouts. It also gives guidance on when to use specific filters (e.g., traderType). However, it does not explicitly state when not to use this tool compared to sibling tools (e.g., for specific token details), so it lacks explicit exclusions or alternatives.

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

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

No annotations provided, so description carries full burden. Discloses that onchain_tokens mode does not support native tokens but perps mode does. Missing some details like data freshness or error handling, but overall transparent.

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 sections and bullet points. Slightly lengthy but each part adds value. Front-loaded with main purpose.

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

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

Covers all aspects: modes, holder segments, date range, token support limitations, comparison with sibling tool. Complete for a complex tool with two modes and multiple segments.

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

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

Schema coverage is 100%, but description adds significant context: explains holder segment options, modes and their implications, and important notes about smart_money usage. Goes beyond 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?

Clearly states the tool gets hourly aggregated token flows for a specific holder segment over a date range. Distinguishes from sibling token_recent_flows_summary by noting it is more granular.

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 advises when not to use smart_money segment as a proxy, and provides alternative use. Also notes it's more granular than the summary tool, helping the agent choose.

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?

Given no annotations, the description carries the full burden. It clearly discloses the behavioral traits: two modes, identifier types (contract address vs symbol), output format (markdown with detailed fields), and timeframe usage. It does not mention data freshness or caching, but overall provides substantial behavioral context.

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

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

The description is well-structured with sections, bullet points, and examples. It front-loads the purpose and modes. Slightly long but every section adds value; the field lists are justified given the output complexity.

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

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

The description thoroughly explains its own functionality, output fields, and modes. However, it does not contextualize the tool among many siblings (e.g., when to use this vs token_dex_trades or token_flows), leaving a gap in integrated usage guidance. An output schema is missing but the field lists partially compensate.

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% on the top-level 'request' parameter. The description compensates by explaining the request structure via examples and notes, clarifying how mode affects required fields and identifier types. While the schema covers subfield constraints, the description adds meaningful usage context beyond the raw 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 a specific verb ('Get') and resource ('token information'), and distinguishes two distinct modes (on-chain tokens and Hyperliquid perps). The examples further solidify the purpose, distinguishing it from sibling tools that cover narrower token aspects.

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 explains the two modes and provides examples but does not explicitly guide when to use this tool versus alternatives like token_dex_trades or token_flows. It implies usage context through the two modes but lacks exclusionary guidance or explicit when-not-to-use statements.

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?

Discloses all behavioral traits: automatic resolution algorithm, detailed columns returned (including optional market cap fields), and special handling for Hyperliquid perpetual futures. No annotations provided, but description fully compensates.

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 sections: supported chains, resolution rules, column descriptions, and multiple examples. Every sentence adds value without redundancy.

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

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

Given the complexity of the tool (multiple chains, auto-resolution, optional fields) and the lack of an output schema in the structured data, the description fully documents return columns and behavior, satisfying completeness.

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

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

Adds significant meaning beyond the input schema by explaining the tokenAddress parameter for Hyperliquid, date format conventions (e.g., '7D_AGO'), and the includeMarketCap flag. Schema coverage is low, so description carries the burden effectively.

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 that the tool retrieves OHLCV price data for tokens with automatic interval resolution. It specifies supported chains (EVM, Solana, Hyperliquid perps) and distinguishes from sibling tools like general_search by emphasizing that general_search is delayed and incorrect.

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

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

Explicitly instructs to use this tool over general_search for prices, providing a clear reason. Includes example usages for different chains and timeframes, effectively guiding when and how to invoke the tool.

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

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

With no annotations, the description carries full burden. It transparently discloses the 25-result limit, sorting behavior, mode limitations, and that results are never complete. It does not mention rate limits or auth, which is acceptable for a read-only 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 long but well-structured with sections for modes, returns, columns, sorting, filtering, examples, and notes. It is front-loaded with the main purpose, but some redundancy (e.g., repeating the 25-result limit) makes it slightly verbose.

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

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

The description covers modes, filters, sorts, and return columns. However, pagination is not explained (the page parameter is only in the schema), and there is no guidance on how to get more than 25 results. The column details compensate for the missing output schema, but the pagination gap reduces completeness.

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

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

The input schema has a single 'request' object with detailed descriptions on each field. The tool description adds value by grouping parameters into sorting and filtering categories and providing examples, but does not repeat or enhance the schema's own descriptions significantly. Schema coverage is actually high, so baseline is 3.

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

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

The description clearly states the tool returns up to 25 trader PnL results per page for a token, with modes for on-chain tokens and perps. It distinguishes from siblings by focusing on leaderboard-level data, but does not explicitly name alternatives like wallet_pnl_for_token.

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 explains the two modes and provides examples, but lacks explicit guidance on when NOT to use the tool or mention of sibling tools. It does note limitations (no native tokens in onchain_tokens mode, no hyperevm), which helps, but overall guidance is incomplete.

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. It details what is returned: markdown with interpretation, token info, fields per indicator, and indicator types. Notes about availability and percentile comparison add transparency beyond basic output description.

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 sections for purpose, usage, and output details. Every sentence adds value, though slightly verbose. Front-loads key information effectively.

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

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

Covers the output in detail with indicator types, fields, and notes. Given the existence of an output schema, the description provides sufficient context for the agent to understand what the tool returns. Lacks input guidance but overall complete for decision-making.

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?

Description does not explain the input parameter 'request' or its structure (tokenAddress and chain). Relies entirely on the schema descriptions, which are moderately informative but not elaborated in the description. Schema description coverage is 0%, so the description fails to compensate.

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?

Clearly states it retrieves Nansen Score Indicators for a token, specifying quantitative risk and reward signals. Distinguishes from sibling tools like nansen_score_top_tokens (which is for top tokens) by focusing on a single token's quantitative scores.

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 guidance on when to use: assessing risk/reward profile, evaluating buy/sell decisions, or needing quantitative trading data. Does not mention when not to use or alternatives, but the context is clear enough.

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 the description fully discloses behavior: returns markdown format, explains flow meaning (positive=net buying, negative=net selling), notes Bitcoin unsupported, and describes modes comprehensively. No contradictions.

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

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

Well-structured with sections, bullet points, and notes. Information is front-loaded with critical details, and every sentence adds value. No redundancy.

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

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

Given no annotations and 24 sibling tools, the description is complete: covers purpose, usage context, parameter semantics, return format, limitations, and mode alternatives. It fully enables correct 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?

Schema has 1 parameter with 0% description coverage at top level, but the description adds significant meaning: explains the 'request' parameter's nested fields, modes, lookback options, and behavior. It compensates for the schema's lack of top-level parameter description.

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 gets TOTAL token flows per segment, lists the six segments, and explains the importance of inflow/outflow. It distinguishes itself from sibling tool 'token_flows' by specifying aggregation over a lookback period vs specific date ranges.

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: 'If you have SPECIFIC date ranges in mind, use token_flows instead.' Additionally, it notes Bitcoin is not supported and explains when to use different modes (onchain_tokens, perps).

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 pagination (25 per page), default sorting, and a notable constraint (no native token support). However, it omits details such as rate limits, authentication requirements, maximum time range clamp (mentioned only in schema), or any side effects, leaving gaps in the agent's understanding of behavioral traits.

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 headers, bullet points for columns, and multiple examples. However, it is quite lengthy and sometimes repeats information (e.g., filter explanations appear both in text and examples). Slight redundancy reduces conciseness, but the overall organization aids comprehension.

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

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

The description covers pagination, sorting, filtering, and includes extensive examples. With an output schema present (though not displayed), the return value explanation is supplementary. It does not discuss error handling or usage limits, but for a data retrieval tool with given schema richness, it is largely 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?

Despite the schema having descriptions for each parameter, the tool description adds substantial value by explaining the meaning and usage of each filter in depth (e.g., smart money filter definition, transfer origin categories, USD value range format). Examples illustrate real-world usage, which is critical given the 0% schema description coverage context (though schema actually has descriptions). The description compensates fully and exceeds schema detail.

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 that the tool retrieves 25 token transfers per page for a specific token, with default sorting by most recent transfers first. It explicitly excludes native tokens, distinguishing it from potential sibling tools that might handle native transfers, and its focus on token-specific transfers differentiates it from address-level or DEX trade tools.

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

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

The description provides clear when-to-use guidance through examples and filter descriptions, and it explicitly states that native tokens are not supported. However, it does not explicitly suggest alternative tools for cases like investigating address-level transfers or DEX trades, leaving the agent to infer usage boundaries from sibling tool names.

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 covers key behaviors: DEX-only, aggregated totals, markdown output, empty string if no data, sorting options, and note about buy_or_sell filter. It does not mention rate limits or authentication, but is transparent for core 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 well-structured with bullet points and sections (notes, columns, sorting). It is front-loaded with the core purpose. Slightly verbose, but clear.

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 (nested input schema, many parameters, rich output), the description covers the main purpose, return columns, and key parameters. It does not fully explain the request object structure but is adequate with the output schema and column listing.

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 adds meaning for buy_or_sell (BUY/SELL filters net buyers/sellers) and sorting (asc/desc by bought/sold_volume_usd). However, it does not explain page, chain, tokenAddress, include_labels, min_trade_volume_usd, or the nested request structure. Schema descriptions exist for some parameters, but overall coverage is low.

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 gets total amounts of tokens bought/sold by address for a token on DEX only. It specifies the resource (token) and action (get aggregated activity), and distinguishes from siblings like token_dex_trades which lists individual trades.

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

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

The description advises using it to find who is buying/selling and to check for profit-taking or accumulation. It provides context but does not explicitly state when not to use or list alternative tools, though the sibling list is large.

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 must fully disclose behavior. It claims 'comprehensive' details but only cites token transfers as an example, leaving out other aspects like gas, status, logs, or how chain parameter affects results.

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

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

The description is very short (single sentence) and front-loaded. It conveys the main purpose without redundancy, though it could be slightly expanded without being verbose.

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

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

An output schema exists, so return values are covered structurally. However, the description fails to provide context for parameter usage, default behavior, or how this tool fits among many siblings, making it incomplete for an agent to use confidently.

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%, meaning the input schema lacks descriptions. The tool description mentions 'comprehensive transaction details' but does not explain what the 'chain' parameter does or what format transaction_hash should take.

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 comprehensive transaction details including token transfers, which distinguishes it from more specific tools like token_transfers. However, it doesn't explicitly differentiate from address_transactions or other lookup 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?

No guidance on when to use this tool versus siblings like address_transactions, token_transfers, or general_search. The agent must infer usage from the name alone.

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 does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or error conditions. It only implies reading but lacks explicit 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?

Two sentences with no fluff. The first sentence front-loads the purpose, and every sentence is informative and necessary.

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 one parameter and an output schema, the description is minimal but adequate. However, it lacks context on prerequisites, error handling, or expected input format beyond what the schema provides.

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 only parameter 'request' has no description in the tool description. Although the inner properties in the schema have descriptions, the tool description adds no value for parameter understanding. With 0% schema coverage at the top level, the description should compensate but does not.

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 gets PnL stats for a specific token traded by an address during a date range. It distinguishes from siblings like wallet_pnl_summary (overall PnL) and token_pnl_leaderboard (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 says 'Use this tool for analysing the performance of the wallet for the specific token over a time period.' This provides clear context for when to use, but does not explicitly exclude usage or mention 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 discloses the limitation of including only realized PnL, but does not mention data freshness, error handling, or any side effects. Given the lack of annotations, the description provides minimal behavioral context beyond the core function.

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 at 60 words and front-loaded with the key action. However, there is slight redundancy in mentioning 'over a time period' twice. Overall efficient but could be trimmed slightly.

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 large number of sibling tools (34) and the presence of an output schema, the description covers the purpose and a key limitation (realized vs unrealized). However, it fails to differentiate from the similar 'wallet_pnl_for_token', leaving a gap in context for agent selection.

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

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

The input schema already describes the parameters (walletAddress, dateRange) with reasonable detail. The description adds only the concept of 'overall realized PnL' but does not provide additional semantic meaning or examples. With schema description coverage indicated as 0% (though schemas have descriptions), the description does not compensate significantly.

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 aggregate stats of overall realized PnL for an input address, distinguishing from unrealized PnL. It uses specific verbs like 'Get aggregate stats' and identifies the resource as the wallet address, setting it apart from sibling tools like 'wallet_pnl_for_token' which focus on per-token PnL.

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 notes the tool is for analyzing wallet performance over a time period and clarifies it does NOT include unrealized PnL, directing users to alternative methods. However, it lacks explicit differentiation from the sibling 'wallet_pnl_for_token' or guidance on when to use one over the other.

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