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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: pagination ('25 per page'), default sorting ('net value transferred'), and includes important behavioral notes about CEX addresses and relationship depth. It also lists sorting options and provides concrete examples. However, it doesn't cover error conditions, rate limits, or authentication needs, leaving some gaps for a tool with complex input/output.

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

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

The description is front-loaded with core functionality but becomes verbose with implementation notes and examples. Sentences like 'Address structure / string is not important, but the relationship is!' could be more concise. The examples are helpful but lengthy, making the overall description somewhat bloated. It earns its place but could be more tightly structured.

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

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

Given the tool's complexity, no annotations, and an output schema (which handles return values), the description does a good job of completeness. It covers purpose, behavior, parameter usage, and provides examples. However, it lacks information about error handling, rate limits, and doesn't fully explain all parameter interactions (e.g., chain behavior with 'all'). For a tool with rich input/output, it's mostly complete but has minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It adds significant value by explaining parameter usage through examples and contextual notes: it shows how 'addresses' and 'entityId' work, describes 'groupBy' options, explains sorting fields, and provides timeRange examples. The description effectively clarifies what would otherwise be undocumented parameters, though it doesn't cover all parameters exhaustively.

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

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

The description clearly states the tool's purpose: 'Get 25 (per page) addresses or entities with the most common interactions with input addresses' and 'returns the top 3 tokens transferred by count for each counterparty.' It specifies verb ('Get'), resource ('addresses or entities'), and output details. However, it doesn't explicitly differentiate from siblings like 'address_related_addresses' or 'address_transactions' beyond mentioning 'most common interactions' and sorting by 'net value transferred.'

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

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

The description provides some implied usage context: it mentions focusing on 'direct value transfers' and 'CEX deposit addresses,' and includes examples for querying by addresses or entities. However, it lacks explicit guidance on when to use this tool versus alternatives like 'address_related_addresses' or 'address_transactions,' and doesn't state prerequisites or exclusions clearly. The notes offer tactical advice but not strategic when-to-use rules.

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

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

No annotations are provided, so the description carries full burden. It mentions 'historical' balances but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, pagination, or error handling. For a tool with complex input schema and likely data-intensive operations, this lack of transparency is a significant gap.

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

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

The description is a single, efficient sentence: 'Get historical native coin & token balances of address.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's 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?

Given the tool's complexity (multiple parameters, enums, conditional logic in schema) and the presence of an output schema, the description is minimally complete. It states what the tool does but lacks context on usage, behavior, or integration with siblings. With output schema handling return values, the description's gaps are partially mitigated but still notable.

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 no parameter semantics beyond the input schema. With 0% schema description coverage, the schema itself provides detailed parameter documentation (e.g., addresses, entity_id, lookbackDays). The description doesn't compensate for the coverage gap or explain parameter interactions, so it meets the baseline for adequate but not additive 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 historical native coin & token balances of address.' It specifies the action (get), resource (balances), and scope (historical, native coin & token). However, it doesn't differentiate from siblings like 'address_portfolio' or 'smart_traders_and_funds_token_balances', which may also involve balance-related queries.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., address_portfolio, address_transactions, token_balances tools), there's no indication of context, prerequisites, or exclusions. Usage is implied by the purpose but not explicitly stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns pre-formatted markdown for presentation, includes liquidation prices in Hyperliquid positions for risk analysis, and handles both wallet addresses and entities with different data scopes. However, it lacks details on rate limits, error handling, or authentication requirements.

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

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

The description is well-structured and front-loaded with the core purpose, followed by detailed mode explanations and usage examples. While comprehensive, it is appropriately sized for the tool's complexity, with each sentence adding value. Minor redundancy in example formatting slightly affects 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 modes, entity vs. wallet handling) and the presence of an output schema (which covers return values), the description is complete. It explains input semantics, behavioral traits, and usage guidelines thoroughly, leaving no gaps for the agent to understand 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 description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains the semantics of the 'mode' parameter with detailed descriptions of each option (e.g., 'fast-mode-default', 'all', 'defi'), clarifies that entities only return token balances, and provides concrete examples of parameter usage. 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 specifies the verb ('Get'), resource ('portfolio overview'), and scope ('wallet address or entity'), distinguishing it from sibling tools like address_transactions or address_historical_balances which focus on different aspects of address data.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It details different modes (e.g., 'fast-mode-default', 'all', 'defi', 'hyperliquid') for specific use cases and clarifies that for entities, only token balances are returned. It also includes example usage scenarios, helping users choose appropriate parameters based on their needs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the types of connections included (e.g., 'First Funder', 'Signer') and limitations (e.g., exchange withdrawal addresses not indicating same entity). However, it doesn't cover critical aspects like rate limits, authentication needs, error handling, or pagination details, leaving gaps for an agent to infer behavior.

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

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

The description is well-structured and front-loaded with the core purpose, followed by notes and examples. Sentences are efficient, such as 'Get information about related addresses of an input address.' and the note on 'special' connections. However, the example code block is lengthy and could be more concise, slightly reducing efficiency.

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

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

Given the complexity (1 parameter with 0% schema coverage, no annotations, but an output schema exists), the description does a decent job. It explains the tool's scope, provides an example, and notes return format ('Formatted related addresses data as markdown table'). With an output schema handling return values, the description doesn't need to detail outputs further. However, it could better address parameter details and behavioral traits to be fully 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 description coverage is 0%, so the description must compensate. It mentions parameters like 'addresses' and 'chain' in the example and notes that 'chain' can be 'all' or 'evm', adding some semantics beyond the bare schema. However, it doesn't fully explain the 'request' parameter's structure or optional fields, leaving the agent to rely on the schema alone for details, which is insufficient for full clarity.

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

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

The description clearly states the tool's purpose: 'Get information about related addresses of an input address.' It specifies the verb ('Get information') and resource ('related addresses'), and distinguishes it from sibling tools like 'address_counterparties' by noting that counterparties are separate. However, it doesn't explicitly differentiate from other address-related tools like 'address_transactions' or 'address_portfolio', keeping it from a perfect score.

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

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

The description provides some implied guidance by noting that 'To get related wallets, also check address counterparties,' suggesting this tool is for specific 'special' connections. It also clarifies that 'First funder exchange withdrawal address does usually NOT belong to the same entity,' offering context on when results might be misleading. However, it lacks explicit when-to-use vs. when-not-to-use instructions or direct alternatives, relying on implicit context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination ('per page') and recency ('latest transactions'), but lacks details on permissions, rate limits, error handling, or what 'date range' means (implied but not defined). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is concise and front-loaded with the core purpose in the first sentence. Both sentences earn their place by clarifying scope and recency. However, it could be slightly more structured (e.g., explicitly noting parameters or usage context), but it avoids 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 tool's moderate complexity (fetching transactions), no annotations, 0% schema description coverage, but an output schema exists, the description is partially complete. It covers the basic purpose and some behavior (pagination, recency), but lacks parameter details and usage context. The output schema mitigates the need to explain return values, but gaps remain.

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

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

The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, and the description doesn't mention any parameters (e.g., 'address', 'page', 'chain', 'hideSpamToken') or their meanings. This fails to compensate for the schema's lack of descriptions, leaving parameters undocumented.

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

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

The description clearly states the tool's purpose: 'Get list of 20 MOST RECENT transactions made by an address (per page).' It specifies the verb ('Get'), resource ('transactions'), and scope ('by an address'), distinguishing it from siblings like 'address_historical_balances' or 'transaction_lookup'. However, it doesn't explicitly differentiate from all siblings (e.g., 'token_transfers'), so it's not a perfect 5.

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

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

The description provides minimal guidance: 'Only the latest transactions according to the date range are returned.' It implies recency but doesn't specify when to use this tool versus alternatives like 'address_historical_balances' (for balances over time) or 'transaction_lookup' (for specific transactions). No explicit when/when-not or alternative recommendations are 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?

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it's a search/read-only tool (implied by 'look up'), has domain resolution capability ('only tool that can resolve domains'), delayed price data ('DO NOT rely... for LATEST prices'), and limitations (no NFT support, max_results constraint). However, it doesn't mention rate limits or authentication needs.

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

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

The description is well-structured with clear sections (purpose, exclusions, capabilities, args, usage guidance, important notes) and uses bullet points effectively. While comprehensive, it's slightly verbose in places (e.g., repeating chain guidance), but every sentence adds value. It's front-loaded with the core 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 the tool's complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema (which handles return values), the description is exceptionally complete. It covers purpose, usage, parameters, limitations, sibling differentiation, and behavioral context thoroughly, leaving no significant gaps for agent understanding.

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

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

With 0% schema description coverage, the description fully compensates by explaining all 4 parameters in detail. It provides clear semantics for query (what to include/exclude), result_type (when to use each value with examples), max_results (default and max), and chain (how to use, valid values, interaction with query). The 'How to choose result_type' section is particularly thorough.

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 as a 'FIRST entry point' for searching tokens, entities, and addresses, distinguishing it from siblings like prediction_market_lookup. It specifies the exact resources (tokens, entities, addresses) and actions (search, check existence, resolve domains).

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

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

The description provides explicit guidance on when to use this tool vs. alternatives (e.g., 'Do NOT use this tool for prediction markets... use prediction_market_lookup instead'), when to choose specific result_type values, and when to use chain parameter. It includes clear examples (✅ CORRECT/❌ WRONG) and warnings about what not to do.

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 mentions the tool returns a 'Formatted markdown table with chain growth metrics,' which adds some context about output format. However, it fails to describe critical behaviors like whether this is a read-only operation, potential rate limits, data freshness, or error conditions. For a tool with no annotations, this is insufficient.

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

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

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. The 'Args' and 'Returns' sections are structured but could be more integrated. There's no wasted text, though it could be slightly more detailed without losing 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 moderate complexity (1 parameter with nested properties), no annotations, and an output schema exists (implied by 'Returns'), the description is partially complete. It covers the basic purpose and output format but lacks details on parameter semantics, behavioral traits, and usage context. With an output schema, it doesn't need to explain return values deeply, but other gaps remain.

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

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

Schema description coverage is 0%, so the description must compensate. It states that the 'request' parameter is a 'GrowthChainRankRequest containing parameters and pagination settings,' which adds minimal semantics beyond the schema's property names. However, it doesn't explain the meaning of 'chain_type' or 'time_frame' enums (e.g., 'evm' vs. 'all', or what '7', '30', '365' represent). The baseline is 3 due to the schema's lack of descriptions, but the tool's description provides only generic info.

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

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

The description clearly states the tool's purpose: 'Get chain growth rankings by active addresses, transactions, gas fees and DEX volume.' It specifies the verb ('Get') and resource ('chain growth rankings') with specific metrics. However, it doesn't explicitly differentiate from sibling tools, which focus on addresses, tokens, predictions, etc., but this tool's blockchain ranking focus is distinct enough.

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, such as needing specific data access, or comparisons to sibling tools like 'general_search' or 'token_discovery_screener' that might overlap in functionality. This omission leaves the agent without clear usage direction.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it returns data in markdown format, lists specific columns with formatting details (e.g., currency/percentage formatting), explains sorting and filtering options, and includes an example request. It also notes the endpoint specificity. However, it lacks details on rate limits, authentication needs, or pagination behavior beyond the 'page' parameter in 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 sections like 'Returns:', 'Columns returned:', 'Sorting and Filtering Options:', 'Example:', and 'Notes:'. It is appropriately sized and front-loaded with the core purpose. However, some redundancy exists (e.g., repeating 'perpetual futures' in the purpose and notes), and the example could be more concise.

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 (1 parameter with 0% schema coverage, no annotations, but with an output schema), the description is complete enough. It explains what the tool does, what it returns, how to use parameters via the example, and notes endpoint specificity. The output schema likely covers return values, so the description appropriately focuses on usage and semantics without needing to detail outputs.

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

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

The schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining the columns returned (e.g., 'Address', 'Label', 'Total PnL'), detailing sorting and filtering options on fields like 'totalPnl', and providing a concrete example with parameters such as 'date', 'accountValue', 'totalPnl', 'order_by', and 'orderByDirection'. This clarifies how to use the single 'request' parameter 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 the tool's purpose: 'Get Hyperliquid perpetual futures trader leaderboard with performance metrics.' It specifies the exact resource (Hyperliquid perpetual futures trader leaderboard) and action (get), and distinguishes it from siblings by mentioning it's Hyperliquid-specific and for perpetual futures only, unlike other tools focused on prediction markets, tokens, or addresses.

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

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

The description implies usage by specifying 'Hyperliquid-specific endpoint (perpetual futures only)', which helps differentiate it from general leaderboard tools. However, it does not explicitly state when to use this tool versus alternatives (e.g., other leaderboard tools like 'prediction_market_pnl_leaderboard' or 'token_pnl_leaderboard'), nor does it provide prerequisites or exclusions for 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns pre-filtered tokens (Performance Score ≥15), uses daily/batched data (not real-time), explains scoring ranges and thresholds, and details the return format. It doesn't mention rate limits, authentication needs, or error conditions, but covers most operational aspects 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?

The description is well-structured with clear sections (When to use, Scoring, Returns) and uses bold text effectively. It's appropriately detailed for a complex tool but could be slightly more concise in the scoring explanation section, which includes repetitive instructions about explaining thresholds to users.

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 (scoring system, filtering logic, sibling comparisons) and the presence of an output schema, the description is remarkably complete. It explains the tool's purpose, when to use it, behavioral characteristics, scoring methodology, return format, and provides example queries. The output schema handles return value details, allowing the description to focus on higher-level 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?

The input schema has 0% description coverage for its single parameter (marketCapGroup). The description doesn't explicitly mention this parameter, but it implies filtering by stating 'pre-filtered by: performance_score >= 15' and mentions market cap groups in the context of sibling tools. While it doesn't document the parameter directly, the overall context provides some compensation 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 the tool's purpose: 'Discover and filter a daily list of attractive tokens using Nansen Score Indicators weighted by coefficients (= Performance Score).' It specifies the verb ('discover and filter'), resource ('tokens'), and distinguishes from siblings by contrasting with token_quant_scores and token_discovery_screener.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states: 'Use this tool when you don't know which tokens to buy and need recommendations based on backtested indicators' and includes a dedicated section contrasting with token_discovery_screener, explaining when to use each based on pre-scored recommendations versus live filtering.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context: 'Market-by-market PnL when the API provides it' indicates conditional data availability, and 'Blank PnL fields mean unavailable data, not zero' clarifies response interpretation. However, it omits other behavioral traits like error handling for invalid addresses or pagination limits.

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

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

The description is appropriately concise and front-loaded, stating the core purpose immediately. The bullet points for 'Key fields' are structured efficiently. Minor deduction because output field descriptions may duplicate the output schema (unseen here), though the behavioral note about blank fields adds value beyond pure schema documentation.

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

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

Given the presence of an output schema, the description appropriately focuses on interpreting results rather than return values. However, with zero input schema coverage and no annotations, the description is incomplete regarding input requirements. It also fails to contextualize the tool among the many sibling prediction market and PnL tools.

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

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

Schema coverage is 0% (the 'request' parameter lacks a description) and the description fails to compensate adequately. While it mentions 'Polygon wallet' implying the address parameter, it does not explicitly document the required 'address' field, the 'page' pagination parameter, or the fact that inputs must be wrapped in a request object.

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 'Prediction market PnL breakdown for a Polygon wallet,' specifying the resource (PnL), scope (prediction markets), and target (Polygon wallet). It distinguishes from siblings like wallet_pnl_summary (general PnL) and prediction_market_pnl_leaderboard (aggregate data) by emphasizing the wallet-specific prediction market analysis.

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

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

The description provides no guidance on when to use this tool versus alternatives like prediction_market_position_detail, wallet_pnl_summary, or prediction_market_address_trades. It lacks prerequisites (e.g., 'use this when you need historical PnL vs current positions') and exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses that blank PnL or ROI fields mean unavailable data, not zero, which adds behavioral context beyond the schema. However, it does not explicitly state that the tool is read-only, though the name and context imply it. The description could mention pagination behavior or rate limits, but the output schema likely covers returns.

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

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

The description is very concise, using only three short sections: a one-line purpose, a bulleted usage guide, and a brief list of key fields. Every sentence adds value, and the structure is front-loaded with the most critical 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 existence of an output schema, the description does not need to detail return values. It covers purpose, usage context, and handles the edge case of blank fields. It could be improved by mentioning that the address must be a Polygon wallet and that pagination is available, but these are minor gaps for a simple summary 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 input schema already provides clear descriptions for both parameters ('address' and 'page'). The tool description adds no additional semantic information about the parameters themselves. Since the schema descriptions are comprehensive, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides 'Prediction market summary metrics for a Polygon wallet'. It differentiates itself from sibling tools by positioning itself as the first wallet-level Polymarket tool for a quick overview, contrasting with more detailed tools like prediction_market_address_pnl and 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 explicitly includes a 'When to use' section with two actionable guidelines: use it as the initial wallet-level tool for a quick trader overview, and use it before detailed address trades/PnL when the user asks for a general profile. It implicitly indicates not to use it for detailed data, directing to alternatives.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context by explaining output field semantics ('Share Size is quantity traded...', 'Value USD applies to that row only'). However, it omits operational details like pagination behavior, rate limits, or authorization requirements that would be essential 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 uses bold headers ('Key fields:', 'Pitfalls:') effectively to structure information, and every sentence serves a purpose. However, it may be overly concise given the tool's input complexity, leaving critical invocation details undocumented.

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 complex nested input structure (request wrapping, date range tokens) and 0% root schema coverage, the description is incomplete. While it documents key output fields (acceptable since output schema exists), it fails to explain how to construct the input request object, which is essential for successful 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?

Context signals indicate 0% schema description coverage at the root level, and the description fails to compensate. It mentions 'Polygon wallet' which hints at the address parameter, but provides no guidance on the complex 'request' wrapper object, pagination 'page' parameter, or the date token syntax (NOW, XMIN_AGO, etc.) required for the dateRange parameter.

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 opening sentence 'Prediction market trade history for a Polygon wallet' provides a specific verb (trade history/retrieval), resource (prediction market), and scope (Polygon wallet). It effectively distinguishes from sibling tools like prediction_market_trades (general market) and prediction_market_address_pnl (profitability) by specifying 'wallet' and noting 'not profitability' in the pitfalls section.

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

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

The 'Pitfalls' section provides one explicit guideline ('Use this for wallet trade activity, not profitability'), which hints at when not to use it. However, it fails to explicitly name the alternative tool (prediction_market_address_pnl) or clarify when to use this versus prediction_market_trades for general market data.

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

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

With no annotations provided, description carries full burden and successfully explains the domain model (event vs. market building blocks), search API behavior (natural language works, prefer short keywords), and output rules (explicitly states not to silently substitute markets). Lacks explicit rate limit or caching information.

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 headers (PM building blocks, When to use, Query tips, Output rules). Every section earns its place; domain concepts are essential for correct usage. Front-loaded with core purpose and efficiently organized despite length.

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

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

Comprehensive for a complex domain-specific tool. Explains Polymarket-specific concepts (event vs. market) that an AI wouldn't infer, provides query optimization tips, and specifies output behavior. Since output schema exists, description appropriately focuses on input semantics and usage context rather than return values.

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

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

Given 0% schema description coverage per context signals, description partially compensates by explaining query (implied in opening), queryVariant, and includeEventMarkets in the usage section. However, it omits page, status, maxCandidates, and maxEventMarkets, leaving significant gaps for a 7-parameter tool.

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

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

Opens with specific verb and resource ('Search Polymarket for events and markets') and clearly distinguishes from siblings by explicitly stating 'Do NOT use general_search for prediction markets' and contrasting with prediction_market_ohlcv for price history vs. current prices.

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

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

Contains explicit 'When to use:' section naming specific conditions (user asks about PM topic without marketId), recommends setting includeEventMarkets for event-level questions, and explicitly names alternatives to avoid (general_search) and when to use them instead.

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

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

No annotations provided, so description carries full burden. It adds substantial value via 'Key fields' (explaining Close represents share price and Yes/No complementarity) and 'Pitfalls' (warning against mixing markets and prohibiting estimation when no candles returned). Lacks rate limits or auth details.

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

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

Excellent structure with bold headers (**When to use**, **Key fields**, **Pitfalls**, **Prerequisites**) enabling fast scanning. Zero waste—every line provides actionable guidance or domain context. Front-loaded with clear purpose statement.

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

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

Comprehensive for a financial data tool with output schema. Covers data interpretation (share price mechanics), workflow integration (lookup prerequisite), and failure modes (empty results). Does not need to explain return values since output schema exists.

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 context signal claiming 0% coverage, the schema actually documents parameters well (marketId description, dateRange token syntax). Description mentions marketId prerequisite but doesn't elaborate on parameter formats beyond what schema provides. Baseline 3 appropriate given schema quality.

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

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

Description opens with specific verb-noun phrase 'Historical odds/volume candles' and domain 'Polymarket market'. It clearly distinguishes from sibling tools like prediction_market_orderbook (current state) and prediction_market_trades (individual transactions) by specifying OHLCV candle format.

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' section listing specific use cases (current odds, price history, probability changes). Names prerequisite sibling tool 'prediction_market_lookup' directly for obtaining marketId, establishing clear workflow chain.

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. Excellently discloses domain-specific behavioral logic: clarifies Order Size represents share quantity not USD, explains Yes/No price complementarity (summing to ~$1), and warns against interpreting No-side prices as bearish Yes odds. Deducting one point for missing operational details like real-time vs cached data or rate limits.

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?

Perfectly structured with clear markdown headers (When to use, Key fields, Yes/No price relationship, Pitfalls, Prerequisites). Information is front-loaded with the core purpose. Every sentence provides domain-specific value; no fluff. Appropriate length for the complexity of Polymarket mechanics.

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 complex domain (prediction market microstructure), the description is comprehensive. It explains how to interpret the complementary pricing mechanics, converts between No/Yes prices, and warns against common analysis errors. Output schema exists, so return value documentation isn't needed. Adequately distinguishes from 5 sibling prediction market tools.

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

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

Schema description coverage is 0% at the top level (only parameter 'request' lacks description), requiring description to compensate. While prerequisites mention marketId is required, the description fails to explicitly document the 'page' pagination parameter or explain the nested request object structure. The schema's internal descriptions compensate partially, but description adds minimal semantic value beyond the prerequisite note.

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

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

Opens with specific verb+resource ('Live orderbook for a Polymarket market'), immediately clarifying it fetches orderbook depth/liquidity. Distinct from sibling OHLCV/trades tools via explicit 'When to use' scope (bid/ask depth, yes-share/no-share structure).

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' section defining appropriate use cases (bid/ask depth analysis). Names specific alternative tool (prediction_market_ohlcv) in 'Pitfalls' section for when users need current odds rather than orderbook. Includes clear prerequisite workflow (use prediction_market_lookup if marketId unknown).

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

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

With no annotations provided, the description carries the full burden. It successfully discloses key behavioral traits: PnL fields may be blank (nullability), Side Held semantics are explained, and it warns against data substitution errors. Lacks only explicit read-only/safety declarations or rate limit warnings.

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

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

Excellent structure with clear markdown headers (When to use, Key fields, Pitfalls, Prerequisites). Information is front-loaded with the purpose statement, and every sentence provides actionable guidance. No redundancy or filler content.

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

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

Given the output schema exists, the description appropriately focuses on usage context, pitfalls, and field semantics rather than return values. Covers the essential complexity (blank field handling, side exposure interpretation). Minor gap: lacks explicit mention of read-only nature.

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

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

Context signals indicate 0% schema description coverage, requiring the description to compensate. While the Prerequisites section references marketId, it fails to describe its format (numeric string), omits the page parameter entirely, and does not explain pagination behavior. This leaves critical input semantics undocumented.

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

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

The description opens with a precise declaration ('PnL leaderboard for a Polymarket market') specifying the resource (leaderboard), metric (PnL), and domain (Polymarket). It clearly distinguishes from sibling tools like prediction_market_top_holders via the Pitfalls section, which explicitly warns against substituting top holders data.

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

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

Provides explicit when-to-use guidance ('Only for profitability claims'), specific prerequisites ('If marketId is unknown, call prediction_market_lookup first'), and clear anti-patterns ('do not substitute top holders'). This gives the agent clear decision boundaries against alternative tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about output interpretation: clarifying that Position Value USD is marked value not final payout, and that Cost Basis/Unrealized PnL apply to the displayed row only rather than total wallet activity. Lacks explicit statement that this is read-only/safe.

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?

Uses bold headers (**Key fields**, **Prerequisites**) to structure information efficiently. Every sentence provides specific guidance on output interpretation or usage prerequisites 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 presence of an output schema, the description appropriately focuses on explaining field semantics (what Position Value USD represents, scope limitations of PnL) rather than return structure. Prerequisites are covered. Only gap is the lack of input parameter detail given the reported 0% schema coverage.

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

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

Context signals indicate 0% schema description coverage, requiring the description to compensate. While the Prerequisites section mentions `marketId`, the description fails to explain its format, constraints, or the optional `page` parameter, and does not address the complex nested `request` object wrapper structure shown in the schema.

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

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

The opening sentence 'Detailed position breakdown for a Polymarket market' provides a specific verb (breakdown) and resource (position/market), clearly distinguishing this from sibling tools like prediction_market_lookup (discovery) or prediction_market_trades (activity feed).

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 Prerequisites section explicitly states: 'If `marketId` is unknown, call `prediction_market_lookup` first,' providing clear guidance on when to use a sibling tool as an alternative/preliminary step.

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 critical behavioral traits including literal-style (non-fuzzy) matching, the prohibition on inventing nearest matches for empty results, and strict constraints on interpreting superlatives and rankings. Minor gap regarding rate limits or caching.

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

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

Appropriately sized with excellent structure using bold headers (**When to use**, **Query tips**, **Output rules**). Information is front-loaded with the core purpose in the first sentence, and every sentence provides actionable guidance 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 (three discovery modes, sorting, filtering) and the existence of an output schema, the description is comprehensive. It covers selection criteria, invocation constraints, and result interpretation. Minor gap regarding pagination behavior beyond the 'page' parameter's existence.

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

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

Context signals indicate 0% schema description coverage (though nested schema fields do have descriptions). The description adds substantial semantic meaning for the 'query' parameter (literal matching, short fragments, no bundling) and implies 'mode' options (markets/events/categories), but does not explicitly document 'page', 'status', or 'orderBy' parameters.

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

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

The description opens with a specific verb+resource combination ('Browse and sort Polymarket markets, events, or categories') and explicitly distinguishes from the sibling tool 'prediction_market_lookup' by stating when NOT to use this tool ('Do NOT use this to resolve one named market/event/slug/URL').

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' section covering broad discovery scenarios and a clear exclusion case with named alternative ('use prediction_market_lookup instead'). Additional 'Query tips' and 'Output rules' sections provide concrete operational guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains field semantics (e.g., 'Positions are share balances, not USD notional') and data limitations ('Output summary is based only on shown rows, not the entire holder table'), adding crucial context about what the data represents and its constraints.

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 employs a clear hierarchical structure with **Key fields**, **Pitfalls**, and **Prerequisites** sections. Every sentence serves a specific purpose—either clarifying output semantics, warning against misinterpretation, or guiding prerequisite workflow—with minimal 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?

For a financial data tool with interpretation risks, the description adequately covers output field meanings and common pitfalls. Since an output schema exists (per context signals), the description appropriately focuses on semantic interpretation rather than repeating structural return values, though it could mention data freshness or latency.

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

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

Given the 0% schema description coverage reported, the description must compensate for undocumented parameters. It only partially addresses this by mentioning `marketId` in the Prerequisites section, but fails to describe pagination controls (`page`, `orderBy`, `orderByDirection`) or their behavior, leaving significant gaps in parameter understanding.

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

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

The opening sentence 'Largest current holders for a Polymarket market' clearly identifies the resource (Polymarket market holders) and scope. It effectively distinguishes from siblings like `prediction_market_trades` or `prediction_market_screener` by focusing specifically on holder concentration, though it uses a noun phrase rather than an active verb construction.

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 **Prerequisites** section explicitly states 'If `marketId` is unknown, call `prediction_market_lookup` first,' providing clear guidance on when to use an alternative tool. The **Pitfalls** section further guides interpretation by warning against inferring risk or smart-money status without proper data support.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral context through the 'Key fields' section (clarifying Share Size vs Value USD semantics) and 'Pitfalls' (warning that large visible trades do not identify smart money). Deducted one point for not mentioning rate limits, caching behavior, or error states.

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

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

Excellent structure with markdown headers (When to use, Key fields, Pitfalls, Prerequisites) that front-load critical information. Every sentence serves a specific purpose—either guiding usage, explaining data semantics, or warning against misuse. No redundant or filler text.

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

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

Given the existence of an output schema, the description appropriately focuses on usage guidelines and domain-specific interpretation (field meanings, pitfalls) rather than return values. Covers the essential workflow (lookup marketId first) and data interpretation. Deducted one point for not explaining the date range token syntax or pagination behavior given the schema complexity.

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

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

Context signals indicate 0% schema description coverage, requiring the description to compensate. While it mentions `marketId` in the prerequisites section, it fails to document the `page` parameter, the `dateRange` object structure, or the requirement to wrap parameters in a `request` object. Partial credit for the marketId workflow guidance.

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 opening sentence 'Recent trades for a Polymarket market' provides a specific verb (implied retrieval of trades), resource (Polymarket market), and scope (recent). It effectively distinguishes from sibling tools like prediction_market_ohlcv by explicitly warning 'Do not overwrite recent trade prices with older OHLCV candles.'

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

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

Contains an explicit 'When to use' section identifying this as the 'source of truth for recent fills and latest trade-tape pricing.' Provides clear prerequisites ('If `marketId` is unknown, call `prediction_market_lookup` first') and warns against conflating this data with OHLCV candles, creating a clear decision boundary.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes key behavioral traits: the data source (Hyperliquid perpetual futures), temporal scope (recent trades only, no date filtering available), and output format (detailed columns with descriptions). However, it doesn't mention pagination behavior (though the schema includes a 'page' parameter) or rate limits.

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

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

The description is well-structured and appropriately sized. It begins with the core purpose, provides usage guidelines, notes important limitations, details output columns, explains sorting options, and gives practical examples. Every sentence adds value with zero waste, and information is logically organized for easy consumption.

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

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

Given the tool's complexity (querying smart money trades with multiple filtering options) and the presence of an output schema, the description provides excellent contextual completeness. It covers purpose, alternatives, limitations, output format, sorting options, and usage examples. The output schema will handle return value details, so the description appropriately focuses on operational 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?

The schema description coverage is 0%, so the description must compensate. It provides substantial parameter semantics through the examples section, showing how to use sorting options ('order_by', 'order_by_direction') and filtering parameters ('action', 'side', 'includeSmartMoneyLabels'). It also lists all columns returned, which helps understand output structure. However, it doesn't explain all parameters like 'valueUsd' range filtering or 'traderAddress'.

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

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

The description clearly states the tool's purpose with specific verbs ('Get recent Hyperliquid perpetual futures trades') and resources ('from Smart Traders and Funds across all tokens'). It explicitly distinguishes this tool from its sibling token_discovery_screener by explaining this provides granular activity while that tool provides a big picture view.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It states 'For a big picture view of smart traders and funds activity across all tokens, use token_discovery_screener with onlySmartTradersAndFunds filter,' clearly naming the alternative tool and specifying the appropriate filter. It also notes this endpoint is Hyperliquid-only and returns recent trades only with no date filtering.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions aggregation (not per wallet), exclusion criteria (EXCLUDES whales, etc.), and chain querying behavior. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, rate limits, authentication requirements, pagination behavior (though 'page' parameter exists), or what happens when filters return no results. The description provides some context but leaves significant gaps.

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

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

The description is appropriately concise (two sentences) and front-loaded with the core purpose. The first sentence contains the essential information, and the second adds usage guidance. There's no wasted text, though it could be slightly more structured for clarity.

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

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

Given the tool's moderate complexity (8 parameters via nested object), no annotations, 0% schema description coverage, but with an output schema present, the description is minimally adequate. It covers the core purpose and some behavioral context but leaves many parameters unexplained. The output schema existence means return values don't need description, but parameter documentation is insufficient.

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 for undocumented parameters. The description only mentions 'chains' parameter behavior (default is ['all']) and 'filters' generically. It doesn't explain the 8 specific parameters in the schema (page, orderBy, minHolders, etc.) or their semantics. The description adds minimal value beyond what's implied by the tool name.

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

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

The description clearly states the tool's purpose: 'Get aggregated (not per wallet) smart trader and fund token balances and 24h change per chain.' It specifies the resource (smart trader and fund token balances) and verb (get aggregated data), and distinguishes from whales/large holders. However, it doesn't explicitly differentiate from sibling tools like 'smart_traders_and_funds_perp_trades' or '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 provides some usage context: 'Use filters to narrow down the results' and mentions default behavior for chains. However, it doesn't explicitly state when to use this tool versus alternatives like 'smart_traders_and_funds_perp_trades' (for perp trades) or 'token_current_top_holders' (for non-smart money holders). The guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries full burden and delivers comprehensive behavioral information. It discloses pagination limits (25 per page), mode-specific behaviors, sorting options, native token restrictions, error-prone tokens to avoid, and detailed column outputs for both modes. This goes far beyond basic functionality 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?

The description is well-structured with clear sections (Note, Modes, Columns, Sorting, Examples, Restrictions) but is quite lengthy. While every section adds value, some redundancy exists in the examples. The core information is front-loaded effectively with the purpose statement and key notes.

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

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

Given the tool's complexity (two distinct modes, multiple parameters, special restrictions) and absence of annotations, the description provides complete context. It covers purpose, usage guidance, behavioral details, parameter explanations, output format (via column descriptions), and error avoidance. The presence of an output schema reduces need to explain return values, but the description still provides valuable column semantics.

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 schema description coverage being 0%, the description compensates fully by explaining all key parameters through examples and context. It clarifies mode differences, label_type usage, filtering capabilities, sorting options, and special restrictions for native tokens. The examples demonstrate how parameters interact in practical scenarios.

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 immediately states the specific action ('Get upto 25 (per page) top holders information for a specific token') with clear resource scope. It distinguishes from siblings by focusing on current top holders rather than historical data, flows, or portfolio information found in other tools like token_flows, address_historical_balances, or address_portfolio.

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

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

The description provides explicit guidance on when to use specific features (warning about smart_money label as 'not a good proxy for an overall market view'), distinguishes between two operational modes with different use cases, and offers multiple concrete examples showing different scenarios. It also explicitly states restrictions for native tokens and tokens that will cause errors.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns DEX trading activity as markdown, specifies what happens when no trades are found ('Returns empty string if no trades found'), details the output format with columns for each mode, and explains sorting options. It lacks explicit rate limits or authentication requirements, but covers core behavioral aspects 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?

The description is well-structured with clear sections (Modes, Args, Returns, Common Columns, mode-specific columns, Sorting Options, Examples). It is appropriately sized for a complex tool, though slightly lengthy. Every sentence adds value, such as explaining column meanings and providing practical examples, with 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 tool's complexity (two modes, many parameters, no annotations, but with output schema), the description is highly complete. It covers purpose, usage, behavior, parameters, output format, and examples. The output schema existence means return values need not be detailed, but the description still usefully explains the markdown format and columns. It addresses all contextual needs for effective tool invocation.

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

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

Despite 0% schema description coverage, the description compensates fully by explaining parameter semantics. It details the 'request' object, describes modes, provides examples with parameter usage (e.g., dateRange, order_by, action, side), and clarifies filtering options. The examples illustrate how to structure requests for different use cases, adding significant value beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Get DEX trades for a specific token.' It specifies the verb ('Get'), resource ('DEX trades'), and target ('specific token'), distinguishing it from siblings like token_ohlcv (price history) or token_transfers (transfers). The two modes (onchain_tokens and perps) further clarify scope.

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

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

The description provides explicit guidance on when to use this tool vs alternatives. It distinguishes between the two modes (onchain_tokens vs perps) and specifies their use cases (on-chain tokens by contract address vs Hyperliquid perpetual futures by symbol). The examples illustrate practical scenarios like 'whale watching' and 'price analysis,' helping the agent choose appropriate parameters.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses critical behavioral traits: result limits ('maximum of 25 results'), timeout risks, Hyperliquid special handling (perps vs. spot tokens, dual result sections), filter/orderBy fallbacks for unsupported options, and data sparsity warnings for smart money filters. It also explains output format (markdown with specific columns) and empty return cases.

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

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

The description is well-structured with clear sections (purpose, important notes, examples, warnings, filtering/sorting details), but it's quite lengthy. Every section adds value, though some redundancy exists between examples and parameter explanations. It's front-loaded with key information, but the volume of content slightly impacts 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 (many parameters, special cases like Hyperliquid, rich filtering), no annotations, and an output schema present, the description is exceptionally complete. It covers purpose, usage guidelines, behavioral details, parameter semantics, examples, warnings, and output format. The output schema handles return values, so the description appropriately focuses on input behavior and 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?

Despite 0% schema description coverage (schema has no parameter descriptions), the description comprehensively compensates. It provides detailed filtering options with numeric ranges and categories, sorting options with valid fields, critical warnings about invalid filters ('priceChange is NOT a valid filter'), and extensive input examples covering various use cases. The description adds substantial meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Get comprehensive token screening data across multiple blockchain networks with advanced filtering' and 'helps with token discovery and finding trending tokens by combining different metrics'. It specifies the resource (token data), action (screening/discovery), and distinguishes from siblings by focusing on multi-chain token screening with metrics like volume, liquidity, and smart money activity.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It includes warnings about chain limits ('maximum of 5 chains'), timeout recommendations ('Use 4 chains or less'), and special cases like Hyperliquid perps. It also distinguishes usage from other tools by its focus on token discovery across chains, unlike sibling tools that target specific addresses, transactions, or prediction markets.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a read operation ('Get'), provides hourly aggregated data, supports two modes with different interpretations (e.g., 'Inflows/Longs' vs 'Outflows/Shorts'), excludes native tokens in 'onchain_tokens' mode, and notes sign conventions in 'perps' mode. It could improve by mentioning rate limits or authentication needs, but covers core behaviors 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?

The description is well-structured with clear sections (purpose, note, comparison, modes, args, returns, columns, notes). Most sentences add value, such as distinguishing from siblings and explaining mode behaviors. It could be slightly more concise by integrating some notes into earlier sections, but overall it's efficient and front-loaded with key information.

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

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

Given the tool's complexity (multiple modes, segments, and parameters) and 0% schema description coverage, the description provides comprehensive context. It explains purpose, usage guidelines, behavioral traits, parameter semantics, and output format (including detailed column descriptions). With an output schema present, it appropriately focuses on clarifying inputs and behaviors rather than repeating return values, making it complete for agent use.

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

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

The input schema has 0% description coverage, so the description must compensate. It adds significant semantic context: explains 'holder_segment' options (Top 100 holders, Whale, etc.) and advises on 'smart_money' usage, describes 'mode' options ('onchain_tokens' vs 'perps') and their implications, and notes 'date range' usage. However, it doesn't detail 'tokenAddress' or 'chain' parameters, leaving some gaps.

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

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

The description clearly states the tool's purpose: 'Get hourly aggregated token flows for a specific segment of holders over a date range.' It specifies the verb ('Get'), resource ('token flows'), and scope ('hourly aggregated,' 'specific segment,' 'date range'). It distinguishes from sibling tool 'token_recent_flows_summary' by noting this is 'more granular' and provides 'TOTAL flows over the entire time frame broken down by segment.'

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It distinguishes from 'token_recent_flows_summary' by noting this is 'more granular' and provides 'TOTAL flows.' It advises caution with 'smart_money' segment: 'Use it only if user explicitly requests it, or to combine it with other non smart money data.' It also specifies modes ('onchain_tokens' vs 'perps') and notes unsupported tokens in 'onchain_tokens' mode.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes what information is returned in each mode (market cap, volume, funding rates, etc.) and mentions the output format (markdown). However, it lacks details about potential limitations, error conditions, rate limits, or authentication requirements that would be important for a production tool.

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

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

The description is well-structured with clear sections for each mode, return format, field details, examples, and notes. While somewhat lengthy, every section adds value. The purpose is front-loaded, and the information is organized efficiently without redundant content.

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

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

Given the tool's complexity (dual modes with different data types), no annotations, and an output schema present, the description provides substantial context. It thoroughly explains what data is returned in each mode, includes practical examples, and clarifies parameter usage. The main gap is lack of operational details like error handling or performance characteristics.

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

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

Despite 0% schema description coverage, the description compensates well by explaining the semantics of key parameters: it clarifies that 'mode' selects between on-chain tokens and perps, specifies that 'tokenAddress' means contract addresses for on-chain mode but symbols for perps mode, and explains 'timeframe' usage across both modes. The examples provide concrete parameter usage, though it doesn't cover all schema parameters like 'chain' in 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 the tool's purpose with specific verbs ('Get token information') and distinguishes between two distinct modes: on-chain token details and Hyperliquid perpetual futures stats. It explicitly differentiates from siblings by focusing on comprehensive token/perpetual information rather than specific aspects like trades, transfers, or portfolio data.

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

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

The description provides explicit guidance on when to use each mode: on-chain tokens mode for contract addresses and spot trading metrics, and perps mode for Hyperliquid perpetual futures using token symbols. It includes practical notes about parameter differences between modes and timeframe usage, offering clear alternatives within the tool itself.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains the automatic resolution logic based on date ranges (6 specific rules), lists all columns returned (6 base columns + 4 additional with includeMarketCap=true), provides format details (timestamp format), and includes 3 detailed usage examples. It also discloses chain limitations (EVM/Solana only, no Hyperliquid).

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, limitations, usage mandate, resolution rules, columns, examples). However, it's quite lengthy due to the detailed resolution table, column listings, and multiple examples. While all content is valuable given the lack of annotations and schema descriptions, it could be slightly more concise by integrating some information more tightly.

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 (automatic resolution, multiple output columns, chain restrictions) and the complete lack of annotations and schema descriptions (0% coverage), the description provides everything needed. It explains what the tool does, when to use it, behavioral details, parameter usage, and includes practical examples. The presence of an output schema means it doesn't need to explain return format, but it still helpfully lists the columns.

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

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

With 0% schema description coverage (the schema has no parameter descriptions beyond type definitions), the description must and does compensate fully. It explains the purpose of chain, tokenAddress, and date parameters through examples. It clarifies the includeMarketCap parameter by describing the additional columns it returns. The examples show exactly how to structure requests with different date ranges, providing practical 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 the tool's purpose: 'Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution.' It specifies the exact data retrieved (OHLCV + volume), the resource (token), and the automatic resolution feature. It also distinguishes from sibling 'general_search' by noting this tool provides more accurate, non-delayed data.

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

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

The description provides explicit usage guidance: 'YOU MUST USE THIS over `general_search` to get prices' and explains why (general_search prices are delayed/incorrect). It also specifies when NOT to use it: 'chain=Hyperliquid is a perps chain AND IS NOT supported for token_ohlcv' and 'ENDPOINT ONLY SUPPORTS EVM CHAINS AND SOLANA.' It even includes a specific use case: 'To get LATEST price set from to '5MIN_AGO' and to to 'NOW'.'

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 behavior: pagination limit ('ONLY RETURNS TOP 25 RESULTS'), output format ('markdown'), empty result handling ('Returns empty string if no trading data'), and critical constraints ('does not support native tokens', 'does not support hyperevm as chain'). It also explains default sorting and analysis utility.

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 (Modes, Returns, Sorting, Filtering, Examples, Notes), but it is lengthy due to comprehensive parameter explanations. Every sentence adds value (e.g., column definitions, constraints), though it could be more front-loaded; the core purpose is clear early, but details are extensive.

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 complexity (multiple modes, many filters), no annotations, and an output schema (implied by 'Returns' section), the description is highly complete. It covers input semantics, behavioral limits, output format, and usage context. The output schema likely details columns, so the description appropriately focuses on input guidance and constraints.

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

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

Schema description coverage is 0%, so the description compensates thoroughly. It explains modes, token/chain requirements, dateRange tokens, sorting/filtering options with examples, and advanced filtering logic. The examples clarify parameter usage (e.g., 'order_by' values, numeric ranges), adding significant meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: retrieving 'trader PnL for a token' with 'upto 25 results (per page)' and 'ranking' traders. It distinguishes from siblings like 'wallet_pnl_for_token' (individual wallet) and 'hyperliquid_leaderboard' (perps-only) by focusing on token-specific leaderboards across modes.

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 is provided: 'Use the sorting and filtering options to narrow down results,' with modes ('onchain_tokens' vs 'perps') and notes on limitations (no native tokens, no hyperevm chain). It contrasts with 'hyperliquid_leaderboard' by supporting both on-chain and perps, and with 'wallet_pnl_for_token' by being multi-trader.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (risk/reward indicators as markdown with interpretation guidance) and includes important notes about limitations ('Not all indicators available for every token/chain combination') and comparison methodology ('Percentile compares against same market cap group'). However, it doesn't mention potential rate limits, authentication requirements, or error conditions.

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

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

The description is well-structured with clear sections (purpose, usage, returns, token info, fields, indicator types, notes) and uses bullet points effectively. While comprehensive, it could be more concise by combining some sections or reducing repetition in the market cap group explanations.

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 (risk/reward analysis with multiple indicator types), no annotations, and an output schema present, the description provides excellent completeness. It thoroughly explains what information is returned, how it's structured, what the indicators mean, and important limitations. The output schema handles return format details, allowing the description to focus on semantic context.

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

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

With 0% schema description coverage for the single parameter (request), the description must compensate but doesn't directly address parameters. However, it implicitly clarifies the tokenAddress parameter by discussing what the tool analyzes ('for a token'), and the detailed output description helps understand what inputs are needed. The description adds substantial context about what the tool does, which partially 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 the tool's purpose: 'Get Nansen Score Indicators for a token - quantitative risk and reward signals.' It specifies the exact resource (token indicators) and distinguishes it from siblings like token_info or token_ohlcv by focusing on risk/reward analysis rather than general information or price data.

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

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

The description explicitly states when to use this tool: 'when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions.' This provides clear context for usage versus alternatives like token_info for basic details or token_ohlcv for price history.

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

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

With no annotations provided, the description carries full burden and does well: it explains what the tool returns (categorized token flow analysis as markdown with specific metrics), defines positive/negative flow meanings for general segments and exchanges, and discloses important limitations (Bitcoin/Hyperliquid not supported). It doesn't mention rate limits or authentication needs, but 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?

Well-structured with clear sections (purpose, usage guidance, returns format, notes). Some repetition exists (two notes about 'token_flows' alternative and two Bitcoin/Hyperliquid warnings), but overall it's efficiently organized with front-loaded critical information.

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

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

Given the tool's complexity (analyzing token flows across 6 segments) and no annotations, the description does well: explains purpose, provides detailed usage guidelines, describes return format, and gives important behavioral notes. With an output schema present, it doesn't need to explain return values in detail. The main gap is incomplete parameter 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?

Schema description coverage is 0%, so the description must compensate. It mentions 'lookback period' and gives examples (last 5min, 1d, 7d etc.), which helps explain one parameter. However, it doesn't address the 'chain' and 'tokenAddress' parameters at all. The description adds some value but doesn't fully compensate for the schema coverage gap.

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

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

The description clearly states the tool's purpose: to get total token flows per segment (listing all 6 segments) and explains it aggregates over a lookback period. It distinguishes from sibling 'token_flows' by specifying this tool provides aggregated summaries while that one offers granular data with exact date ranges and hourly breakdowns.

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 is provided on when to use this tool vs. alternatives: use this for aggregated summaries over lookback periods; use 'token_flows' for specific date ranges and hourly breakdowns. Clear exclusions are stated: Bitcoin and Hyperliquid are not supported.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behaviors: pagination (25 per page), default sort order (most recent first), supported/non-supported tokens (no native tokens), and detailed filter behaviors. It explains what 'smart money' means and how filters work. The only minor gap is lack of explicit rate limit or authentication requirements.

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

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

The description is well-structured with clear sections (description, columns, sorting, examples, available filters, notes). While comprehensive, it's appropriately sized for a complex tool with many parameters. Some redundancy exists (e.g., filter explanations repeated in examples), but overall each section earns its place by providing necessary context for proper tool invocation.

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

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

Given the tool's complexity (multiple filters, sorting options), no annotations, and the existence of an output schema (which handles return values), the description is remarkably complete. It covers purpose, constraints, parameters with semantics, examples, and behavioral context. The output schema existence means the description doesn't need to explain return format, allowing it to focus on usage guidance and parameter understanding.

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

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

Schema description coverage is 0%, so the description must fully compensate. It provides extensive parameter semantics: detailed explanations of all filters (address filters, transfer origin categories, smart money filter, numeric range filter), sorting options with examples, and comprehensive examples showing parameter usage. The description adds significant value beyond what the bare schema provides.

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

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

The description clearly states the tool's purpose: 'Get 25 token transfers (per page) for a specific token based on the sort order.' It specifies the verb ('Get'), resource ('token transfers'), scope ('per page'), and key constraint ('for a specific token'). It distinguishes from siblings like token_dex_trades (only DEX trades) or token_flows (different flow metrics) by focusing specifically on transfers with filtering capabilities.

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

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

The description provides clear context for when to use this tool: for retrieving token transfers with various filters. It explicitly states when NOT to use it: 'This tool does not support native tokens.' However, it doesn't explicitly mention alternatives among sibling tools (e.g., token_dex_trades for only DEX trades or address_transactions for wallet-level activity), which prevents a perfect score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns aggregated buyer/seller activity as markdown, returns empty string if no data found, lists all columns returned, explains sorting options, notes how the buy_or_sell parameter filters results, and clarifies that it aggregates all trading activity within the time range. This covers output format, error handling, and operational details 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?

The description is well-structured and concise, with each section (purpose, usage, returns, columns, sorting, notes) adding clear value. It uses bullet points and headings effectively, and every sentence earns its place by providing essential 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 complexity of the tool (multiple parameters, no annotations, 0% schema description coverage, but with an output schema), the description does a good job of covering purpose, usage, output format, and key behaviors. However, it lacks details on parameter semantics beyond buy_or_sell and time range, which is a gap given the schema's poor coverage. The output schema likely handles return values, so the description's focus on other aspects is appropriate.

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

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

Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description mentions the 'buy_or_sell parameter filters for "BUY" (net buyers) or "SELL" (net sellers)' and implies a time range parameter, but it doesn't explain other parameters like chain, tokenAddress, page, order_by, include_labels, order_by_direction, or min_trade_volume_usd. It adds some value but doesn't fully compensate 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 TOTAL amount of tokens bought/sold by address for a token on DEX (Decentralised Exchanges) ONLY.' It specifies the verb ('Get'), resource ('tokens bought/sold by address'), and scope ('on DEX ONLY'), distinguishing it from siblings like token_transfers or token_dex_trades which have different focuses.

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

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

The description provides explicit usage guidance: 'Use this tool to find out WHO is buying or selling a token (on DEX) AND then you can check if they are liquidating profits or accumulating more.' It clarifies the tool's specific use case for analyzing trader behavior on DEXs, helping differentiate it from other tools like token_current_top_holders or wallet_pnl_for_token.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'comprehensive transaction details' and 'pagination settings' in the Args section, but fails to specify critical aspects like rate limits, authentication needs, error handling, or whether it's a read-only operation. This leaves significant gaps for a tool that likely queries external data.

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

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

The description is front-loaded with the core purpose, followed by structured Args and Returns sections, making it efficient. However, the Args section could be more concise by integrating details into the main text, and some redundancy exists (e.g., 'transaction details' repeated).

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

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

Given the tool's complexity (querying transaction details with pagination), no annotations, and an output schema present (which covers return values), the description is moderately complete. It outlines the purpose and parameters but lacks behavioral context and usage guidelines, making it adequate but with clear gaps for effective agent use.

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

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

The schema description coverage is 0%, but the description adds value by naming the parameter as 'TransactionLookupRequest' and hinting at 'parameters and pagination settings'. However, it doesn't detail what 'parameters' include beyond 'transaction_hash' or explain pagination behavior, so it only partially 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 the verb 'Get' and resource 'comprehensive transaction details including token transfers', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'address_transactions' or 'token_transfers', which might overlap in functionality, preventing a perfect score.

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

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

No guidance is provided on when to use this tool versus alternatives, such as 'address_transactions' for transactions by address or 'token_transfers' for token-specific transfers. The description lacks context on prerequisites or exclusions, leaving the agent to infer 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 full burden of behavioral disclosure. It mentions the tool retrieves PnL stats but doesn't describe what those stats include (e.g., profit/loss amounts, percentages, timeframes), whether it requires authentication, rate limits, or how it handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

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

The description is concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence adds value without redundancy, making it easy to understand quickly.

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 (PnL analysis with multiple parameters), no annotations, and 0% schema description coverage, the description is incomplete. It lacks details on behavioral traits, parameter semantics, and output specifics. However, an output schema exists, which may cover return values, preventing a lower score. The description provides a basic overview but misses critical 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?

The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'input address,' 'specific token,' and 'date range,' which loosely map to parameters like walletAddress, tokenAddress, and dateRange, but it doesn't explain parameter meanings, formats (e.g., address formats, date syntax), or the required 'showRealized' parameter. It adds minimal value beyond the schema.

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

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

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

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

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

The description provides some usage guidance: 'Use this tool for analysing the performance of the wallet for the specific token over a time period.' This implies when to use it (for token-specific PnL analysis over time) but doesn't explicitly state when not to use it or mention alternatives like 'wallet_pnl_summary' for aggregated PnL. The guidance is helpful but not comprehensive.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool excludes unrealized PnL and is for analyzing performance over time, which is useful. However, it lacks details on permissions, rate limits, error handling, or what the output schema contains (e.g., specific stats like total profit/loss). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

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

The description is front-loaded with the core purpose and key limitation (no unrealized PnL), followed by usage guidance. It uses four sentences efficiently, with minimal redundancy. However, the last two sentences are slightly repetitive ('analyse the performance' vs 'analyse the wallet portfolio performance'), which could be streamlined.

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 there is an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and a tool focused on financial analysis (which can be complex), the description is incomplete. It covers purpose and exclusions but lacks details on parameter usage, behavioral traits like data freshness or limitations, and how it integrates with sibling tools.

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

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

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'input address' and 'time period,' which loosely map to 'walletAddress' and 'dateRange,' but provides no details on parameter formats, required fields, or the 'chain' parameter. It fails to compensate for the schema's lack of descriptions, leaving parameters poorly understood.

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

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

The description clearly states the tool's purpose: 'Get aggregate stats of overall realized PnL for the input address.' It specifies the verb ('Get'), resource ('aggregate stats'), and scope ('realized PnL'), distinguishing it from tools like 'wallet_pnl_for_token' which focuses on specific tokens. However, it doesn't explicitly differentiate from all siblings like 'address_portfolio' or 'address_historical_balances' in terms of performance analysis.

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

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

The description provides clear guidance on when to use this tool: 'Use this tool for analysing the performance of the wallet over a time period.' It also explicitly states when not to use it: 'Note, this tool DOES NOT include unrealized PnL. For unrealized PnL you need to check change in token prices of the current holdings.' This helps differentiate it from tools that might include unrealized gains. However, it doesn't name specific alternative tools for related analyses.

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