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

The description adds behavioral details beyond the annotations (readOnlyHint=true, destructiveHint=false). It discloses the default page size (25), default sort (net value transferred), the return of top 3 tokens per counterparty, and the timeRange clamping behavior (max 365 days, clamped to recent year with effective range reported in response). These specifics are not present in the annotations and provide useful transparency about the tool's 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 lengthy but well-structured with clear sections: core purpose, a 'Note' for related-wallet strategies, sorting options, and two examples. The most critical information (what it does) is front-loaded. While some parts (e.g., the related-wallet note) could be considered extra, they are directly useful for agents seeking to maximize tool effectiveness. The structure makes it easy to scan, and no content is redundant or wasted.

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 essential aspects for correct invocation: page size, default sort, sortable fields, timeRange tokens and clamping behavior, the distinction between address and entity queries, and the return of top tokens. It also includes examples that demonstrate valid parameter combinations. Given that an output schema exists (which documents return structure) and annotations cover safety, nothing critical is missing for an agent to use this tool effectively.

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

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

The schema already has 100% description coverage, but the tool description adds valuable context: it explains the sorting fields and their semantics, provides relative time token examples (7D_AGO, 30D_AGO, etc.), clarifies the mutual exclusivity of address and entity_id, and includes two complete JSON examples demonstrating realistic parameter usage. This goes beyond the schema's individual parameter descriptions, enriching the agent's understanding of how to construct effective requests.

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 25 (per page) addresses or entities with the most common interactions with input addresses'. It specifies the resource (addresses/entities), the action (get), the scope (most common interactions), and adds details about default sorting and token returns. This clearly distinguishes it from sibling tools like address_related_addresses, which focuses on related addresses rather than counterparty interaction ranking.

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

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

The description includes a dedicated 'Note: To get related wallets' section that provides practical guidance on how to use this tool for finding related wallets (focusing on direct transfers, including CEX deposit addresses, and going one level deeper). It does not explicitly mention alternative tools or when not to use this tool, but the contextual guidance is clear and actionable. The examples also illustrate two distinct query patterns (address vs entity), which clarifies usage scenarios.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context beyond that: each wallet gets its own list (not summed), duplicate addresses are removed, sorting applies inside each wallet's block, and with 'all' chains, a counterparty appears per chain so rows should not be added together. It also warns that a wider date range is rejected, preparing the agent for error handling. No contradiction with annotations.

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

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

The description is long but well-structured: it front-loads the purpose, then breaks down usage, limits, chain behavior, sorting, and ends with a complete example. Each sentence earns its place; there is no filler. It could be slightly tightened (e.g., repeating the 'not added together' point), but the organization is clear and aids comprehension.

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

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

Given the tool's complexity (nested filters, multiple limits, sorting options, pagination), the description covers all critical aspects: the exact call shape via example, limits with error behavior, chain family rules, sorting semantics, and the distinction from the single-wallet sibling. An output schema exists, so return-value details are not required. Nothing an agent needs to invoke it correctly is missing.

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% (the input schema contains extensive descriptions for every parameter). However, the description adds meaning beyond the schema: it provides a concrete example JSON, clarifies that walletAddresses are deduplicated, explains the perPage must cover all wallets (rows stay together), and emphasizes the chain family restriction. These extras go beyond what the schema states, so it earns a 4 rather than the baseline 3.

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

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

The description states a specific verb ('Get') and resource ('top counterparties of up to 10 wallet addresses'), and immediately distinguishes it from the sibling tool address_counterparties by clarifying that this is for comparing multiple wallets, not single wallets or entity names. This makes the tool's purpose unmistakable.

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?

It explicitly tells the agent when to use this tool (comparing wallets, shared counterparties, CEX deposit addresses, fund with many wallets) and when not to (single wallet or entity name → use address_counterparties). It also provides concrete limits (max 10 addresses, 90-day range, single chain family) and explains consequences of exceeding them, leaving no ambiguity about invocation conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds rich behavioral context beyond that: output columns for spot and perp, default sort (newest first), available filters, and special rules for token fields on Hyperliquid. It also discloses that 'all'/'evm' are unsupported and that EVM wallets must specify a chain, which are critical behavioral constraints not evident from annotations alone.

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

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

The description is long but exceptionally well-structured: it opens with the core purpose, then systematically covers chain constraints, output columns, sorting/filtering, and special cases, and ends with an example. Every sentence contributes necessary information without redundancy, and key constraints are front-loaded.

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

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

The description is comprehensive enough for an agent to call the tool correctly: it covers chain handling, parameter details, output columns, filters, and provides a full example. Since an output schema exists, the description need not detail return values, but it still lists the columns, which is helpful. There are no missing operational requirements for a typical use case.

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

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

Despite the schema having descriptions for many nested properties, the overall schema coverage signal is 0% for the top-level parameter. The description compensates by explaining each parameter's behavior in detail: chain selection, sort fields, value filters, date ranges, and token filter semantics on spot vs Hyperliquid. It also includes a concrete example that clarifies the expected request structure, adding significant meaning beyond the schema.

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

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

The description clearly states the tool retrieves a wallet's individual DEX trades on a single chain, distinguishing spot swaps from Hyperliquid perpetual trades. It explicitly positions itself as the wallet-centric counterpart to token_dex_trades, making its purpose unambiguous and differentiated 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?

Provides explicit when-to-use guidance: for wallet-centric trade queries vs token-centric alternatives, and specifies chain requirements (EVM must pass chain, non-EVM auto-detected, hyperliquid for perps). It also notes that only one chain is queried per call and advises calling once per chain, giving clear operational 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?

Annotations already cover the read-only, non-destructive, open-world nature. The description adds behavioral context beyond that by explaining the result is resolved across all chains and that no chain argument is required. This is meaningful and consistent with the 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?

Three sentences, all substantive: the core behavior, the intended use case, and the cross-chain parameter clarification. There is no filler, and the most important information is front-loaded.

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

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

For a single-parameter, read-only lookup with an output schema and safety annotations, the description is complete. It covers what the tool returns, why to use it, and the key behavioral nuance about chain resolution. Nothing essential is missing for an agent to invoke it 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 for parameter meaning. It does clarify that the lookup target is an EVM wallet and explicitly says no chain argument is needed, which adds value. However, it does not explain the request wrapper structure or address format, leaving the generic 'request' parameter and its anyOf schema somewhat ambiguous.

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

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

The description opens with a specific verb and resource: 'Get the first address that ever funded an EVM wallet,' and also names the returned fields (transaction hash, chain, timestamp). This clearly distinguishes it from sibling address_* tools, especially with the explicit note that no chain argument is needed because resolution is cross-chain.

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?

It gives a concrete use case: attribute an unlabelled wallet to a known entity, since the first funder is often a CEX withdrawal or another wallet the same owner controls. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to guide selection among the many 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation, and openWorldHint further signals results may shift over time. The description adds the native-coin-and-token scope and historical temporality but discloses nothing about pagination, return format, or chain behavior beyond that scope.

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

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

A single nine-word sentence with zero filler that front-loads the action and the resource. 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?

Given the rich input schema, read-safety annotations, and an output schema, the description is sufficient for invoking the tool correctly. The main gap is explicit routing guidance against smart_traders_and_funds_historical_token_balances, but the 'address' qualifier in both name and description mitigates that ambiguity.

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

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

Schema description coverage is 100%, with address, entity_id, lookbackDays, and suspiciousFilter all documented including defaults and mutual exclusivity. The description's mention of 'address' only weakly ties to the primary parameter and adds no meaning beyond what the schema already provides, so baseline 3 applies.

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

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

The description states a specific verb ('Get') and a specific resource ('historical native coin & token balances of address'), so the function is clear. However, it doesn't explicitly distinguish itself from near-siblings like address_portfolio or smart_traders_and_funds_historical_token_balances; differentiation is left to inference from the word 'historical' and the 'address' qualifier.

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 word 'historical' implies the tool is for point-in-time balance queries, providing implied usage context. But no when/when-not guidance, exclusions, or named alternatives appear in the description, so an agent must infer which sibling (e.g., address_portfolio for current holdings) to choose.

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

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

Annotations already declare the tool read-only and non-destructive. The description adds meaningful behavioral context by disclosing the exact label categories returned and the notable limitation that premium labels are not returned, which goes beyond the structured 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 two compact sentences with no filler. It front-loads the core action in the first sentence and adds the key exclusion in the second, making it easy for an agent to parse quickly.

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

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

Given the rich nested input schema, presence of an output schema, and safety annotations, the description is nearly complete. It clearly defines the tool's scope and key exclusion, though it could briefly mention an alternative for premium labels or define 'standard labels' more precisely.

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

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

Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds little parameter-level meaning beyond confirming the tool targets a single wallet address, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get the standard labels for one wallet address.' It further specifies the label categories returned (identity, behavioural, protocol) and explicitly excludes premium labels, which distinguishes it from other address-related tools.

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

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

The description conveys when to use the tool—when standard labels for a wallet are needed—and clarifies that premium labels are not included. However, it does not name an alternative tool or provide explicit when-not-to-use guidance, leaving some routing to inference from the sibling list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the 'without a portfolio lookup' scoping detail, which clarifies behavior. However, it doesn't disclose what the output contains beyond positions and liquidation risk, nor any rate limits or data freshness. With annotations covering the main behavioral traits, a 3 is appropriate.

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?

One sentence with zero waste. The core action and the key differentiator ('without a portfolio lookup') are front-loaded. 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?

The tool has a rich output schema and 100% parameter schema coverage, so the description doesn't need to explain return values or parameters. The only minor gap is that it doesn't mention the optional filters/sorting capabilities, but those are fully documented in the schema. For a read-only lookup tool with strong structured metadata, this is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents the address and all filter/orderBy fields thoroughly. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 states a specific verb ('Get'), a specific resource ('a wallet's Hyperliquid positions and liquidation risk'), and a distinguishing constraint ('without a portfolio lookup'). This clearly differentiates it from sibling tools like address_portfolio and address_historical_balances. The title reinforces the purpose.

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

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

The description implies when to use this tool: when you need positions and liquidation risk specifically, and explicitly excludes the portfolio lookup path. However, it doesn't name sibling alternatives or state when NOT to use it (e.g., use address_portfolio for full portfolio context). The 'without a portfolio lookup' phrase gives some exclusion guidance but not a full routing rule.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it states that Hyperliquid positions include liquidation prices, that entity queries return only on-chain balances, and that the output is pre-formatted markdown to be presented verbatim. These are operational traits an agent must know and are not in the annotations. This exceeds the baseline for annotation-covered tools.

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

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

The description is longer than average but each section earns its place: purpose, mode list, entity behavior, output-format instruction, and four examples. It is front-loaded with the purpose and uses bullet lists for readability. A small redundancy ('This tool provides flexible portfolio analysis...') could be trimmed, but overall it is well-structured and not bloated.

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

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

Given the tool's complexity (multiple modes, wallet vs entity, output format), the description covers all necessary details. It explains mode semantics, entity limitations, output formatting, and provides working examples. Since an output schema exists, return-value explanation is not required. No critical information is missing for an agent to call 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% for the top-level 'request' parameter, so the description must fully compensate. It does so admirably by defining each mode, providing concrete JSON examples for wallet (all, defi, hyperliquid) and entity queries, and clarifying the mutual exclusivity of walletAddress and entity_id. This is far more informative than the bare schema.

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

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

The description opens with a specific verb+resource: 'Get comprehensive portfolio overview for a wallet address or entity.' It clearly enumerates the modes and the entity behavior, making it easy to distinguish from focused siblings like address_perp_positions or address_historical_balances. The purpose is unambiguous and action-oriented.

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

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

The description explains the modes and when to use each, and explicitly notes that entities return only token balances. However, it does not explicitly state when to prefer a sibling tool (e.g., address_perp_positions for only perp positions) or provide exclusion criteria. The mode guidance is strong but lacks explicit alternatives, so a 4 is appropriate.

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

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

Annotations already cover readOnly and non-destructive behavior, so the description adds value by clarifying data scope (only special connection types) and the exchange funding nuance. This goes beyond structured fields, but it could still mention edge cases like unknown addresses or pagination behavior, which are not covered.

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

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

The description is front-loaded with the core purpose, then provides relevant scope details and a caveat. The second paragraph listing connection types is a bit verbose but each item is meaningful; the exchange nuance is valuable. No wasted sentences, though it could be slightly tighter.

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

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

Given the tool's complexity and the presence of an output schema, the description covers purpose, scope, and a key interpretation pitfall. It does not explain pagination or error handling, but those are likely in the output schema, and the annotations cover safety. Overall it gives enough context for a correct call.

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

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

Schema description coverage is 100%, so the input schema already documents the 'request' object and its fields ('address', 'chain'). The description adds no direct parameter semantics, so baseline 3 is appropriate. It does not harm selection but also does not compensate 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 states a specific action ('Get information about related addresses') with a clear resource and input. It explicitly enumerates which connection types are included, and names the sibling tool 'address counterparties' as a complement, distinguishing this tool from that one. An agent can tell exactly what this tool returns without opening the schema.

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 guides when to use this tool vs. alternatives: 'To get related wallets, also check address counterparties.' It also provides a crucial data-quality caveat about exchange withdrawal addresses, which helps an agent interpret results and decide when to trust the relationship. This is clear, actionable 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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral details like the 20-per-page limit and date-range ordering, though it does not describe edge cases or pagination behavior beyond this.

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 short sentences with no filler. The most important facts—recency, limit, and date-range behavior—are front-loaded.

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

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

The description, together with the annotations and output schema, covers the core behavior of the tool. Some parameter-level details are left to the schema, but existing structured info and output schema reduce the burden on the description.

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 for explaining parameters. It only generically references 'per page' and 'date range', leaving address, chain, page, dateRange formatting, and hideSpamToken mostly unexplained at the description level.

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 states a specific action ('Get list of 20 MOST RECENT transactions') and a clear resource ('made by an address'), with explicit pagination ('per page'). This distinguishes it from sibling tools like address_dex_trades and transaction_lookup at a high level.

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

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

The description gives clear context: this tool returns the most recent address transactions within a date range, paginated. It does not explicitly name alternatives or exclusions, but the use case is evident from the wording.

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

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

Annotations already mark this as read-only and non-destructive, and the description adds matching behavior beyond that: case-insensitive matching, matching anywhere in the name, and returning exact entity names. This gives the agent useful expectations without contradicting the 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?

Three sentences carry the purpose, use case, example, and routing rule with no filler. The main behavior is front-loaded before the alternative guidance.

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 is simple, has full schema coverage, annotations, and an output schema, so the description does not need to explain return formats. It covers purpose, usage timing, matching semantics, and alternatives, making it complete for an 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?

The input schema already documents both parameters with 100% coverage, so the baseline is a 3. The description adds value by explaining how search_query is interpreted (case-insensitive, partial, matches anywhere) beyond the schema's 'Partial entity name' phrasing.

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 a specific verb and resource: search Nansen entity names by partial name and return exact matching names. It also distinguishes itself from general_search, which is for tokens or addresses, so an agent can tell sibling tools apart.

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?

It gives an explicit when-to-use rule: when a downstream tool needs an exact entity name but the user provided an approximate one, with a concrete example. It also states the alternative for tokens/addresses, making the routing decision unambiguous.

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 annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it is the entry point, it does not support NFTs, it resolves labels and domains, and it reports price, volume, contract address, chain, market cap, and supply 'when available.' This gives the agent useful expectations without repeating annotation data.

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

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

The description is front-loaded with the most important guidance ('FIRST entry point' and the prediction-market exclusion) before a well-organized bullet list of capabilities. It is somewhat long, but each bullet communicates a distinct lookup capability and the NFT caveat earns its place. No redundant sentences dilute the message.

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, the 100% parameter schema coverage, and the read-only/open-world annotations, the description is nearly complete. It covers the main search categories, return-style information, exclusions, and label/domain resolution. A small gap is that the title mentions 'companies' while the description only implies them through 'entities' and the schema's stock mode, but this is minor given the schema already clarifies stock search.

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 fully documents all four parameters, so the baseline is 3. The description adds value by expanding the meaning of `query` beyond the schema: it can be a token name, symbol, contract address, Nansen label, or a domain such as .eth/.sol. It also clarifies that entity search is part of the tool's scope, complementing the schema's stock-mode note.

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

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

The description opens with 'General search tool' and explicitly frames it as the 'FIRST entry point to look up for possible tokens, entities, and addresses related to a query.' It then lists concrete use cases, including token existence checks, token details, entity lookup, Nansen-label resolution, and domain resolution. It also distinguishes itself from prediction_market_lookup by explicitly saying not to use it for prediction markets.

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

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

It gives explicit when-to-use guidance ('FIRST entry point'), an explicit when-not-to-use rule ('Do NOT use this tool for prediction markets'), and names the alternative tool ('use prediction_market_lookup instead'). It also adds a useful caveat about NFTs and name collisions, telling the agent to still check this tool when a query relates to a token even though Nansen MCP does not support NFTs.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description need not restate that. It adds that results are rankings segmented by several metrics, but it does not reveal behavior like aggregation method, data coverage limits, or pagination. This is acceptable given the annotations, but adds no strong behavioral detail.

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?

A single, focused sentence that state the purpose and the key output dimensions without filler or redundancy. The core action and resource are front-loaded for quick parsing.

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

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

With a full input schema, an output schema, and clear read-only annotations, the description covers what an agent needs to invoke the tool. It does not explain how to interpret the rankings or pagination, but for a straightforward read-only ranking query the provided context is sufficient.

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

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

The schema descriptions cover the request, chain_type, and time_frame parameters fully, so the schema does the heavy lifting. The tool description adds no additional meaning to the parameters, such as how chain_type or time_frame affect the rankings, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Get'), a clear resource ('chain growth rankings'), and the exact dimensions being ranked (active addresses, transactions, gas fees, DEX volume). This clearly differentiates it from the many address-, token-, and prediction-market-focused sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are stated. An agent must infer from the name and metrics that it is for chain-level growth analysis rather than address-, token-, or market-specific queries.

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

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

Annotations declare read-only/non-destructive behavior, and the description adds substantial context beyond that: ROI is PnL per dollar traded rather than return on capital, realized PnL is a net total so win rate cannot be derived, account value is only available for top 500K traders, and null/empty means unavailable rather than zero. These caveats materially change how an agent should interpret results.

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

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

The description is well-structured with headers, bullets, an example, and notes, and the core purpose is front-loaded. It is fairly long, but each section earns its place by addressing a real usage question: columns, semantics, sorting, filtering, and scope.

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 return columns, metric interpretations, sorting, filtering, domain restrictions, and the key alternative tool. Minor gaps remain, such as explicit valid date-token syntax and pagination behavior, but the example and output schema help fill those in, making the description largely complete for correct invocation.

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

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

Schema description coverage is effectively 0%, so the description carries the burden of explaining parameters. It names all filter fields (totalPnl, accountValue, roi), exact sort values, and the orderByDirection, and includes a full example request. It does not mention the page parameter, but the detailed field explanations and example largely compensate for the schema gap.

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

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

The description opens with a specific verb and resource: 'Get Hyperliquid perpetual futures trader leaderboard with performance metrics.' It clearly scopes the tool to Hyperliquid perps, distinguishing it from sibling leaderboard tools for prediction markets, tokens, and smart traders. The return format and column list further pin down what the tool does.

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

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

The description explicitly tells agents when to use a different tool: 'For a trader's open positions, call address_portfolio with mode="hyperliquid".' It also states 'Hyperliquid perpetual futures only,' limiting the tool's domain, and provides concrete sorting/filtering examples so an agent knows how to construct requests.

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

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

Annotations already declare readOnlyHint and non-destructive behavior. The description adds valuable behavioral context beyond that: daily batch updates, the performance_score >= 15 pre-filter, score ranges, dynamic indicator columns, and markdown output. No contradictions with annotations.

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

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

The description is long but well organized with bold section headers, bullets, and example queries. Some redundancy exists (the performance_score >= 15 threshold appears twice, and the output format is stated more than once), but the structure keeps it skimmable.

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 scoring semantics, return fields, dynamic columns, update cadence, and sibling-tool alternatives. It misses concrete guidance on how to pass the request payload and any pagination/result limits, but the output schema and annotations fill 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?

Schema description coverage is 0%, so the description should compensate, but it never explains the required 'request' object or the optional marketCapGroup parameter. The only hint is the generic word 'filter', which does not tell an agent how to structure input.

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

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

The description opens with a specific verb and resource: 'Discover and filter a daily list of attractive tokens using Nansen Score Indicators.' It clearly differentiates itself from token_quant_scores and token_discovery_screener, and states the core output: pre-filtered buy recommendations with Performance Score >= 15.

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 has an explicit 'When to use this tool vs token_discovery_screener' section with concrete conditions: use this for pre-scored recommendations without criteria, use the screener for live data or custom filters. It also tells agents to use token_quant_scores for specific token analysis and provides example queries.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses important behavioral nuances: 'The API gives no ROI or share count here. Do not state them.' and 'Blank PnL fields mean unavailable data, not zero.' These prevent the agent from making false inferences and add real value beyond the structured 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 well-structured with clear headings ('When to use', 'Key fields', 'Pitfalls') and front-loaded purpose. Every sentence adds meaningful information, and the format makes it easy to scan. It is detailed without being verbose.

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

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

The description covers the key output fields, usage context, and common pitfalls. It does not explain the request parameter, but the schema provides details for the nested properties, and the output schema is present. Minor gaps like explicit pagination behavior are not covered, but the overall guidance is solid for a read-only analysis tool.

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

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

The description does not explain the 'request' parameter structure at all. Although the schema includes descriptions for the nested 'address' and 'page' properties, the schema coverage is reported as 0% (the top-level 'request' parameter has no description). The description also does not mention pagination or how to specify the wallet address, so the agent must infer this from the tool name and schema alone.

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

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

The description states a specific verb and resource: 'Prediction market PnL breakdown for a Polygon wallet, market by market.' It clearly distinguishes this tool from the sibling prediction_market_address_summary by focusing on per-market detail versus aggregate, so an agent can select the right one without opening the schema.

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 has a dedicated 'When to use' section and explicitly names the alternative: 'use prediction_market_address_summary for the aggregate.' It also gives guidance on summing rows for a wallet total, leaving no ambiguity about when this tool is appropriate.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses important behavioral details: lifetime vs. derived field semantics, Total PnL = realized + unrealized, and the critical caveat that blank PnL fields mean unavailable data, not zero. It also warns that trade count, volume, and ROI are not provided by this API.

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 a one-line summary followed by concise, scannable sections for usage, key fields, and pitfalls. Every bullet earns its place and no redundant filler is present.

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

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

This is complete for a read-only summary tool: it covers when to use it, what the lifetime metrics mean, what the API cannot provide, how to interpret missing values, and which sibling tool to fall back to. The output schema exists, so return-value details are already structured.

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 for missing parameter meaning, but it never explains the `request` object or how the address/page parameters work. It only says the tool is 'for a Polygon wallet,' which lightly hints at the address field but does not convey the request structure or pagination behavior.

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 identifies the tool as the wallet-level Polymarket summary, using 'Prediction market summary metrics for a Polygon wallet' and 'First wallet-level Polymarket tool for a quick trader overview.' It explicitly distinguishes itself from detailed trade/PnL tools, and the key-fields list grounds the purpose in concrete output semantics.

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 gives explicit conditions: use it before detailed address trades/PnL when the user wants a wallet profile, activity summary, or Polymarket activity check. It also names the sibling tool prediction_market_address_pnl as the alternative for per-market costs and proceeds.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds useful interpretive context beyond annotations: 'Share Size' is per-outcome-side quantity and 'Value USD' applies to the row only, not the whole transaction. This helps avoid misinterpretation of the returned data.

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

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

The description is short, front-loaded with the core purpose, and uses clear bolded sections for key fields and pitfalls. Every sentence adds value, and the formatting makes the important caveats easy to scan.

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

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

For a simple read-only tool with an output schema and annotations covering safety, the description includes the crucial row-level semantics and the profitability caveat. It does not discuss default date ranges or pagination, but those are already present in the input schema, so nothing critical is missing for invoking the tool.

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

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

Schema description coverage is reported as 0%, so the description needed to compensate for parameter meaning, but it does not. It mentions 'Polygon wallet' generally but provides no guidance on the `request` object, `address`, `page`, `dateRange`, or date-range tokens. The only field-level detail is about output fields, not input 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 returns prediction market trade history for a Polygon wallet, and the pitfall note distinguishes it from profitability analysis. It lacks an explicit verb such as 'get' or 'list,' and does not name a sibling tool, so it stops short of a 5.

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

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

The pitfall explicitly says to use this tool for wallet trade activity, not profitability, giving a clear when-to-use and when-not-to-use signal. However, it does not name the alternative tool (e.g., prediction_market_address_pnl), leaving the agent to infer it from sibling names.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context beyond this: it uses Polymarket's search API, natural language queries work well, recommends short 1–3 keyword queries, and mandates explicit statement when no suitable market is found rather than silently substituting. These behaviors are not inferable from 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 lengthy but well-structured with clear section headers (PM building blocks, When to use, Query tips, Output rules) and a helpful example event vs. market. Each sentence serves a purpose, though it could be tightened without losing value. It is front-loaded with the core purpose and uses formatting to improve scannability.

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

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

Given the tool's complexity (nested request object, multiple configuration flags, integration with detail tools), the description is remarkably complete. It explains the event/market relationship, when to use this versus prediction_market_ohlcv, the importance of marketId for detail tools, query strategy, and output honesty rules. The presence of an output schema covers return values, so the description fills every other 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?

Schema description coverage is 0% for the top-level 'request' parameter, though nested properties have descriptions. The tool description compensates by explaining the purpose of queryVariant ('cleaner short keyword version') and includeEventMarkets ('also return child markets... for detail tools'), which adds meaning beyond the schema. It does not explicitly describe all parameters (e.g., maxCandidates, maxEventMarkets), but the schema covers those and the description's additions are genuine and useful.

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 states a specific verb and resource ('Search Polymarket for events and markets') and lists the search dimensions (name, topic, URL, slug). It also clarifies the event vs. market distinction, which differentiates it from siblings like general_search and prediction_market_ohlcv. The purpose is unambiguous and the tool is clearly distinguished.

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?

A dedicated 'When to use:' section explicitly states this is the first tool when the user provides a topic/event/slug/URL but no marketId. It explicitly says 'Do NOT use general_search for prediction markets' and routes price history queries to prediction_market_ohlcv. It also explains when to set includeEventMarkets and queryVariant, providing clear context and exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond this, such as the warning that each response is for one exact marketId (do not mix across markets) and the instruction to say so directly if no candles are returned rather than estimating. These add practical pitfalls not present in 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 well organized with bolded section headers ('When to use', 'Key fields', 'Pitfalls', 'Prerequisites') and is front-loaded with the core purpose. Each section adds practical value without significant fluff, though it could be slightly tighter.

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

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

Given the tool's complexity (nested request object) and the presence of an output schema, the description covers prerequisites, key field semantics, and common pitfalls. It does not detail date range defaults or pagination in prose, but those are already documented in the input schema, and the output schema handles return value expectations. Overall, it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. However, it does not explain the request object structure, dateRange tokens, orderBy options, or pagination. It only implicitly mentions marketId and explains the Close field's meaning. This fails to fill the gap left by the missing schema description.

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

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

The opening line 'Historical odds/volume candles for a Polymarket market' states a specific verb, resource, and data type. The 'When to use' section further clarifies it covers current odds, implied probability, price history, and recent probability changes, which distinguishes it from sibling tools like prediction_market_orderbook or prediction_market_trades.

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

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

The description includes a 'When to use' section and a 'Prerequisites' note that tells the agent to call prediction_market_lookup if marketId is unknown. It does not explicitly state when not to use this tool or compare against alternatives like orderbook or trades, but it gives enough context for an agent to select it 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?

Beyond the readOnly/openWorld annotations, the description adds critical behavioral nuance: order size is share quantity not USD, Yes and No are complementary, No bids act as resistance to Yes rallies, and No-side prices must be converted to Yes-equivalent before comparing with OHLCV. These guardrails materially change how an agent interprets results.

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

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

The description is long but well-structured with bold section headers, and each bullet provides distinct, non-redundant guidance. No sentence is filler; the Yes/No relationship and pitfall details earn their space.

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

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

Given the output schema exists, return format does not need to be described. The description covers when to use, how to source the required `marketId`, how to interpret values, and which sibling to prefer, making it complete for correct invocation.

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

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

Schema description coverage is 0%, and the description does not explain the `request` object or `page` parameter, though the schema itself already documents `marketId` and `page` properties. It does add the useful prerequisite 'If `marketId` is unknown, call `prediction_market_lookup` first', but this conflicts slightly with the schema's `marketId` description which says to obtain it from `prediction_market_screener`.

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 states a specific resource ('Live orderbook for a Polymarket market') and enumerates its intended outputs: bid/ask depth, liquidity, and yes-share/no-share order structure. It also implicitly distinguishes itself from the sibling `prediction_market_ohlcv` by pointing to that tool for current odds and implied probability.

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?

It has an explicit 'When to use' bullet, a 'Pitfalls' section that explicitly routes to `prediction_market_ohlcv` for current odds, and a 'Prerequisites' telling the agent to call `prediction_market_lookup` if `marketId` is unknown. This leaves no ambiguity about when to pick this tool over 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?

Annotations already mark the tool as readOnly and non-destructive, but the description goes well beyond that by defining the exact PnL formula, explaining each field, and warning that ROI, volume, and trade count are not provided. It also tells the agent how to behave when PnL fields are blank, which is valuable operational guidance.

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

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

The description is organized into clear, scannable sections with front-loaded purpose, definitions, pitfalls, and prerequisites. Every section adds practical value, and the bullets make the longer content easy for an agent to parse.

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

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

For a tool with this complexity, the description is remarkably complete: it covers the PnL formula, field meanings, missing-data behavior, and prerequisites, while the output schema handles return shape. It falls slightly short due to the inconsistent marketId source guidance and the lack of explicit differentiation from similar PnL tools.

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

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

The top-level request parameter has 0% schema description coverage and the description does not explain the request object or the page parameter. It does note that marketId can be obtained via prediction_market_lookup, but this conflicts with the schema's instruction to get it from prediction_market_screener, and no other parameter semantics are compensated for.

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

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

The description opens with a specific definition: 'PnL leaderboard for a Polymarket market,' which names the resource and scope. It further narrows the purpose with 'Only for profitability claims' and explains the key PnL fields, making it clearly distinguishable from token- or address-level PnL 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 'When to use' section explicitly limits the tool to profitability claims, and the prerequisites section gives a concrete next step if marketId is unknown. It does not name sibling alternatives or give explicit when-not-to-use exclusions beyond profitability claims, so a small gap remains.

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

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

Beyond the readOnlyHint=true annotation, the description discloses important behavioral details: each row represents one outcome token of one wallet, a wallet holding both sides appears twice, and Position PnL applies only to the displayed row. These pitfalls and row-scoping notes add real interpretive value that an agent could not infer from annotations or the schema.

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

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

The description is well-organized with bold section headers, concise bullets for key fields, an explicit pitfalls section, and a one-line prerequisite. Every sentence adds non-obvious information and the most important framing comes first.

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

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

Given the output schema exists, the description still explains the meaningful fields, warns about duplicate rows for two-sided positions, and routes to prediction_market_lookup when marketId is unknown. This is sufficient for an agent to know what the tool returns, what the numbers mean, and what to do before calling it.

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

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

Although the reported schema description coverage is 0%, the nested schema itself documents marketId and page with meaningful descriptions. The tool description adds a useful prerequisite for obtaining marketId, but it does not explain the request wrapper or the pagination parameter, so it only partially compensates for the top-level schema gap.

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

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

The description opens with 'Detailed position breakdown for a Polymarket market,' which names a specific resource and the kind of output an agent can expect. It is clear and distinct from the many trading-history siblings, though it does not explicitly contrast itself with nearby tools like prediction_market_address_summary or prediction_market_trades.

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

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

The description gives a concrete prerequisite and an explicit alternative: 'If marketId is unknown, call prediction_market_lookup first.' It also implies the tool is for inspecting positions in a specific market, which gives an agent context for when to choose it, but it does not exhaustively list when-not-to-use cases against the other prediction_market_* 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?

The description discloses search behavior not captured by annotations: 'Literal-style matching on text and slugs, not fuzzy web search.' It also sets output-handling rules ('If a query returns no rows, do not invent a nearest match') and prevents overinference from titles, which is important for trustworthy results. Annotations already declare read-only and open-world, and the description adds substantial behavioral context beyond them.

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

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

The description is organized with clear headers (When to use, Query tips, Output rules) and front-loads the core purpose. Every section earns its place by providing actionable guidance; there is no filler or repetition of schema details.

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

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

For a broad discovery tool with an output schema and annotations, the description covers use cases, exclusions, query formulation, empty-result handling, and output accuracy expectations. The combination of annotations, schema, and description leaves little an agent needs to invoke the tool correctly.

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

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

The input schema documents nested fields (mode, page, query, status, orderBy), but the tool description adds critical query semantics: 'Literal-style matching on text and slugs,' 'Prefer one short topic or slug fragment,' and 'Do not bundle unrelated topics.' It also maps to mode by naming markets/events/categories. This goes beyond the schema's generic 'Optional text query for filtering' description, though it does not elaborate on status or orderBy values.

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

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

The description opens with a specific verb and resource: 'Browse and sort Polymarket markets, events, or categories.' It further clarifies this is for 'broad discovery, screening, and ranked browsing across many markets,' and explicitly contrasts with the sibling `prediction_market_lookup`, so an agent can distinguish it without inspecting schemas.

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?

It provides an explicit 'When to use' section stating the intended scope and a direct exclusion: 'Do NOT use this to resolve one named market/event/slug/URL — use prediction_market_lookup instead.' Query tips further guide usage with concrete examples and negative constraints (e.g., 'Do not bundle unrelated topics').

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 annotations declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds behavioral context such as: positions are share balances not USD notional, Position Value USD is marked value not payout, and output summary is based only on shown rows. This enriches the read-only nature but does not mention pagination specifics or rate limits, which is acceptable given the annotation coverage.

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 purposeful sections labeled 'Key fields' and 'Pitfalls' and a 'Prerequisites' note. Every bullet adds value, front-loading the most critical interpretations and cautions. No redundant sentences; each provides operational guidance.

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 schema, potential ambiguity in interpreting positions and values) and the presence of an output schema, the description covers the critical pitfalls and prerequisites that an agent needs to avoid misinterpretation. It also references related tools for lookup, completing the context. Combined with the output schema, this is adequate for correct invocation.

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

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

The input schema has one parameter 'request' with nested properties, and the schema description coverage is 0% (schema properties have their own descriptions but not summarized in the tool description). The tool description does not explain the parameters beyond referencing marketId in prerequisites admissions. For example, it doesn't clarify that marketId is required in the nested schema. With 0% coverage, the description should compensate, but it partially does by mentioning the prerequisite. It lacks detail on orderBy options, which are partially self-explanatory from enums, but the description doesn't add meaning beyond schema. Score 3 as baseline for low coverage with minimal compensation.

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 states a specific verb ('finding'), a specific resource ('top holders for a Polymarket market'), and clearly distinguishes it from siblings. It names a prerequisite tool and includes usage notes, making the purpose unmistakable despite the terse title. It is clear and specific, differentiating from other prediction_market tools.

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

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

Explicitly states a prerequisite: if marketId is unknown, call prediction_market_lookup first. It also warns against over-interpreting data (e.g., not labeling positions as smart money without Nansen support), which helps the agent avoid misuse. The description effectively guides correct usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: each row is one trade leg with Value USD scoped to that row, and large visible trades do not indicate smart money. This clarifies return semantics and common misinterpretations beyond the structured metadata.

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 clear sections (When to use, Key fields, Pitfalls, Prerequisites) and is appropriately sized. It front-loads the core purpose and efficiently conveys all necessary guidance without redundancy.

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

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

Given that an output schema exists, the description correctly focuses on usage, pitfalls, and field meanings. It covers prerequisites, typical use cases, and potential misinterpretations, making it fully adequate for an agent to call the tool correctly. No critical information is missing.

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

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

The input schema already provides descriptions for all parameters (marketId, page, dateRange), so baseline is 3. The description adds a hint about obtaining marketId via prediction_market_lookup, but does not elaborate on page or dateRange semantics beyond the schema. It does not significantly enhance parameter understanding, but it doesn't need to given the schema coverage.

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

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

The description clearly states 'Recent trades for a Polymarket market' with a specific verb and resource, and distinguishes itself as the 'source of truth for recent fills and latest trade-tape pricing.' It differentiates from siblings like prediction_market_ohlcv by emphasizing the trade-tape nature.

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

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

Explicit 'When to use' section with clear guidance: it is the source for recent fills and warns not to overwrite with OHLCV. Also provides a prerequisite to call prediction_market_lookup if marketId is unknown, and a pitfall about interpreting large trades. This fully guides an agent on when and when not to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope and output context (Solana, deposit size, amount spent, order status), but it does not disclose pagination, default ordering, or other query behavior. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core purpose and followed by a single routing note. No filler, no repetition, every sentence 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?

For a read-only tool with an output schema, the description covers the core purpose, Solana scope, returned data categories, and the key sibling distinction. It omits pagination and default sort behavior, but the schema's property descriptions and output schema fill in much of the remaining detail.

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 reported at 0%, so the description needed to compensate by explaining how to use the sole `request` parameter. It does not: it only describes what the tool returns, not how to construct the request object. The nested schema fields are documented, but the description itself adds no parameter-level meaning.

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

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

The description opens with a specific verb and resource: 'Get Jupiter DCA (dollar-cost-averaging) orders opened by smart traders and funds on Solana.' It also names the included fields (deposit size, amount spent, order status) and explicitly distinguishes it from the one-off-swap sibling tool, so an agent can tell it apart from the many smart_traders 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?

It states the intended scenario directly: 'Use this for scheduled accumulation intent.' It also names the alternative for the opposite case: 'use smart_traders_and_funds_dex_trades for one-off swaps.' This is an explicit when-to-use and when-not-to-use signal.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the data is individual per-wallet/per-transaction, and the population explicitly excludes whales/large holders/influencers, which shapes interpretation of results.

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

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

Two sentences with no filler. The first sentence front-loads the scope, exclusions, and chain default; the second points to the relevant sibling. 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?

For a read-only query tool with an output schema and safety annotations, the description covers the core semantics: granularity, population exclusions, chain scope, and the aggregated alternative. Nothing critical is missing for an agent to decide whether to call this tool.

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

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

The prose adds little parameter-specific meaning beyond the default chain behavior; the heavy lifting is done by the schema, which documents each filter (chains, orderBy, tradeValueUsd, traderAddress, token symbols, includeSmartMoneyLabels). Although context reports 0% schema description coverage, the embedded schema clearly describes the nested filters, so a baseline 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?

States a specific verb and resource: get individual DEX trades made by smart traders and funds, per wallet and per transaction. It explicitly excludes whales/large holders/influencers and names the default chain behavior, which distinguishes it from sibling tools like netflow, perp_trades, and dcas.

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 a clear routing cue: use this for exactly which wallet bought/sold what, and use smart_traders_and_funds_netflow for the aggregated view. It does not explicitly address other sibling alternatives, but the tool name and descriptions of those siblings make the distinction fairly obvious.

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

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

Annotations already mark the tool read-only and non-destructive, and the description adds important behavior beyond that: results are aggregated, day-by-day, multi-chain, and explicitly exclude whales/large holders/influencers. This is genuine behavioral context, not just a safety profile.

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

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

Two sentences with no filler: the first defines the data captured, and the second routes the agent to the correct sibling. The exclusion and chain scope are front-loaded and every phrase 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?

For tool selection, the description is complete enough: it gives the historical intent, exclusions, supported chains, and the close sibling alternative, while output schema covers return shape. It does not state defaults such as the 30-day lookback or maximum 4-year range, but the input schema handles those details.

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

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

The description only gestures at date range and chains, and the chain list mostly repeats the schema enum. With schema description coverage at 0%, the description does not compensate by explaining the request envelope, dateRange formats, token filters, or the include/label options, even though the nested schema itself is detailed.

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 uses a specific verb and resource: 'Get the day-by-day history of aggregated smart trader and fund token balances,' and adds scope by naming the excluded groups and supported chains. It also names a sibling for the current snapshot, so an agent can distinguish it from smart_traders_and_funds_token_balances without inspecting that tool's schema.

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?

It explicitly says when to use it: 'Use this to see how smart money holdings changed over time; use smart_traders_and_funds_token_balances for the current snapshot.' That gives a clear decision rule and points to the most likely sibling alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by clarifying that data is aggregated, not per-wallet, and that whales/large holders/influencers are excluded, which materially affects interpretation of results.

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

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

Two crisp sentences front-load the core behavior and end with a pointer to the relevant sibling. No filler words, and every clause adds decision-relevant 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 read-only annotations and the presence of an output schema, the description is sufficient for an agent to select and invoke the tool correctly. It covers the key dimensions of aggregation, exclusions, timeframes, and chain scope, though it could marginally benefit from mentioning default ordering or filtering options 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 top-level schema has 0% description coverage, so the description partially compensates by explaining the core semantics: USD net flow per token over 1h/24h/7d/30d and per-chain filtering with a default of all chains. However, it does not explain the required request wrapper or any of the filter options beyond chains, leaving the nested schema to carry most parameter-level meaning.

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 a specific verb ('Get') and resource ('aggregated smart trader and fund net USD flow per token'), and explicitly scopes what is included and excluded ('EXCLUDES whales, large holders, influencers, etc.'). It also differentiates itself from a sibling tool by pointing to smart_traders_and_funds_token_balances for holdings.

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

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

The description gives a clear usage context: use this for what smart money is buying or selling right now, and use smart_traders_and_funds_token_balances for what they hold. It names one key alternative but does not fully cover when to choose other smart-money siblings like dcas, dex_trades, or historical balances.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral caveats beyond them: Hyperliquid-only, no date filtering, recent trades only, and that labels do not expand the address universe. The label warning is especially useful because it prevents a likely misinterpretation.

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

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

The description is long but well organized: purpose, caveats, returned columns, sorting, and examples are all separated. It front-loads the most decision-relevant constraints before the detailed column list. The column list is somewhat redundant given that an output schema exists, but it is scannable and not padded.

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 provides scope, exclusions, sorting contract, label semantics, and example request bodies, which is sufficient given the annotated schema and output schema. An agent has what it needs to invoke the tool correctly and avoid the common mistakes of label searching or expecting historical date filtering.

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

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

Schema description coverage is low (0%), so the description compensates by explaining sortable fields, the default orderBy behavior ('amount', direction desc), and the important includeSmartMoneyLabels semantics. The concrete JSON examples also clarify how parameters are passed. However, page, valueUsd, and traderAddress are not covered in prose, so some burden remains on 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 first sentence is specific: 'Get recent Hyperliquid perpetual futures trades from Smart Money addresses across all tokens.' This names the verb, resource, scope, and domain, and clearly differentiates it from sibling tools such as smart_traders_and_funds_dex_trades and smart_traders_and_funds_dcas.

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 labels narrow the Smart Money cohort and are not a general label search. It also names the alternative for broad Smart Money activity: token_discovery_screener with traderType="sm". The Hyperliquid-only and recent-trades-only constraints further clarify when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds behavioral context by specifying that it EXCLUDES whales and large holders, and details the PnL metrics and time windows (1/7/30/90/180 days). This goes beyond the annotations and helps the agent understand the exact scope of the leaderboard.

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, with the first sentence front-loading the core purpose and scope, and the second sentence providing usage guidance and an alternative. There is no fluff or redundancy, making it efficient for an agent to parse quickly.

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

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

For a read-only leaderboard tool with a rich input schema and an output schema present, the description provides enough context for the agent to understand the core functionality and when to use it. It does not describe the output format, but that is covered by the output schema. The main gap is that it does not mention the available filters (chains, labels) explicitly, though the schema covers them.

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

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

The description mentions 'realized, unrealized and total USD PnL' and '1/7/30/90/180 day window', which directly map to the orderBy and timeframe parameters in the schema. However, it does not explain chains, orderByDirection, includeSmartMoneyLabels, or pagination. Since the schema itself has detailed descriptions for these properties, the description adds partial meaning but does not fully compensate for the 0% schema description coverage from the description side.

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 ranks smart trader and fund addresses by PnL metrics, explicitly excludes whales/large holders/influencers, and names the specific sibling (token_pnl_leaderboard) for the alternative use case. This distinguishes it from the many sibling tools that focus on specific tokens or other smart-money data.

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

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

The description provides explicit guidance on when to use this tool ('to find the best performing smart money wallets') and when to use the alternative ('use token_pnl_leaderboard for the best performers on one specific token'). This covers the primary routing scenario, though it does not mention other relevant siblings like smart_traders_and_funds_dcas or perp 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?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: aggregated rather than per-wallet data, category exclusions, 24h change, per-chain segmentation, and the 'all' default. It does not mention pagination or response size, but the output schema covers return shape.

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 tight sentences: the first states the action, aggregation level, exclusions, chain behavior, and 24h change; the second points to filtering. No filler, repetition, or unnecessary detail.

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

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

The description covers the essential decisions: aggregation level, exclusions, chain selection, and time-window change. Pagination and sorting are left to the schema, which is acceptable given the output schema exists; a brief pointer to the available filters would make it slightly more self-contained.

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 prose only says 'Use filters to narrow down the results' and mentions chain selection; it does not explain page, orderBy, minHolders, includeStablecoin, includeNativeTokens, or includeSmartMoneyLabels. Although the nested schema has some descriptions, the reported schema description coverage is 0%, and the tool description itself does not compensate for parameter-level meaning.

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

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

The description opens with a specific verb and resource: 'Get aggregated ... smart trader and fund ... token balances and 24h change per chain.' It clearly distinguishes this tool from per-wallet views and explicitly excludes whales, large holders, and influencers, making its scope unambiguous relative to sibling tools.

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

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

The description gives useful context: aggregate smart-money balances by chain, default to all chains or specify chains, and use filters to narrow results. However, it does not explicitly say when to prefer this over sibling tools like smart_traders_and_funds_historical_token_balances or smart_traders_and_funds_netflow, and offers no when-not-to-use guidance beyond 'not per wallet.'

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description goes far beyond these by disclosing pagination (25 per page), fallback behavior for unsupported sort values (falls back to holding_size and notes the change), mode-specific column sets, and restrictions on native tokens and stablecoins. It also notes that unsupported combinations are not errors but degrade gracefully.

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

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

The description is long but exceptionally well-structured: it opens with a one-line summary, then uses headers (Note, Modes, Columns returned, Sorting Options, Examples, Restrictions) to organize dense information. Every section serves a distinct purpose—examples are practical, restrictions are clearly separated, and columns are listed per mode. There is no fluff; each sentence earns its place.

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

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

Given the tool's complexity (two modes, many parameters, multiple restrictions), the description is complete. It covers modes, columns, sorting options, fallback behavior, native-token restrictions, SOL exclusion, and provides five examples covering the main use cases. An output schema exists, so return value details are covered there; the description adds the operational context an agent needs.

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

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

Although the input schema provides descriptions for each parameter, the tool description adds substantial meaning through examples that show real parameter combinations (e.g., mode, chain, token_address, label_type, orderBy, includeSmartMoneyLabels). It clarifies the meaning of mode with defaults, explains the orderBy enum values per mode, and shows how filters like upnlUsd and positionValueUsd work in perps. This is far beyond the schema's terse 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 opens with a specific, concrete statement: 'Get upto 25 (per page) top holders information for a specific token.' It clearly identifies the resource (token holders) and the action (retrieve), and distinguishes between onchain_tokens and perps modes. This differentiates it from sibling tools like token_flows or token_transfers, which have different scopes.

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: it warns against using smart_money as a market proxy, explains the two modes and when each is appropriate, gives an explicit exclusion for SOL in onchain_tokens mode with a pointer to perps, and details sorting restrictions for native tokens/stablecoins. It also mentions alternative labelTypes to bypass limitations. This is comprehensive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds useful behavioral nuances, such as mode-specific analysis and the native-token limitation, but does not discuss pagination or output behavior. Given the annotation coverage, this is acceptable but not rich.

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

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

The description is compact and well-structured: a one-line summary, a clean two-bullet mode list, and a single important note. Every sentence adds value, and the core action is front-loaded without redundancy.

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

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

Given the tool's complexity (a large request object with many fields), the schema and output schema handle most details. The description fills the most critical cross-cutting gap—native token handling and mode selection—making it sufficient for a read-only query tool.

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

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

Schema description coverage is 100% for the single top-level parameter, giving a baseline of 3. The description elevates this by explaining that perps mode auto-sets chain to 'hyperliquid' and that onchain_tokens only supports ETH among native tokens—details that are not fully captured in the schema and help agents choose the right mode and 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 states a specific verb and resource: 'Get DEX trades for a specific token.' It goes on to describe two modes, clarifying the tool's scope. However, it does not explicitly differentiate itself from sibling tools like address_dex_trades or smart_traders_and_funds_dex_trades, though the token-centric focus is evident.

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

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

The description provides clear internal guidance: it explains when to use onchain_tokens vs perps mode, and specifically directs users to perps for native tokens other than ETH. It does not mention when to prefer this tool over sibling DEX-trade tools, so it offers clear context but no explicit alternatives.

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

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

Annotations already indicate a safe read-only operation, and the description adds substantial behavioral detail: a 25-result page cap, the 5-chain maximum with automatic trimming, the two-section mixed spot + Hyperliquid response, fallback behavior for unsupported filters/orderBy fields, and a timeout warning recommending 4 chains or fewer. It also states the empty-string return when no tokens are found. No contradiction with annotations 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 long but well-organized with clear sections: overview, input examples, warnings, returns, notes, filtering options, and sorting options. It is front-loaded with the purpose and the most important constraints. Some redundancy exists — page limits and defaults are repeated in the schema, and the 'Args:' label is empty — but the length is largely 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, one required request object, no schema-level coverage, and rich sibling context, the description covers everything needed to invoke it correctly: examples, limits, perps special cases, valid sectors, traderType semantics, timeout mitigation, and return format. The output schema exists, so the detailed return-column list is a bonus rather than a necessity.

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

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

With schema description coverage at 0%, the description carries the full burden, and it delivers: numeric filter ranges, category filters, asset-class toggles, traderType constraints, sorting fields, default orderBy, and Hyperliquid-specific fields are all explained. It even clarifies which fields are filter-only versus sort-only, and warns that 'priceChange' cannot be filtered. This fully compensates for the absent schema-level 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 first sentence states a precise verb and resource: 'Get comprehensive token screening data across multiple blockchain networks with advanced filtering.' It clarifies that the tool is for token discovery and trending-token identification by combining volume, liquidity, market cap, smart money activity, and token age. It does not explicitly distinguish itself from sibling screeners like prediction_market_screener, but the core purpose is unmistakable.

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 extensive when-to-use guidance: when to sort versus filter, when traderType should be used ('ONLY when user explicitly asks for smart money'), when stablecoins/native tokens should be included, and a critical warning that 'priceChange' is not a valid filter. It provides concrete examples for common discovery scenarios. It does not name alternatives among sibling tools, but it clearly explains conditions and exclusions within this tool's parameter space.

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

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses two distinct modes (onchain_tokens vs perps), the native-token fallback behavior with a data-source warning, and that it provides hourly flows over the entire time frame. This is rich behavioral context that annotations alone do not convey.

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

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

The description is long but well-structured with clear Modes and Note sections. It front-loads the core purpose and the alternative usage, then expands on necessary edge cases. Each section earns its place; it is thorough without being redundant.

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

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

Covers all critical aspects: modes, native-token handling, holder-segment caveats, and comparison to the sibling. Since an output schema exists, return values are already defined. Nothing an agent needs to call this tool correctly is missing.

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 holder_segment caveat (smart_money not a good proxy for market view) and detailing the mode-specific behavior, including the native-token fallback. These insights go 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?

States a specific verb and resource: 'Get hourly token-flow history for ONE holder segment over a date range.' It explicitly contrasts with the sibling token_recent_flows_summary, making the purpose and scope unambiguous. The agent can immediately tell what this tool does and how it differs.

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?

Directly instructs when to use the alternative: 'Use token_recent_flows_summary instead for an on-chain snapshot across ALL wallet categories.' It also cautions that holder_segment=smart_money is not a good proxy for an overall market view and should only be used when explicitly requested. Clear when-to-use and when-not-to-use 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 already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds substantial behavioral context: it details the return format (markdown), the two modes with distinct fields, and notes about address vs symbol usage. It also provides example JSON structures, clarifying expected inputs. This goes well beyond the annotations and fully informs the agent of 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 long but well-structured, using headings, bullet lists, and examples. It front-loads the purpose and then systematically details fields, notes, and examples. Each section earns its place; there is no filler or repetition. The structure makes it easy to scan and reference.

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 is complete for a tool of this complexity. It covers both modes, all parameters, the return fields for each mode, and practical notes (address vs symbol, timeframe options). The example JSONs are provided. With the output schema present (as indicated), the description does not need to explain return values further. Nothing critical is missing.

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

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

Despite the schema coverage being reported as 0%, the description thoroughly explains all parameters. It covers mode (onchain_tokens vs perps), chain (with supported networks), timeframe (with allowed values), and tokenAddress (explaining address vs symbol). The examples clarify the exact format. The description compensates fully for the lack of schema-level parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get token information — spot on-chain details or Hyperliquid perpetual futures stats.' It names the two modes and differentiates them, and the title 'Loading token info' aligns. The description distinguishes this tool from siblings like token_dex_trades or token_ohlcv by focusing on token info rather than specific transactions or price data.

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

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

The description provides clear guidance on when to use each mode: on-chain for spot details (contract addresses) and perps for Hyperliquid stats (symbols). It also explains the default mode and the distinction between address vs symbol. However, it does not explicitly mention when to use this tool instead of sibling tools like token_dex_trades or token_ohlcv, so no exclusions or alternatives are stated. This is clear context but lacks explicit 'when-not' guidance for other tools.

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

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

Annotations already convey readOnlyHint, openWorldHint, and non-destructiveness. The description adds meaningful context by clarifying that this surfaces scheduled buying/selling pressure and by naming the returned metrics (deposit size, amount spent, amount accumulated, status). It does not contradict annotations.

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

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

Two tight sentences with no filler. The core purpose is front-loaded, followed by usage guidance and a chain restriction. Every sentence earns its place.

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

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

Given an output schema exists and annotations cover safety, the description is largely sufficient: it provides purpose, a concrete use case, a sibling distinction, and a chain constraint. It omits filter behavior, but the schema documents the filtering parameters, so the practical gap is small.

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 reported as 0%, and the description does not compensate for the input parameters. It says nothing about tokenAddress, status, traderAddress, depositUsdValue, includeSmartMoneyLabels, or page; only output concepts are mentioned, so it adds little 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 opens with a specific verb and resource: 'Get Jupiter DCA (dollar-cost-averaging) orders opened against a Solana token', and lists key returned fields. It also clearly distinguishes itself from token_dex_trades, so an agent can differentiate sibling tools without opening schemas.

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

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

The description explicitly states when to use this tool ('see scheduled buying or selling pressure that has not hit the market yet') and names the alternative for executed trades ('use token_dex_trades for trades already executed'). It also restricts scope to Solana tokens, leaving no ambiguity.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower. The description still adds value by disclosing the automatic interval resolution rules, the supported chain types (EVM, Solana, Hyperliquid), the Hyperliquid prefix normalization behavior, and the returned column set including market cap fields. No contradiction with annotations.

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

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

The description is long and slightly repetitive: the first three WETH examples could be reduced, and the resolution table already communicates the interval logic. However, it is well-structured with bolded directives, a clean list, and syntax-highlighted JSON examples, making it easy to scan despite the length.

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

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

Given the tool's complexity (polymorphic request, multiple chains, date-range syntax), the description covers everything needed to invoke it correctly: scope, chains, token identification, date values, resolution behavior, return columns, and the key alternative. The output schema exists, so detailed return formatting is not required.

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 carry the parameter meaning, and it does thoroughly. It explains date tokens like '7D_AGO', '5MIN_AGO', 'NOW', shows chain values through examples, clarifies tokenAddress can be an address or perp symbol, and mentions includeMarketCap behavior. The examples are unambiguous and cover the main parameter combinations.

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

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

The description opens with a specific verb-resource statement: 'Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution.' It also distinguishes this tool from the sibling general_search by explicitly stating 'YOU MUST USE THIS over general_search to get prices.' The title is generic, but the description makes the tool's differentiation clear.

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

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

The description provides explicit when-to-use guidance: 'YOU MUST USE THIS over general_search to get prices' and warns that general_search prices are 'delayed and often incorrect.' It also gives a concrete recipe for the latest price ('from 5MIN_AGO' to 'NOW') and explains how to use it for Hyperliquid perps with chain='hyperliquid' and the perp symbol as tokenAddress.

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 is exceptionally transparent about behavior beyond annotations. It explicitly states the 25-result limit ('ONLY RETURNS TOP 25 RESULTS... the result is NEVER complete'), the mode limitations (native tokens not supported in onchain_tokens mode, hyperevm not supported as chain), and the output format (markdown, empty string if no data). These details add significant value over the readOnlyHint and openWorldHint 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 well-structured with clear headings (Modes, Returns, Sorting, Filtering, Examples, Notes) but is quite long, with a lengthy column list that could be trimmed. It is front-loaded with the core purpose but includes redundancy (e.g., repeated mentions of native token limitations). The organization helps readability, but the verbosity prevents a higher score.

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

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

For a tool with one complex request object and many parameters, the description is comprehensive. It covers modes, limitations, sorting/filtering options, output columns, examples, and critical notes about result limits. It also provides a complete column list that serves as an effective output schema. Nothing essential for correct invocation is missing.

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

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

Despite the schema description coverage being 0% per context, the description compensates well by listing all sorting fields and grouping filter options (list filters vs numeric range filters). It also explains the mode parameter thoroughly and provides examples that illustrate parameter usage. However, it does not describe every filter parameter in detail (e.g., nofBuys, soldUsd), though the schema itself includes descriptions for those. The description adds structure and context beyond the schema, earning a 4.

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

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

The description clearly states the tool's function: 'Upto 25 results (per page) of trader PnL for a token.' It specifies the resource (token PnL leaderboard), the verb (return/analyze), and differentiates between onchain and perps modes. This is specific enough to distinguish it from wallet-level PnL tools or prediction-market-specific 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 explains the modes and gives examples, but it does not explicitly state when to use this tool over siblings like wallet_pnl_for_token or prediction_market_pnl_leaderboard. It implies use for token-level leaderboards but never names alternatives or exclusion criteria, leaving the agent to infer the appropriate 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it explains the output structure (Score, Signal, Percentile, Last Trigger), notes that not all indicators are available for every token/chain combination, and mentions that some indicators don't apply to stablecoins. This goes beyond the annotations and gives the agent a clear picture of what to expect. No contradictions with annotations.

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

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

The description is well-structured and front-loaded with purpose and usage, then details the output format and indicator types. It is somewhat long but every section adds value — the output field explanations and indicator categories are necessary for correct interpretation. No fluff, so it earns a 4.

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 indicator types, percentile comparisons, caveats), the description is fairly complete. It explains the output fields, indicator categories, and the note about availability. It does not explicitly state that a token address is required, but the schema makes that clear. The output schema exists, so return values are covered. Minor gaps exist (e.g., error handling, prerequisites), but overall the description provides enough context for an 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% — the tool description does not explain how to construct the 'request' parameter. The schema itself includes descriptions for 'chain' and 'tokenAddress', but the 'request' wrapper is an anyOf with two object types, which could confuse an agent. The description does not compensate by explaining that the tool requires a token address and chain, nor does it clarify the anyOf structure. With low schema coverage, the description was expected to fill the gap but does not, so this dimension scores low.

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

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

The description opens with a clear statement of what the tool does: 'Get Nansen Score Indicators for a token - quantitative risk and reward signals.' It specifies the resource (token) and action (get), and distinguishes itself from siblings like token_technical_indicators by focusing on risk/reward scoring. The purpose is unambiguous and 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 the tool: 'Use this tool when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions.' This provides clear context. It does not mention when not to use it or alternative tools, but the explicit positive guidance is strong, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds meaningful behavioral context: aggregation over lookback periods, the interpretation of positive/negative flow, exchange flow semantics, and perps mode return details. No contradiction with annotations.

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

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

The description is detailed and well-structured with sections, but somewhat long. It front-loads the core purpose and uses bullets for return values, though some redundancy exists (e.g., repeated notes on positive/negative flow). Still, every major sentence adds value and it is not bloated to the point of distraction.

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, the description is remarkably complete: it covers scope, supported chains, return format, interpretation, limitations, modes, and proscriptions. With output schema present and annotations covering safety, nothing an agent needs to call it correctly is missing.

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 carry the burden. It explains modes (onchain_tokens vs perps), supported chains (ETH, SOL), lookback period options, and how mode defaults to perps for symbols. It also describes the request's flattened structure and return format, adding semantics far beyond the sparse schema.

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

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

The description clearly states the tool gets an on-chain flow snapshot across all wallet categories in one call, lists the segments, and explicitly contrasts with token_flows for specific date ranges. It is a specific verb+resource that distinguishes it 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?

It provides explicit when-to-use guidance: correct for standard lookbacks like 1d, and explicitly names token_flows as the alternative for specific date ranges and hourly breakdowns. It also warns Bitcoin is not supported and instructs to use token_flows for granular needs, making selection unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with read-only behavior. The description adds only that it lists 'valid' sectors, implying a controlled vocabulary. It does not contradict annotations but also does not provide significant behavioral detail beyond what annotations already convey.

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, succinct sentence that front-loads the verb and resource. There is no fluff, and every word contributes to clarity. It is an example of concise and well-structured tool documentation.

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

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

For a tool with no parameters and an existing output schema, the description is fully sufficient. It explains the tool's purpose, and the output schema provides the return structure. No additional information is needed for an agent to call this tool correctly.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate for no parameters. The description does not need to explain parameters and does not attempt to, so it does not detract from the baseline.

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

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

The description clearly states the tool's function: listing valid token sectors for token discovery filters. The verb 'List' and resource 'token sectors' are specific, and the purpose ties directly to token discovery, distinguishing it from sibling tools like token_discovery_screener that likely consume these sectors.

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

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

The description provides clear context that the tool's output is intended for token discovery filters, implying its use case. However, it does not explicitly mention when to use it versus alternatives or when not to use it, and it names no sibling tools. The context is sufficient for an agent to infer usage but lacks explicit exclusions.

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

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

Annotations already mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: computation from the last 260 closed candles, explicit timeframe with no auto-resolution, n/a behavior for insufficient history, and the Hyperliquid VWAP volume-NULL limitation. This is the kind of behavioral disclosure an agent needs.

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

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

The description is long, but it is well-organized with sections, bolded callouts, a timeframe list, and concrete examples. It earns most of its length; the detailed per-indicator output bullets are slightly redundant given an output schema exists, so it is not maximally lean.

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

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

For a complex tool covering multiple chains, perp futures, seven timeframes, and seven indicator groups, the description covers all operational edge cases: insufficient-history n/a, Hyperliquid symbol formats, timeframe semantics, VWAP unavailability, and the output shape. Nothing an agent needs to invoke it correctly is missing.

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 bears the full burden of explaining parameters, and it delivers. It explains that chain supports EVM/Solana and Hyperliquid, how to encode perp symbols as tokenAddress with namespace normalization, the full timeframe enum and its default, and that results are always computed up to now with no date range. The two JSON examples make the intended 'request' shape unambiguous.

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

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

The description opens with a specific verb and resource: 'Get a technical-analysis snapshot for a token', then enumerates exactly which indicators are computed. It distinguishes itself from the sibling token_ohlcv by explicitly saying it should be used instead of computing indicators from raw candles.

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

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

The description gives explicit when-to-use guidance with '**YOU MUST USE THIS** for technical analysis instead of computing indicators from raw token_ohlcv candles' and explains why (more history, charting conventions). It also gives concrete guidance for Hyperliquid perps, timeframe selection by horizon, and the VWAP-on-Hyperliquid caveat.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: pagination (25 per page), default sort order (most recent first), the native token exclusion, and the clamping behavior of dateRange (max 365 days, clamped and reported). It also clarifies the smart money filter semantics (only profitable addresses) and that transferValueUsd is valued at time of transaction. This goes beyond the annotations and schema. Slight deduction: it doesn't explicitly mention rate limits or what happens with invalid parameters.

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

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

The description is long but well-structured: opening statement, columns list, sorting options, examples, and filter sections with headers. The information is front-loaded with the key facts (25 per page, default sort, native token exclusion). The examples are clear and demonstrate usage patterns. Deduction: the filter section duplicates some schema descriptions (e.g., transferValueUsd, transferOriginCategories), and the examples section is extensive, which could be trimmed. However, the structure makes it scannable.

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

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

For a read-only, paginated list tool with an output schema, the description covers: what it returns (columns with mapping to response fields), how to paginate (per page), sorting, all filter types with examples, and the native token limitation. It doesn't explicitly state the maximum page size or how to request additional pages (beyond 'per page'), but the page parameter is in the schema. It also doesn't explain the output schema's format (e.g., whether there's a 'data' wrapper), but the columns section implies this. Given the output schema exists and the annotations cover safety, this is strong. Minor gap: no explicit statement on how to combine filters or whether multiple filters are additive, but the examples imply this.

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% for the top-level request parameter, but the nested schema has descriptions for several properties (orderBy, dateRange, transferValueUsd, etc.). The description adds significant meaning: it lists all filters with examples, clarifies the transferOriginCategories enum values and their combinations, explains the transferValueUsd range format with concrete examples, and shows full JSON examples. It also explains the meaning of 'Smart Money' and the USD valuation nuance. This compensates well for the low schema coverage. Deduction: the schema already describes dateRange clamping, but the description repeats it – minor 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 tool retrieves token transfers (25 per page) for a specific token with configurable sorting. It explicitly excludes native tokens, which is a key distinction. Among siblings, this is distinct from token_dex_trades (which filters by DEX), token_flows (aggregated flows), and token_who_bought_sold (specific wallet patterns). The description defines the resource (token transfers) and the scope (per token, per page, sortable).

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 filters: use fromAddress/toAddress for specific wallet transfers, transferOriginCategories to control transfer types, onlySmartTradersAndFunds for smart money, and transferValueUsd for USD thresholds. It also notes when to use alternatives (e.g., for native tokens, this tool does not apply). While it doesn't explicitly name sibling tools for when-not-to-use, the filter guidance is actionable and comprehensive. The notes section gives clear use-case-specific direction.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context beyond that: DEX-only scope, aggregation behavior, markdown output, empty-string behavior when no data exists, net buyer/seller semantics for buy_or_sell, and time-range aggregation. No contradiction exists between the description and 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 well-structured with clear sections for returns, columns, sorting, and notes, making it easy for an agent to scan. The column list is lengthy but earns its place because the output format matters for downstream parsing. It is slightly redundant given an output schema exists, but not excessively bloated.

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

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

For a read-only DEX analysis tool, the description covers the core decision context, return shape, sorting intent, and net buyer/seller semantics. The main gaps are the missing optional parameter guidance and the misleading sorting field names, though the input schema partially compensates for those. Overall it is complete enough for an agent to use the tool successfully most of the time.

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

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

With schema description coverage reported at 0%, the description carries the burden of explaining parameters, but it only partially does so. It usefully clarifies buy_or_sell and time-range semantics, but omits several parameters such as chain, tokenAddress, include_labels, page, min_trade_volume_usd, and order_by_direction. More seriously, the sorting guidance mentions bought_volume_usd/sold_volume_usd, which do not match the orderBy enum values (bought_token_volume/sold_token_volume) and conflicts with the schema note that USD volume fields are disabled.

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

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

The description opens with a specific verb and resource: 'Get TOTAL amount of tokens bought/sold by address for a token on DEX ONLY.' It clearly defines this as an aggregated per-trader view rather than a raw transaction log, which distinguishes it from sibling trade/list tools. The title 'Finding recent traders' reinforces the intended use case without creating ambiguity.

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 it: to find out who is buying or selling a token and to infer whether they are liquidating profits or accumulating more. It also constrains the tool to DEX-only data. It does not name sibling alternatives or explicitly state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful detail that token transfers are included in the returned details, but it does not disclose any additional behavioral traits such as missing transaction handling or chain-scoping effects.

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

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

The description is a single, front-loaded sentence with no filler. It earns its place but is slightly too sparse to fully compensate for missing usage and parameter context.

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

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

An output schema exists, so return-value details are less necessary, but the description still lacks when-to-use guidance and parameter semantics. For a tool with dozens of siblings and an undocumented chain parameter, this is not complete enough for reliable selection and invocation.

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

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

Schema description coverage is 0%, so the description should compensate, but it does not explain what transaction_hash or chain mean or how they affect results. 'transaction_hash' is somewhat self-explanatory, and 'chain' has a default of 'all', but the description gives no parameter-level guidance.

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

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

The description uses a clear verb ('Get') and names the resource ('transaction details') with a specific scope ('comprehensive ... including token transfers'). It is distinguishable from address- and token-focused siblings, but it does not explicitly mention lookup by transaction hash, which leaves slight ambiguity versus address_transactions.

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

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

No guidance is given about when to use this tool instead of alternatives such as address_transactions, token_transfers, or prediction_market_lookup. There is no stated context, prerequisite, or exclusion, so an agent must infer when this is the right 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: on 'hyperliquid', tokenAddress must be a perp symbol, not a contract address, and every other chain expects a contract address. No contradiction with annotations.

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

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

The description is compact and front-loaded: purpose appears in the first sentence, followed by a clear special-case rule for chain handling. Every sentence earns its place without unnecessary detail.

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 the input schema includes detailed nested descriptions, the description is nearly complete. It could be stronger about showRealized behavior and how dateRange can accept tokens or dates, but those are already covered in the schema, so no critical calling information is missing.

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?