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

No annotations are provided, so the description bears full behavioral disclosure burden. It discloses pagination (25 per page), default sorting (net value), return content (top 3 tokens per counterparty), clamping behavior for time ranges (max 365 days), and sorting options. This is thorough but could mention rate limits or auth requirements.

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

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

The description is well-structured with a clear main statement, a bulleted 'Note' section, sorting options list, and two JSON examples. It is somewhat lengthy but every section serves a purpose, and the examples clarify usage. Slightly verbose but justified by 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 input options, sorting, grouping, time range) and the presence of many sibling tools, the description covers purpose, usage, behavior, and parameter semantics comprehensively. An output schema exists to document return values, so the description is complete without needing to detail return fields.

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

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

The description adds significant meaning beyond the input schema, such as default sort order, per-page count, return structure details, and time range clamping. It also explains sorting fields and provides examples. Despite context signal of 0% schema coverage, the actual schema includes field descriptions, but the description enriches them substantially.

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'. This specific verb+resource definition distinguishes it from sibling tools like address_transactions or address_related_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 includes a 'Note' section with explicit guidance on how to use the tool effectively (focus on direct value transfers, include CEX deposit addresses, go one level deeper). It provides context for when to use it but does not explicitly exclude alternatives or state when not to use it.

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

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

With no annotations, description covers main behavior: returns trades newest first, columns listed, sort/filter options. Missing details on pagination (page parameter not described) and error handling for invalid addresses. Adequate but not comprehensive.

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

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

Description is well-structured: opening sentence, chain rules, columns, filter/sort, then example. Front-loaded with purpose. Slightly long but every sentence earns its place; no filler.

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

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

Given complexity (multiple parameters, no annotations, output schema exists), description covers input well but omits pagination behavior and potential errors. With output schema present, return details are assumed, but behavioral 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% per context, so description must compensate. It provides meaning for address, chain constraints, dateRange, orderBy, valueUsd filter, and sort order. Example clarifies usage. Does not fully explain all parameters (e.g., page is undocumented), but adds significant 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?

Description states 'Get a wallet's individual DEX trades (token swaps) on a single chain' with specific details on returned data (bought/sold token pair, amounts, USD value, newest first). Clearly distinguishes from sibling token_dex_trades by being wallet-centric.

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

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

Description explains when to use this tool (wallet-centric), compares to token_dex_trades, and specifies chain constraints ('all'/'evm' unsupported, EVM wallets must pass chain explicitly, non-EVM auto-detected). Lacks explicit alternatives for other wallet tools, but sibling list provides 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 disclosing behavioral traits such as pagination, data scope, or rate limits. The description only states the basic action, omitting any additional behavioral context.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded with the key action and resource.

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?

Despite having an output schema, the tool's description does not explain mutual exclusivity of address/entity_id parameters, default values, or the result structure. For a tool with multiple parameter options and constraints, the description is insufficiently complete.

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

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

Schema description coverage is 0%, meaning the tool description does not describe parameters. While the input schema includes descriptions for sub-properties (e.g., address, entity_id), the tool description itself adds no parameter semantics. The agent receives no extra guidance 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 verb 'Get' and the resource 'historical native coin & token balances of address'. It distinguishes from sibling tools like address_portfolio (current portfolio) and address_transactions (transaction history) by specifying 'historical' and 'balances'.

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 (e.g., address_portfolio for current balances, token_current_top_holders for holder lists, etc.). It lacks explicit statements of context, prerequisites, or alternatives.

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

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

No annotations are provided, but the description fully discloses behavioral traits: which data each mode returns, output format (markdown vs raw JSON), and that entities only return token balances. It covers all important aspects without contradiction.

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

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

The description is somewhat long but well-structured with clear sections, bullet points, and examples. It front-loads the main verb and resource, then details modes. Could be slightly more concise, but the structure aids readability.

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

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

Given the complexity (multiple modes, entity vs wallet, output format differences) and the presence of an output schema, the description is complete. It explains all essential aspects without relying on the output schema for return value details.

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

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

Schema description coverage is 0% (the schema's own descriptions are insufficient), but the tool description compensates with detailed explanations of each mode and parameters. It adds meaning beyond the schema, especially for 'mode' and the mutual exclusivity of walletAddress/entity_id.

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

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

The description clearly states the tool provides a comprehensive portfolio overview for a wallet address or entity. It distinguishes between wallet addresses and entities, and lists the different modes and their focuses. This distinguishes it from sibling tools like address_counterparties, address_dex_trades, etc.

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: when to use wallet modes vs entity, the meaning of each mode, required mutual exclusivity of walletAddress and entity_id, and output format differences. Example JSON for each use case is given, making it easy for an agent to select and invoke correctly.

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

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

The description discloses that the tool only returns a predefined set of 'special' connections and clarifies the nature of first funder addresses. However, it does not explicitly state that the operation is read-only, which is a minor gap given the absence of annotations.

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

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

The description is concise, front-loaded with the primary purpose, and includes a bulleted list of connection types. Every sentence adds value, with no redundant or extraneous 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 has an output schema, the description does not need to detail return values. It adequately covers the scope of the tool, the specific connections, and provides cross-reference to a sibling tool. The caveat about exchange addresses adds necessary context for correct 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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add significant information beyond what is in the schema; it restates the purpose but does not explain the structure of the 'request' object or the meaning of its sub-properties.

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

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

The description explicitly states it retrieves information about related addresses and lists the specific connection types included. It distinguishes itself from the sibling tool address_counterparties by advising to check that tool for broader related wallets.

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: 'To get related wallets, also check address counterparties.' It also includes a caveat about first funder exchange withdrawal addresses, clarifying that they usually do not belong to the same entity.

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?

Without annotations, the description carries the burden. It discloses that it returns 20 most recent transactions per page and filters by date range. However, it does not mention pagination details beyond 'per page', default values, rate limits, or whether it is read-only.

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 two sentences long, front-loads the core purpose, and contains no extraneous information. Every word earns its place.

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

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

Despite the presence of an output schema, the description does not explain the output format or the structure of the required 'request' parameter. It omits details about default date range, chain support, and spam filtering, leaving significant gaps for agent usage.

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% and the description does not explain any of the parameters (request, page, chain, address, dateRange, hideSpamToken). It adds no value beyond what the schema provides, which itself has no 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 verb 'Get' and the resource 'list of transactions made by an address', and specifies constraints (20 most recent, per page, date range). It distinguishes from sibling tools by focusing on generic address transactions rather than specific token transfers or single transactions.

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

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

No guidance is provided on when to use this tool versus alternatives like transaction_lookup or token_transfers. There is no mention of context or exclusion criteria 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?

No annotations are provided, so the description carries full burden. It discloses the tool's behavior: searches tokens, entities, addresses; returns price, volume, contract, chain, market cap, labels, domain resolution; has max_results and result_type filters; does not support NFTs or prediction markets. It does not mention data freshness, rate limits, or pagination details, but covers key behavioral traits 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: a single opening sentence for purpose, followed by warnings and a bulleted list of capabilities. Every sentence is informative and necessary. It is front-loaded with the most critical information and avoids 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 (4 parameters, many sibling tools, output schema exists), the description is complete. It explains the tool's scope, what it returns, parameter usage, and exclusions. The existence of an output schema reduces the need to detail return values, and the description adequately covers the remainder.

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

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

Schema description coverage is 100%, baseline 3. The description adds significant value beyond schema: it explains usage conventions ('DO NOT include chain name here!'), notes valid chain values, and describes what each result_type returns. This enhances parameter understanding beyond the schema definitions.

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 is a general search first entry point for tokens, entities, and addresses. It explicitly distinguishes from prediction market queries by naming the alternative tool `prediction_market_lookup`, and notes Nansen MCP does not support NFTs but advises to check if the query relates to a token. This provides specific verb+resource and distinguishes from siblings.

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

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

The description gives explicit when-to-use ('first entry point'), when-not-to-use (prediction markets), and names the alternative tool. It also provides parameter usage advice (e.g., 'DO NOT include chain name here!' and 'ALWAYS use this parameter instead of adding chain name to the query string'). This is comprehensive usage 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?

Annotations are absent, so the description carries full responsibility for behavioral disclosure. The description only states the tool 'gets' rankings, implying read-only, but does not address authentication, rate limits, or error scenarios. More detail would be beneficial.

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?

Single sentence, under 20 words, front-loaded with the key action and resource. No unnecessary words or redundancy. Excellent 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 presence of an output schema (not shown), the description does not need to explain return values. However, for a tool returning rankings, absence of details on sorting or pagination context makes it slightly incomplete. Still adequate.

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

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

Schema coverage is 100% with descriptions for each parameter (chain_type and time_frame). The tool description does not add additional semantics beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves chain growth rankings with specific criteria (active addresses, transactions, gas fees, DEX volume). The verb 'Get' and resource 'chain growth rankings' are explicit. Although not explicitly differentiated from siblings, the focus on chain-level growth distinguishes it from address/token tools.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, use cases, or exclusions. An agent would have to infer usage from the tool name and description alone.

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

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

The description mentions the return format (markdown), columns, and sorting/filtering options. However, it does not disclose pagination behavior, data freshness, or any error/edge-case handling. Since there are no annotations, the description carries a moderate burden but falls short of full transparency.

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

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

The description is well-structured with clear sections (introduction, returns, columns, sorting/filtering, example, notes). It is not overly verbose and every section adds value, though some sentences could be slightly more compact.

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

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

Given the presence of an output schema and the detailed description of columns and filtering, the tool description is fairly complete. It explains the return format and provides an example. However, it lacks information on pagination (the parameter 'page' is not mentioned) and potential API limits.

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

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

The description adds context beyond the input schema by listing the specific columns returned and the fields available for sorting/filtering (totalPnl, accountValue, roi). It also provides a concrete example. The schema already contains parameter descriptions, so the description enriches understanding without redundancy.

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

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

The description clearly states the verb 'Get' and the specific resource 'Hyperliquid perpetual futures trader leaderboard with performance metrics'. It distinguishes itself from sibling leaderboard tools (e.g., token_pnl_leaderboard) by specifying the Hyperliquid perpetual futures domain.

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. Sibling tools include many other leaderboards and trader-related tools, but the description lacks explicit when-to-use or when-not-to-use instructions.

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

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

No annotations provided, but description fully discloses behavior: pre-filtered by performance_score >=15, explains scoring ranges, notes dynamic indicator columns, and instructs agent to explain thresholds to user. No contradictions.

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

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

Well-structured with clear sections, front-loaded purpose and usage. Uses markdown headings and bullet points. Every sentence adds value; no fluff.

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

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

Given only one simple parameter and the presence of an output schema, the description covers purpose, usage, scoring, and return format sufficiently. Agent can correctly invoke and interpret results.

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

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

Only one parameter 'request' with an optional marketCapGroup. The schema already describes marketCapGroup. The tool description does not elaborate on the parameter beyond its existence. Schema coverage is 0% for the outer parameter, but the inner field has description; still, description adds no extra semantic value.

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

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

The description clearly states it ranks top tokens by Nansen Score, and distinguishes from sibling tools like token_discovery_screener and token_quant_scores. The title reinforces this.

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

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

Explicitly tells when to use (don't know tokens to buy, need recommendations) and when not (use token_quant_scores for specific token, token_discovery_screener for live data/custom criteria). Provides clear 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, the description partially compensates by explaining that blank PnL fields mean unavailable data (not zero) and clarifying the meaning of Position Size vs. Position Value. However, it does not disclose any side effects, rate limits, or address validation 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 short, front-loaded, and uses bullet points to highlight key output fields. Every sentence adds value without redundancy.

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

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

The description covers important output interpretation (blank fields, position semantics). Although it omits pagination details, the schema documents the 'page' parameter. Given the tool's simplicity, the description is largely complete.

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

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

The input schema has brief descriptions for the 'address' and 'page' parameters. The tool description adds value by explaining output fields (blank handling, position interpretation), but it does not elaborate on the request parameter structure or provide additional parameter-level guidance beyond the schema.

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

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

The description clearly states it provides a 'PnL breakdown for a Polygon wallet', specifying the resource (prediction market PnL for a wallet) and verb (checking). This distinguishes it from sibling tools like prediction_market_address_summary and prediction_market_position_detail.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when-not to use, or comparison to sibling 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, the description carries full burden. It notes that empty PnL/ROI fields mean unavailable data, not zero, which adds transparency. However, it does not explicitly state that the tool is read-only or safe, nor does it discuss error behavior or API limits. Still, it provides useful context beyond the schema.

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

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

The description is concise with three short paragraphs. The first sentence states purpose, followed by clear usage guidelines and key fields. Every sentence adds value, and it is front-loaded with the most important 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 complex input schema with anyOf and low schema coverage, the description should explain the request structure more thoroughly. It does mention the address and key output fields, and with an output schema present, return values need not be detailed. However, the pagination parameter is not addressed, leaving a gap for completeness.

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

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

Schema coverage is 0%, so the description must compensate. It states the tool requires a 'Polygon wallet address,' which is the key input, but does not explain the complex anyOf structure of the 'request' parameter or the 'page' field. The description adds some context but insufficiently clarifies input syntax.

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 lists key fields and explicitly differentiates from sibling tools like prediction_market_address_pnl and prediction_market_address_trades by positioning itself as a first wallet-level Polymarket tool for a quick overview.

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

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

The description includes a 'When to use' section with two bullet points: 'First wallet-level Polymarket tool for a quick trader overview' and 'Use before detailed address trades/PnL when the user asks for a general wallet profile, activity summary, or whether a wallet is active on Polymarket.' This provides clear guidance and alternatives.

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

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

No annotations are provided, so the description must carry the full burden. It explains key fields (Share Size, Value USD) to prevent misinterpretation and warns about pitfalls (not for profitability). However, it does not disclose whether the tool is read-only, required permissions, rate limits, or how it handles missing data. It adds value beyond the schema but is incomplete for a tool without annotations.

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

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

The description is extremely concise: three short items (purpose, key fields, pitfalls) with no extra fluff. Every sentence adds value, and the structure is front-loaded with the purpose. Ideal for quick scanning by an AI agent.

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

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

The tool has an output schema (context signals say yes), so return values are covered. However, the description does not mention the 'request' parameter's structure or how to use date range tokens, pagination, or the address field. Given that the schema partially includes descriptions, the description still lacks completeness for a tool with one complex nested parameter. Leaves gaps about constructing the request correctly.

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

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

Schema description coverage is 0%, so the description should compensate, but it does not explain how to structure the 'request' parameter. The schema itself provides descriptions for sub-properties (e.g., address, page, dateRange), so the schema is partially descriptive. The description adds no parameter guidance, only output field explanations. With 0% coverage, a score of 2 is appropriate as it falls short of compensating.

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 'Prediction market trade history for a Polygon wallet.' This distinguishes it from sibling tools like prediction_market_address_pnl (profit/loss) and prediction_market_address_summary (summary). The verb 'trade history' and resource 'Polygon wallet' are specific and immediately informative.

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

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

The description explicitly says 'Use this for wallet trade activity, not profitability,' which provides a clear when-not usage. However, it does not compare to other wallet tools or mention alternatives, losing a point for limited comparative 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?

No annotations provided, but description explains that results include current prices, last trade price, and bid/ask inline. It also states output rules (say explicitly if no suitable market). Could mention read-only nature, but adequate.

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

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

Well-structured with sections and bold headings. Front-loaded with purpose. Slightly long but every part adds value. Efficient considering 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 high complexity (events vs markets, multiple parameters) and presence of output schema, the description covers usage, query tips, output details, and edge case behavior completely.

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

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

Schema has 1 parameter (request) with detailed inner descriptions. The description adds context on how queryVariant relates to query and when to use includeEventMarkets, 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 searches for prediction markets by name, topic, URL, or slug, distinguishes between events and markets, and provides examples. It sets the scope precisely.

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: 'First tool when user asks about a specific PM topic...', 'Do NOT use general_search', and recommends prediction_market_ohlcv for price history. Also advises on queryVariant and includeEventMarkets 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 full burden. It discloses that results are for one exact marketId and warns against mixing markets. It also instructs to say so directly if no candles are returned. It does not mention read-only nature, but it's implied by historical data. The description is transparent about constraints and expected 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 with clear sections (When to use, Key fields, Pitfalls, Prerequisites). It is concise—only three sentences for the core purpose plus bullet points. Every sentence adds value without redundancy.

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

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

Given the tool has an output schema, the description does not need to detail return values. It covers prerequisites, pitfalls, and usage context. The key fields section explains the main output fields (Close, binary market complementarity). It is complete for the tool's complexity.

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

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

The description does not add much to the parameter schema beyond the caution about not mixing marketId. The schema itself has detailed descriptions for all parameters, so the baseline is 3. The description adds a behavioral constraint (do not mix dates/prices across different markets) but no semantic enrichment of 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 clearly states the tool's purpose: 'Historical odds/volume candles for a Polymarket market.' It includes a 'When to use' section and distinguishes from siblings by specifying it returns price history. The verb 'Loading' in the title aligns with 'historical' in the description.

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' and provides prerequisites (use prediction_market_lookup if marketId unknown). It also advises on handling empty results. However, it lacks explicit exclusions or alternatives, such as when to use prediction_market_trades 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?

Given no annotations, the description discloses key behavioral traits: order size is share quantity, not USD; explains Yes/No price complementarity; warns about misinterpreting no-side prices as bearish odds. This covers what the tool does and how to interpret results, which is beyond basic transparency.

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

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

The description is well-structured with headings (When to use, Key fields, Yes/No relationship, Pitfalls, Prerequisites). Each section adds value and the total length is appropriate for the complexity. Information is front-loaded with the 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?

Despite the complexity of interpreting an orderbook, the description provides sufficient context: how to use, key field interpretations, pricing relationships, pitfalls, and prerequisites. With an output schema available, the return values are covered. No major 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?

Parameter schema descriptions for marketId and page are present but the tool description does not add significant meaning beyond them. Schema coverage is 0% per context, but the description indirectly mentions marketId in prerequisites. The request parameter's anyOf structure is not clarified, and the description does not elaborate on parameter usage beyond context.

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

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

The description clearly states 'Live orderbook for a Polymarket market', specifying the exact resource and action. It differentiates from sibling tools like prediction_market_trades and prediction_market_ohlcv by focusing on bid/ask depth and order 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?

Includes explicit 'When to use' section listing bid/ask depth, liquidity, and order structure. 'Pitfalls' section advises against misinterpreting no-share prices and directs users to prediction_market_ohlcv for current odds. 'Prerequisites' instructs to call prediction_market_lookup if marketId is unknown, covering when-not-to-use and 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, the description covers key behavioral aspects: the 'Side Held' field behavior and handling of blank PnL fields. It does not disclose authentication or error behavior, but the output schema reduces need for return value 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?

The description is concise and well-structured with bullet points for 'When to use,' 'Key fields,' 'Pitfalls,' and 'Prerequisites.' Every sentence adds value without redundancy.

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

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

Given the output schema exists and annotations are absent, the description covers prerequisites, pitfalls, and primary use case. However, it does not explain the free-form request variant in the input schema, which is a minor gap.

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

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

Despite 0% schema description coverage on the top-level parameter, the description adds no meaning to the 'request' parameter beyond what is in the schema. It mentions output fields but does not explain the parameter structure or the free-form alternative in the union type.

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

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

The description clearly states 'PnL leaderboard for a Polymarket market' and specifies 'Only for profitability claims,' distinguishing it from related tools like top holders. It explicitly warns against substituting top holders for PnL, clarifying its unique purpose.

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

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

Provides explicit 'When to use' and 'Prerequisites' sections, including the alternative tool 'prediction_market_lookup' for obtaining marketId. Pitfalls warn against misinterpreting blank PnL fields, offering concrete guidance on correct 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 must convey behavioral traits. It explains key fields (Position Size, Value, Cost Basis, Unrealized PnL) and notes that Cost Basis and Unrealized PnL apply only to the displayed row. However, it does not disclose read-only nature, authentication needs, or error handling for invalid marketId.

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

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

The description is concise, using bullet points for key fields. It front-loads the main purpose and provides necessary detail without verbosity. No redundant sentences.

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

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

The description explains output fields and provides a prerequisite. However, it omits pagination context (page parameter) and does not clarify that the tool returns the current user's position (implying authentication). With an output schema, some return details are covered, but context lacks completeness.

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

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

Schema description coverage is 0%, meaning the main description does not detail parameters. The description only indirectly mentions marketId via the prerequisite. The page parameter is not discussed. The schema itself provides parameter descriptions, but the tool description fails to add value beyond that.

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

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

The description clearly states it provides a 'Detailed position breakdown for a Polymarket market,' specifying verb (position breakdown) and resource (Polymarket market). The title 'Loading prediction market position' also aligns. It distinguishes from siblings like prediction_market_address_summary by focusing on a single market's detail.

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

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

The description provides a prerequisite: if marketId is unknown, call prediction_market_lookup first. This guides the agent on obtaining required input. However, it does not explicitly state when not to use this tool or compare to alternatives like prediction_market_address_pnl.

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 discloses query behavior (literal-style matching, not fuzzy), output rules (superlatives must match shown metric, no inference from titles), and instructions for empty results. Lacks explicit statement of read-only nature, but overall sufficiently transparent.

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

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

Well-structured with sections ('When to use', 'Query tips', 'Output rules'). Content is substantial and necessary, though slightly verbose. Each section earns its place; could be more concise without losing value.

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

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

Covers tool usage comprehensively: when to use, how to query, how to interpret output, and edge case handling (empty results). With an existing output schema and good sibling differentiation, this description is complete for a screener tool.

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

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

Schema description coverage is 0% at the top level, but sub-parameters in the schema have descriptions. The description adds practical query tips (e.g., prefer short topic, avoid bundling unrelated topics) that enrich the parameter semantics and guide effective use 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?

Clearly states the tool browses and sorts Polymarket markets, events, or categories, and explicitly distinguishes itself from the sibling tool prediction_market_lookup by specifying when not to use it (for resolving a single 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?

Dedicated 'When to use' section with explicit instructions: use for broad discovery and ranked browsing; do not use for singular resolution. Also provides query tips and output rules, giving clear guidance on when and how to employ this tool versus alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: positions are share balances, position value is current marked value, output summary is based only on shown rows, and warns against misinterpreting smart money. This adds significant transparency.

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

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

The description is well-structured with sections: 'Key fields', 'Pitfalls', and 'Prerequisites'. It is concise (about 10 lines) and front-loads the main purpose. Every sentence adds value.

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

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

The description covers key fields, pitfalls, and prerequisites. Given that the tool has an output schema (not shown), the description does not need to explain return values. It is sufficiently complete for a data retrieval tool, though it could mention pagination behavior more explicitly.

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 descriptions for nested parameters (e.g., marketId, page, orderBy), but context signals indicate 0% schema description coverage (possibly counting only top-level). The description does not explain the parameters beyond mentioning marketId as a prerequisite. For a tool with schema coverage effectively 0%, the description should compensate, but it does not add meaning to the 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 clearly states 'Largest current holders for a Polymarket market,' which specifies the verb (find largest holders), resource (Polymarket market), and distinguishes it from sibling tools like prediction_market_address_summary 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?

Includes explicit prerequisite: 'If marketId is unknown, call prediction_market_lookup first.' Also provides pitfalls about not inferring risk or smart money. However, it does not explicitly compare with alternative tools or state when not to use this tool.

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

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

With no annotations, the description fully covers behavioral traits: it is a read operation, explains key output fields (Share Size, Value USD), clarifies that each row is one trade leg, and warns about misinterpretation. No contradictions with annotations since none exist.

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 headings (When to use, Key fields, Pitfalls, Prerequisites). Every sentence adds value without redundancy. It is appropriately front-loaded with the main purpose.

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

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

Given the existence of an output schema (not shown), the description adequately covers the tool's purpose, usage, and pitfalls. It lacks explicit detail on pagination (page parameter) and default date range behavior, but overall it is sufficiently complete for a trade-listing tool.

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

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

Schema description coverage is 0%, meaning the parameter descriptions in the schema are not counted. The description only hints at marketId through prerequisites but does not explain page, dateRange, or the generic request object. It adds value for output fields but not for input parameters, leaving the agent with incomplete understanding.

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

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

The description clearly states 'Recent trades for a Polymarket market,' specifying the verb (checking recent trades) and resource (Polymarket market). It distinguishes from siblings like prediction_market_ohlcv and prediction_market_orderbook through explicit usage guidance.

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

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

The 'When to use' section provides explicit guidance: 'Source of truth for recent fills and latest trade-tape pricing. Do not overwrite recent trade prices with older OHLCV candles.' It also gives a prerequisite: if marketId is unknown, call prediction_market_lookup first. Pitfalls warn against misinterpreting large trades.

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. Clearly states data source (Hyperliquid perp), limitation to recent trades, lists returned columns, and sorting options. Could mention auth requirements but overall transparent.

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

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

Well-structured with header, columns list, sorting info, and examples. Slightly long but each section adds value. Front-loaded with purpose.

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

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

Covers data scope, limitations, columns, sorting, and examples. Pagination not explained in description but present in schema. Adequate for a data-fetching tool.

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

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

Schema description coverage is 0% (per context), so description compensates fully by explaining columns, sorting fields, and providing multiple examples that demonstrate parameter usage.

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

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

The description clearly states the tool retrieves recent Hyperliquid perpetual futures trades from Smart Traders and Funds across all tokens. It distinguishes itself from the sibling tool token_discovery_screener for 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?

Explicitly mentions when to use this tool vs. token_discovery_screener, notes Hyperliquid-only limitation and no date filtering. Provides examples but does not explicitly say when not to use.

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

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

Without annotations, the description carries the burden. It discloses aggregation, exclusions, and default chain behavior, but lacks details on performance, rate limits, or error scenarios.

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

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

Two sentences, front-loaded with key purpose, no fluff. Concise and well-structured.

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

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

Covers main functionality and output type, but misses mention of pagination, default page, or sorting options. Output schema exists, so return format detail is optional, but pagination context would help.

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 only says 'Use filters to narrow down the results' – adds no specific parameter meaning. Despite schema having detailed parameter descriptions, the context indicates 0% coverage, so the description fails to compensate.

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

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

The description clearly states it gets aggregated token balances and 24h change for smart traders and funds, excluding whales and influencers. It specifies the resource and action, distinguishing it from perp trades sibling.

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 context (aggregated, not per wallet, excludes whales) but does not explicitly guide when to use this tool versus alternatives like per-wallet tools or other smart money 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?

Thoroughly discloses behavior: pagination (25 per page), mode-dependent results, column schemas, sorting options, restrictions for native tokens and specific orderBy values, and explicit failure case for SOL. Annotations absent, so description carries full burden and does so excellently.

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

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

Structured with headings, bullet points, and examples. While lengthy, every section serves a purpose (columns, sorting, restrictions, examples). Could be slightly trimmed, but overall efficient for the 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 (two modes, multiple filters, restrictions), the description covers all necessary details: return columns, sorting options, constraints, and comprehensive examples. With an output schema present, this is complete.

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

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

Schema description coverage is 0%, meaning the description must compensate. It adds value through examples and mode-specific parameter usage, but does not systematically explain each parameter beyond what the schema provides. Still, the examples and notes significantly aid understanding.

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

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

The description clearly states it retrieves top holders for a token, with two distinct modes (onchain_tokens, perps) and detailed column lists. It effectively distinguishes the tool from sibling tools by focusing on holder 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?

Provides guidance on when to use smart_money label, mode selection, and includes examples. However, it lacks explicit comparison to sibling tools or clear 'when not to use' scenarios beyond the smart_money note.

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

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

With no annotations, the description carries the burden of behavioral context. It explains modes and a token limitation, but omits important details such as default pagination, sorting behavior, output format (though output schema exists), rate limits, and error handling. The description provides basic functional clarity but lacks depth about runtime 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 (two paragraphs) and well-structured with clear mode definitions and a note. Every sentence adds value, though the note about native tokens could be integrated more seamlessly.

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 optional filtering parameters) and the availability of an output schema, the description covers modes and a caveat but does not guide the agent on common usage patterns (e.g., how to filter by action/side, pagination limits). It is adequate but not comprehensive for a data-intensive tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the two modes and the native token note, but does not elaborate on other parameters like page, side, chain, action, or dateRange. While the schema defines them, the description could provide more usage context for complex parameters like valueUsd or dateRange.

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

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

The description clearly states 'Get DEX trades for a specific token' and explains two distinct modes (onchain_tokens and perps), which precisely defines the tool's scope and distinguishes it from sibling tools like address_dex_trades (which focuses on an address) and token_info (which provides general token info).

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: 'onchain_tokens' for analyzing on-chain tokens by contract address, 'perps' for Hyperliquid perpetual futures by symbol. It also includes a crucial caveat about native tokens (only ETH supported in onchain mode, others should use perps), which prevents misuse.

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

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

With no annotations provided, the description carries full burden and discloses all key behaviors: maximum results, chain limit, perps special case returning two sections, timeout risks, default sorting (netflow desc), and that 'priceChange' is not a filter. It also explains what happens with unsupported filters/orderBy (fallback to defaults).

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, examples, warnings, and bullet points. It front-loads the purpose and key constraints. However, it is quite long (several paragraphs) which could be trimmed for brevity without losing essential information. Every sentence earns its place, but overall length slightly impacts quick scanning.

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 for Hyperliquid, multiple filtering/sorting options), the description is complete. It covers return columns (though output schema exists), edge cases like mixed chains, timeout recommendations, and how to avoid spam tokens. It leaves no significant gaps for an agent to guess.

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 schema: it clarifies that priceChange cannot be used as a filter, explains the relationship between traderType and includeSmartMoneyLabels, notes that tokenAgeDays is for filtering only (not sorting), and provides real-world usage patterns through examples. Schema descriptions exist but the tool description provides critical operational context.

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

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

The description clearly states the tool provides 'comprehensive token screening data across multiple blockchain networks with advanced filtering' for 'token discovery and finding trending tokens'. It distinguishes from siblings like token_info (which is for single token details) and token_flows (which focuses on flows) by emphasizing multi-token, multi-chain screening.

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

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

The description provides extensive when-to-use and when-not-to-use guidance: maximum 25 results, max 5 chains (excess trimmed), timeout warnings (recommends ≤4 chains, shorter timeframes), specific Hyperliquid perp behavior, and explicit warnings like 'priceChange is NOT a valid filter'. It also advises on traderType usage (use only when explicitly asked). Examples illustrate correct 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 provided, so description carries full burden. It discloses modes, limitations on native tokens, and default segment. Could mention response format (hourly aggregated data) but overall transparent about 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?

Well-structured with main purpose first, then notes, then comparison, then modes, then native token note. Slightly verbose but each sentence adds value. Could be more concise but not excessive.

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 (modes, segments, date ranges, chains) and presence of output schema, description covers all necessary aspects: usage guidelines, limitations, segment recommendations, and mode details. Complete for an AI agent to invoke correctly.

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

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

Schema has 100% coverage, but description adds substantial meaning: explains holder_segment options, modes, and provides important usage notes like 'smart_money is not a good proxy' and native token support. Adds value beyond schema.

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

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

Description clearly states the tool gets hourly aggregated token flows for a specific holder segment over a date range. It distinguishes from sibling token_recent_flows_summary by noting it is more granular. The verb 'get' and resource 'hourly aggregated token flows' are specific.

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

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

Explicit guidance on when to use smart_money segment (only if user requests or combined), and that native tokens are not supported in onchain_tokens mode but are in perps mode. Also compares to token_recent_flows_summary to indicate granularity.

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 bears the full burden. It discloses the dual-mode behavior, the difference in tokenAddress usage (contract vs. symbol), and the default mode. It does not mention side effects, rate limits, or destructive actions, which are not expected for a read-only tool. The disclosure is thorough.

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-organized with sections for modes, returns, examples, and notes. It is front-loaded with a clear summary. However, the returns section is lengthy and repeats field details that may be covered by the output schema, making it slightly verbose.

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

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

Given the complexity of two modes and the presence of an output schema, the description covers the essential aspects: mode selection, parameter differences, and return fields. It lacks guidance on when to choose this tool over similar siblings, but overall it provides sufficient context for the agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'mode' parameter fully, the difference between contract address and symbol for tokenAddress, and provides examples with each parameter shown in context. The description adds meaning beyond the schema, especially for the nested request structure.

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

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

The description clearly states 'Get token information — spot on-chain details or Hyperliquid perpetual futures stats', providing a specific verb and resource. The two modes are explicitly defined, distinguishing the tool from siblings that focus on specific aspects like trades, OHLCV, or 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 implies usage via two modes but does not explicitly state when to use this tool versus other token-related siblings (e.g., token_dex_trades, token_ohlcv). There is no guidance on use cases or exclusions, so the agent lacks clarity on when this tool is the best choice.

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

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

No annotations provided, so the description carries full burden. It discloses automatic resolution calculation based on date range, column descriptions, and special handling for Hyperliquid perps. It does not explicitly state read-only nature, but the context (OHLCV data) implies it. Good behavioral coverage, though a statement like 'This is a read-only operation' would improve clarity.

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 (introduction, bulleted resolution rules, table of columns, multiple examples). It is front-loaded with the core purpose. Every sentence adds value, and the examples are varied and instructive. Concise for the amount of information conveyed.

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 chains, auto-resolution, optional parameter), the description is complete. It covers supported chains, date range formats, resolution logic, column output (including optional market cap columns), and special cases for Hyperliquid. With an output schema present, the description need not explain return values beyond what it provides.

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

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

Schema coverage is 0%, but the description compensates comprehensively. It explains each parameter: chain, tokenAddress, date (with from/to format and examples), and includeMarketCap (booleans and defaults). Resolution logic is detailed. Examples demonstrate exact usage patterns, making parameter semantics crystal clear.

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

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

The description clearly states it retrieves OHLCV price data for tokens with automatic interval resolution. It explicitly distinguishes itself from general_search, advising agents to use this tool for prices instead. The verb 'Get' and resource 'OHLCV price data' are specific, and the scope (EVM chains, Solana, Hyperliquid perps) is well-defined.

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 instructs to use this tool over general_search for prices, citing that general_search prices are delayed and often incorrect. It provides detailed examples for various scenarios (WETH, BTC perp, latest price). It indirectly advises when to use (for OHLCV data) and when not (for general search). No explicit exclusions but highly practical.

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

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

With no annotations provided, the description carries full burden. It discloses the tool only returns top 25 results, explains sorting and filtering limitations, and mentions unsupported chain. However, it lacks details on side effects, rate limits, or query response time, and does not fully compensate for the absence of annotations.

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

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

The description is comprehensive but verbose, with multiple sections (Modes, NOTE, Returns, Sorting, Filtering, Examples, Notes). It is well-structured with headings and bullets, but could be more concise by removing repetitive elements like the full column list which could be inferred from output schema.

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

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

Given the tool's complexity (two modes, numerous filters, sorting options, and examples), the description is thorough. It covers modes, limitations, return format, and practical use cases. Output schema exists, so detailed column listing is acceptable. Minor gaps include not specifying pagination behavior beyond the 25-result limit.

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 high (all parameters have descriptions in the nested request object), so baseline is 3. The description adds value by providing examples of valid parameter combinations and listing columns returned, but this information is partially redundant with schema descriptions.

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

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

The description clearly states the tool retrieves 'Up to 25 results (per page) of trader PnL for a token', specifies two modes (onchain_tokens and perps) with distinct use cases, and distinguishes from siblings like hyperliquid_leaderboard by focusing on token-specific PnL leaderboards.

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 (onchain_tokens for contract addresses, perps for Hyperliquid perpetuals), notes unsupported scenarios (native tokens in onchain_tokens mode, hyperevm chain), and includes examples. However, it does not explicitly state when not to use or suggest alternatives among siblings.

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 reveals that results include percentile comparisons within market cap groups and that not all indicators are available. However, it does not disclose rate limits, authentication needs, or potential side effects (though likely read-only). Adequate but not thorough.

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

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

Well-structured with sections for usage, return fields, indicator types, and notes. Front-loaded with purpose. Slightly verbose but every section adds value; no wasted sentences.

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

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

Given the complexity (anyOf input, output schema exists, no annotations), the description adequately covers return values but fails to clarify the input request format or the vague additionalProperties option. It is sufficient for simple cases but incomplete for complex ones.

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%, yet the description explains output fields and indicator types in detail. However, it provides no additional explanation of the 'request' parameter structure beyond what the schema shows, missing an opportunity to clarify the anyOf and the required tokenAddress/optional chain.

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

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

The description clearly states the tool retrieves 'Nansen Score Indicators for a token - quantitative risk and reward signals.' The verb 'Get' and resource are specific, and it distinguishes itself from sibling tools that handle direct trades, wallets, or general searches by focusing on risk/reward scoring.

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

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

Explicitly advises when to use: 'assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data.' Provides positive guidance but lacks explicit 'when not to use' or comparison to alternatives among siblings.

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, but description details what is returned (flow amount, ratio, number of wallets), explains positive/negative flow meanings, and notes aggregation over lookback period. Could be more explicit about read-only nature, but sufficient.

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

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

Description is relatively long but well-structured with headings, bullet points, and bold. Every sentence adds value, though could be slightly 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?

Covers all key aspects: purpose, segments, output format, modes, guardrails (no Bitcoin), and differentiation from sibling tool. With output schema present, the description is 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?

Input schema has one complex parameter `request` with schema description coverage 0% at top level, but inner properties have descriptions. The tool description adds context about segments and usage but does not explain parameter structure. Adequate but not enhanced.

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

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

The description clearly states it gets TOTAL token flows per segment, enumerates the 6 segments, and distinguishes from sibling tool token_flows for specific date ranges. It also notes Bitcoin not supported.

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

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

Explicitly tells when to use token_flows instead (specific date ranges, more granular data). Also specifies that Bitcoin is not supported and describes two modes (onchain_tokens and perps).

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

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

The description explicitly states pagination (25 per page), default sort order, unsupported tokens, available filters, and columns returned. While it does not explicitly state the tool is read-only, the behavior is clear and no contradictions exist. With no annotations, the description provides substantial transparency.

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

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

The description is well-structured with clear sections, headings, code blocks, and bullet points. It is longer than necessary but front-loaded with key information. Some redundancy exists between the examples and filter list, but overall it remains efficient.

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

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

The description covers all aspects: purpose, pagination, unsupported tokens, all filters with explanations, sorting options, and multiple examples. It also details the output columns. Given the tool's complexity, the description is 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 description compensates for the 0% schema coverage by providing a comprehensive breakdown of all parameters, including address filters, transfer origin categories, smart money filter, numeric range filter, and sorting. Multiple examples demonstrate usage, making parameter semantics very clear.

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

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

The description clearly states the tool retrieves 25 token transfers per page for a specific token with sorting, and explicitly mentions it does not support native tokens. It distinguishes from sibling tools by focusing on transfers rather than trades or flows.

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

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

The description provides detailed usage instructions and examples for various filter scenarios, but it does not explicitly differentiate when to use this tool over sibling tools like token_dex_trades or token_flows. Usage is implied but no alternatives or exclusions are mentioned.

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

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

No annotations provided, so the description bears full responsibility. It discloses that the tool returns aggregated buyer/seller activity as markdown, returns empty string if no data, and lists all return columns. It also notes sorting options and parameter effects. Missing details on rate limits or authentication, but adequate for a read 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 sections (purpose, usage, returns columns, sorting, notes). It is front-loaded with the main purpose. While somewhat verbose, each section adds value and is clearly organized.

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

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

Given the tool's complexity (nested parameters, many siblings) and lack of annotations, the description is fairly complete. It explains return format, columns, sorting, and parameter behavior. Minor omissions: no mention of pagination ('page' parameter exists) or explicit time range limitations, but overall adequate.

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 by explaining the meaning of key parameters (e.g., buy_or_sell filters for net buyers/sellers). It also describes sorting options and the returned columns, which adds semantic context beyond the schema's field descriptions.

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

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

The description clearly states the tool's function: 'Get TOTAL amount of tokens bought/sold by address for a token on DEX ONLY.' It specifies the resource (token and address) and verb (get aggregated amounts). While it doesn't explicitly differentiate from sibling tools like token_dex_trades, the focus on aggregated buyer/seller activity is distinct.

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

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

The description explains when to use: '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 buy_or_sell parameter for filtering net buyers/sellers. It doesn't explicitly state when not to use, but the context is evident.

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 only mentions that the tool returns 'comprehensive transaction details including token transfers,' but does not specify what exact fields are returned, whether the tool is read-only, any rate limits, or error conditions (e.g., invalid transaction hash). Behavioral transparency is minimal.

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, concise sentence that front-loads the core purpose. It avoids unnecessary words. However, it could be slightly more structured by separating purpose from the parameter hint, but overall it is efficient and to the point.

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

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

Given the tool has only two parameters (one required) and an output schema is present, the description could be more complete. It lacks any explanation of the chain parameter's valid values, the meaning of 'comprehensive details', or how the output relates to inputs. The presence of an output schema reduces the need to explain return values, but the parameter gap leaves the tool under-described.

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, yet the description does not explain either parameter (chain and transaction_hash). It fails to mention that transaction_hash is required and that chain defaults to 'all'. The description adds no semantic value beyond the schema, leaving the agent uninformed about parameter formatting, options, or constraints.

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

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

The description 'Get comprehensive transaction details including token transfers' clearly states the tool's purpose: retrieving transaction details with a specific emphasis on token transfers. It is specific enough to distinguish from sibling tools like address_transactions (which list transactions for an address) and token_transfers (which focus on token-level transfers), but the term 'comprehensive' is somewhat vague.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when to choose transaction_lookup over other tools such as address_transactions or token_transfers. The phrase 'including token transfers' hints at a use case but is insufficient for clear decision-making.

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

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

The description does not disclose behavioral traits like data freshness, authentication requirements, or what happens if no trades are found. Since no annotations are provided, the description carries the full burden, but it adds minimal behavioral context beyond the basic purpose.

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 two sentences, direct and free of unnecessary words. It frontloads the purpose and usage, making it easy for an AI agent to quickly parse.

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

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

Given the tool's complexity (nested request parameter) and the presence of an output schema, the description is adequate but lacks mention of edge cases, prerequisites (e.g., wallet must have traded the token), or the meaning of showRealized. It covers the core use case but leaves some 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?

The tool description does not detail the parameters (schema description coverage is 0%), but the input schema itself provides comprehensive descriptions for properties like tokenAddress, dateRange, and showRealized. The description adds some meaning by mentioning 'specific token' and 'date range,' but it could go further in explaining the role of showRealized or chain.

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

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

The description clearly states 'Get PnL stats for a specific token traded by the input address during a specific date range.' It uses a specific verb and resource, and the qualifiers (specific token, input address, date range) distinguish it from sibling tools like wallet_pnl_summary and token_pnl_leaderboard.

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

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

The description says 'Use this tool for analysing the performance of the wallet for the specific token over a time period,' which provides clear context. However, it does not explicitly mention when not to use it or suggest alternatives, though the context of sibling tools is implied.

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

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

No annotations provided, so the description carries the burden. It discloses the tool only returns realized PnL (not unrealized), which is a key behavioral trait. However, it does not mention if there are any side effects, rate limits, or authentication requirements, nor does it detail the response format (though output schema exists).

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

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

The description is four sentences that are mostly direct and clear. It front-loads the purpose. However, there is minor repetition ('over a time period' appears twice), and the structure could be slightly tighter.

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

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

Given the complex input schema (anyOf with nested objects) and no annotations, the description should explain the parameter structure. It fails to do so, leaving the agent uncertain how to invoke the tool correctly. The output schema exists but does not mitigate this need.

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

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

The input schema has a complex 'request' parameter with anyOf, but the description provides no guidance on how to structure the parameter. With 0% schema coverage in the description, the agent would not know that 'walletAddress' and 'dateRange' are expected. This is a critical gap.

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

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

The description clearly states the tool gets aggregate stats of overall realized PnL for a wallet address. It distinguishes from siblings like 'wallet_pnl_for_token' by focusing on overall stats, and from prediction market tools by being address-specific.

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 (analyzing wallet performance over a time period) and when not (excludes unrealized PnL, advises checking token price changes). It does not explicitly mention alternative sibling tools like 'wallet_pnl_for_token', but the guidance is clear enough.

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