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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds meaningful behavioral context beyond that: 'Read-only and keyless', AND-combined filters, pagination via next_cursor, default/max limit, and sort aliases. It also discloses the response wrapper, which the annotations do not cover.

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 dense but well-structured: purpose, safety, sibling differentiation, examples, filter semantics, then parameter summary. No filler or redundant restatement of the schema; every sentence contributes actionable 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?

For a 19-parameter tool with an output schema and strong annotations, the description covers purpose, usage alternatives, response shape, filter combination semantics, pagination, defaults, and aliases. It does not need to explain return values because the output schema exists, and it leaves no major contextual 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 100%, so the baseline is 3. The description adds value by grouping filters, stating they are AND-combined, noting network is required, and summarizing defaults/aliases (limit default 50 max 100, sort_by default volume_usd_24h, sort_dir default desc). It also provides real-world usage examples that clarify parameter intent, though the schema already documents each parameter individually.

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+scope: 'Get tokens on one network matching numeric thresholds'. It also names the response shape ('returned under results with has_next_page and next_cursor') and explicitly distinguishes itself from the sibling tool getTopTokens, making its 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?

The description gives explicit when-to-use guidance: 'Choose this over getTopTokens when the user gives numeric constraints or a time window', followed by concrete example queries. It also points to an alternative for other price-change windows ('for 6h, 1h or 5m use getNetworkPoolsFilter'), which is strong usage differentiation.

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, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds 'static', 'keyless', and 'Read it once' which reinforce these traits without contradiction. It also clarifies that it returns docs, not live data, which is additional context beyond annotations. Slight deduction because it doesn't elaborate on output format or pagination, but the output schema presumably covers that.

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 ~120 words, longer than average, but every clause earns its place: purpose, contents, usage timing, trigger questions, disambiguation from siblings, and parameter note. It's front-loaded with the core purpose and then branches into usage. Slight redundancy with 'short rationale' but overall well-structured.

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

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

For a tool with a simple read-only purpose, a single parameter, and an output schema (presumably describing the guide structure), the description fully covers what the agent needs: what it returns, when to call it, what not to expect, and how to differentiate from peers. No gaps are evident.

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 provides a full description of the single `rationale` parameter (with format, length, examples, privacy note). Schema coverage is 100%, so the description doesn't need to add parameter details. The description confirms 'Takes no parameters beyond a short rationale,' which adds clarity that no other parameters exist. This is above baseline because it explicitly reiterates the parameter surface.

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

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

The description clearly defines the tool as returning a static onboarding guide with specific contents (workflows, network name synonyms, call sequences, pitfalls). It explicitly contrasts with sibling tools: 'for the actual list of network slugs use getNetworks, and for coverage totals use getStats.' This is a specific verb+resource with clear scope and sibling differentiation.

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?

Usage guidance is explicit and actionable: 'Read it once at the start of a session before your first query, or when asked...' It lists trigger phrases and also states what the tool does NOT do ('returns onboarding docs, not live market data') and directs to alternatives. This is textbook 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?

Beyond the readOnly/idempotent annotations, the description discloses key behavioral facts: the old endpoint was removed, the proxy endpoint is used, results live under 'results', pagination uses has_next_page/next_cursor, the 24h volume field is volume_usd_24h, and page numbers are deprecated. The empty-results pitfall for dex_name display strings is especially valuable behavioral context.

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

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

The description is dense and front-loaded, opening with a clear purpose before moving into migration, pagination, usage, and parameter semantics. It is long, but most content earns its place. It loses one point because several parameter-level details are duplicated almost verbatim in the input schema, so the description is somewhat heavier than strictly necessary.

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

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

For a tool with 10 parameters, aliases, pagination, and a migrated endpoint, this description is nearly complete: it covers output placement, cursor pagination, field-name conventions, aliases, prerequisites, and failure modes. The presence of a rich output schema means return-value details do not need to be repeated, and the description fills all significant gaps.

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

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

Even though schema coverage is effectively 100%, the description adds semantic value beyond the raw properties: it clarifies that dex must be the id from getNetworkDexes, not the display name; it explains cursor usage; it distinguishes preferred sort_by/sort_dir names from legacy aliases; and it explains REST-layer parameter names. This materially improves the agent's chance of making a correct call.

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 gives a specific verb, resource, and scope: 'Get the pools belonging to one specific DEX on one network' with a concrete example of Uniswap v3 pools on ethereum. It also explicitly distinguishes the tool from getNetworkPools, so the purpose is unambiguous relative to its 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 clear use cases ('show me Raydium pools', 'top pairs on PancakeSwap', 'liquidity on Orca'), a prerequisite chain (getNetworkDexes or search first), and an explicit exclusions: do not pass the human-readable dex_name. It also names getNetworkPools as the broader alternative, giving the agent concrete 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 indicate safe/read-only/idempotent behavior; the description adds that it reads no market data and checks key/plan. It doesn't contradict annotations, though it could mention potential error cases, but given annotation coverage this is solid.

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 concise sentences convey purpose, usage, and a key constraint (no args). No redundant or verbose content.

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

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

The description covers purpose, when to use, and the nature of the output (reports key status and plan). Given the simplicity and lack of an output schema, this is sufficient for a diagnostic tool.

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

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

The input schema is empty (0 parameters), and the description explicitly confirms 'Takes no arguments,' eliminating any ambiguity about invocation.

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 (report API key sending status and plan) and distinguishes it from sibling data-fetching tools by focusing on key health, not market data.

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

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

The description explicitly tells when to use it (when rate-limited, refused, or user asks about key) and implies its distinct role vs. data tools, providing unambiguous usage 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that it's keyless, returns paginated results under 'dexes', and explains the sorting and pagination parameters. It also discloses legacy parameter aliases (sort/order_by) and clarifies that they are not deprecated at the REST layer.

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

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

The description is concise and well-structured: first sentence states purpose and output, followed by key usage info, then clear parameter details. Every sentence adds value without redundancy. It front-loads critical info (read-only, keyless) and uses examples to clarify use.

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

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

Given the tool has 8 parameters (with many optional and aliases), an existing output schema, and annotations covering safety, the description is complete. It specifies the network prerequisite, pagination details, sorting options, output structure, and use cases. No gaps are apparent.

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

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

Schema coverage is 100%, but the description adds value by explaining the legacy aliases (order_by/sort), the valid values for sort_by ('pool'), and the default/max/1-indexed behavior for pagination. The required 'rationale' parameter is not mentioned in the description but is in the schema, so the description doesn't fully compensate for all parameters. Thus, slightly above baseline.

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

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

The description explicitly states it lists DEXes on a single network with examples (Uniswap on ethereum, Raydium on solana), and specifies the output fields 'dexes' and 'page_info'. It distinguishes from siblings by noting this feeds into getDexPools and is scoped to one network, contrasting with getNetworks and getDexPools.

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 use cases ('which DEXes are on Base?', 'does Solana have Orca?') and explicitly states the prerequisite: 'call getNetworks first for the slug'. It also implies when not to use (for pools, use getDexPools) and specifies the scope (single network).

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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond this: the tool is 'keyless', returns results under 'results' with has_next_page and next_cursor, and defaults to 24h volume ranking. 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 compact and front-loaded: purpose, response shape, key property, usage examples, alternatives, then parameter essentials. Every sentence contributes actionable information without unnecessary repetition or padding.

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

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

Given the tool's moderate complexity, rich annotations, full schema coverage, and presence of an output schema, the description is complete: it covers scope, use cases, exclusions, defaults, pagination, aliases, and keyless access. No critical selection or invocation context 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%, and the description adds practical guidance about aliases, preferred names, defaults, and pagination cursor usage. It omits the required 'rationale' parameter from its summary, but the schema documents that fully; overall the description adds meaningful semantic value beyond the raw schema.

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

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

The description clearly states the tool gets 'top liquidity pools across a whole network', specifies default ranking by 24h volume, and identifies itself as 'the primary chain-wide pool discovery tool'. It is sharply distinguished from siblings like getDexPools and getNetworkPoolsFilter.

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 usage guidance is provided with concrete natural-language examples ('biggest pools on ethereum', 'top trading pairs on Base', 'most active pools on Solana'). It also names alternatives: narrow to one exchange with getDexPools, or use filters with getNetworkPoolsFilter.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by stating 'keyless' (no auth requirement), that filters are AND-combined, documenting defaults (limit 50/max 100, sort_by/sort_dir defaults), and noting aliases. 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 compact sentences plus a filter enumeration. Front-loaded with purpose and the key sibling differentiator. While somewhat dense given 25 parameters, every clause earns its place: purpose, read-only/keyless, when-to-use with examples, filter list, required/default/alias info. No filler, but a bit heavy 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 25-parameter tool with an output schema and rich annotations, the description is thoroughly complete. It covers purpose, sibling differentiation, examples, read-only/keyless status, ALL available filters, required network param, pagination (cursor/limit), and sort defaults. The output schema handles return values, so the brief mention of 'results' with has_next_page/next_cursor 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?

Schema coverage is 100% with rich per-parameter descriptions, so baseline is 3. The description adds genuine cross-parameter semantics not in the schema: the AND-combination of filters, which params are required, default values for limit/sort_by/sort_dir, and the alias relationships (sort_by/order_by, sort_dir/sort). This provides real value beyond the structured 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?

Uses a specific verb+resource: 'Get pools on one network filtered by numeric thresholds'. Explicitly distinguishes itself from sibling getNetworkPools by naming it and describing the differentiator (numeric constraints/time windows). The three concrete example queries reinforce the exact scope.

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

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

Gives an explicit when-to-use directive: 'Choose this over getNetworkPools when the user gives numeric constraints or a time window.' Provides three concrete user-query examples ('pools over $1M liquidity on Base', 'pools created in the last 24h', 'high-volume low-liquidity pairs') that map to filters. Clearly implies the alternative for non-numeric 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 already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds 'Read-only and keyless', explains no pagination/sorting, and describes the rationale parameter's purpose. No contradictions.

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

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

Description is well-structured, front-loaded with main purpose, and every sentence provides essential information. No fluff or redundancy.

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

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

For a simple list tool with an output schema, the description fully covers return data (full array, no pagination), usage scenarios, and parameter semantics. No 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 coverage is 100% with description for rationale parameter. Description adds extra guidance on rationale: required, 1-2 sentences, logged for improvement, no PII/secrets, and references server instructions. This adds meaningful context beyond schema.

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

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

Clearly states it lists every blockchain network DexPaprika indexes with specific fields (slug, 24h volume, etc.). Distinguishes from siblings like getStats and getCapabilities by noting it provides network slugs needed by other 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 says when to use: to get network slugs, to check chain support, to find slug for Polygon. Also tells when not to use: for platform-wide totals, use getStats instead. Provides clear alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it is keyless, returns live values only, and returns a single object not a list. No contradictions.

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

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

Description is fairly concise with a clear first sentence, then usage guidelines and parameter details. Could be slightly more streamlined, but each sentence serves a purpose.

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

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

Given 4 parameters and output schema, description covers purpose, usage, parameter semantics, and behavioral traits thoroughly. References sibling tools and explains when to use alternatives.

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 baseline 3. Description adds value by explaining the inversed parameter flips token1/token0 ratio, giving a pool_address example, and emphasizing network is a required slug.

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

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

Description clearly states the tool retrieves a full current snapshot for one pool by address, listing specific data items (tokens, price, liquidity, etc.). It explicitly distinguishes from siblings like getPoolOHLCV and getPoolTransactions.

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 (after search or getNetworkPools, for price/TVL queries) and when not to (for historical candles use getPoolOHLCV, for raw swap feed use getPoolTransactions). 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'Read-only and keyless' and notes that end is capped to 1 year after start, providing useful behavioral context beyond 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?

Description is a single long sentence but front-loaded with purpose and usage. While comprehensive, it could be more concise with bullet points. No superfluous 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?

With 8 parameters, 4 required, and an output schema present, the description covers all necessary aspects: purpose, usage, parameter details, and sibling differentiation. Leaves no gaps for an agent.

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

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

Schema coverage is 100%, but description adds extra meaning: accepted formats for start (Unix timestamp, RFC3339, yyyy-mm-dd), cap on end, interval granularities, and default values. Significantly enriches 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?

Explicitly states it retrieves historical OHLCV candles for one pool over a time range, with specific verb 'Get' and resource 'OHLCV candles'. Clearly distinguishes from sibling 'getPoolDetails' for current price.

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 usage examples ('price history of this pair', 'hourly chart for the last week') and explicitly names alternative tool ('use getPoolDetails instead').

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds key behaviors: 'keyless', pagination via page/cursor, time filter with 7-day cap, and result structure ('under transactions'). No contradictions.

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

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

Concise yet comprehensive: core action first, then differentiation, use cases, parameter details. Every sentence adds value; no redundancy.

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

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

Given output schema exists (not shown), return values need no further explanation. All parameters are fully covered, behavior and constraints clear. Completes the picture for effective tool invocation.

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

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

Schema coverage is 100%, but the description enriches understanding with defaults, limits, pagination types, and time constraints. It explains response format and parameter relationships 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 pool's recent swap transactions, newest first, and distinguishes itself from related tools like getPoolOHLCV and getPoolDetails.

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

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

Explicitly provides use cases ('recent trades on this pool', 'who swapped in the last hour', 'raw transaction feed') and contrasts with other tools ('not aggregated candles' or summary snapshots).

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds 'Read-only and keyless' which reinforces and slightly extends the annotation-provided behavioral context (auth requirements). No contradictions.

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

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

The description is front-loaded with the main purpose in the first sentence and is composed of 5 concise sentences. Slight redundancy ('Read-only and keyless' standalone) but overall efficient with no wasted words.

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

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

For a simple, read-only tool with an output schema, the description fully covers what the tool returns, common use cases, and exclusions. It is complete given the tool's low complexity and the presence of annotations and output schema.

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

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

Schema description coverage is 100% for the single parameter (rationale), so baseline is 3. The description mentions 'Takes no parameters beyond a short rationale' but adds no additional meaning beyond what the schema's parameter description already provides.

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

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

The description clearly states the tool retrieves platform-wide totals for networks, DEXes, pools, and tokens as a single summary object. It distinguishes itself from siblings like getNetworks and getCapabilities by specifying it returns ecosystem-wide counts, not per-network figures.

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 lists example use cases ('how much data do you cover?', 'how many chains or pools total?') and advises when to use alternatives (getNetworks for per-chain breakdown, getCapabilities for onboarding docs). This provides excellent guidance on when to invoke the tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds 'Read-only and keyless' which reinforces the safety profile and adds the keyless auth detail beyond annotations. Doesn't disclose rate limits but annotations carry the load appropriately.

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?

Every sentence earns its place: main description, usage example, symbol-resolution edge case, and sibling pointer. The final sentence is an info-dense list of both alternatives in a compact form. No fluff, no repetition of schema content.

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

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

Given there's an output schema (return value documented elsewhere), 100% param coverage, and rich annotations, the description is complete. It covers edge cases (symbol-only queries), access model (keyless), and disambiguation from 17 siblings. Nothing important is left unexplained.

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 baseline is 3. The description adds value by explaining the network param is a 'slug', providing a real example for token_address, and adding entity resolution workflow guidance ('call search first') that anticipates a common failure mode not in the schema.

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

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

Specific verb ('Get') + resource ('one token's data and metadata by contract address') + scope ('on one network'). Clearly distinguishes from siblings by explicitly naming getTokenMultiPrices and getTokenPools as alternatives for different needs.

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 ('price and volume for 0x... on Base'), what to do with only a symbol ('call search first to resolve the address'), and explicit alternatives ('use getTokenMultiPrices', 'use getTokenPools'). This is exemplary 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 provide readOnlyHint, openWorldHint, idempotentHint. Description adds keyless operation and partial failure behavior (missing_tokens list), which are beyond annotations, but is slightly redundant on read-only.

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

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

Three punchy sentences plus param summary; no wasted words, front-loaded with key action and constraints.

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 full schema coverage, annotations, and output schema, the description covers behavior (return format, partial failures), usage alternatives, and key constraints, making it fully actionable.

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% (baseline 3). Description adds context that tokens must share the network and that network is a slug, adding value beyond the schema.

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

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

The description clearly states the tool gets current USD prices for up to 10 tokens on the same network in a batched call, distinguishes from getTokenDetails for single-token metadata, and specifies the output structure.

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

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

Explicitly states use cases (portfolio/dashboard snapshot, comparing prices) and when to use alternative (getTokenDetails for one token with full metadata).

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, idempotentHint=true, destructiveHint=false. The description adds useful context: 'Read-only and keyless', 'unknown addresses return empty results, not an error', and 'Extra params such as inversed or paired_token_address are unsupported and error'. This goes beyond annotations by explaining error behavior and keyless access.

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 dense but well-organized: purpose, output structure, usage examples, network-scoping caveat, alternative tool reference, and parameter summary. It's longer than ideal but every sentence adds value. The parameter summary at the end is efficient, though it partially duplicates schema info.

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 (13 params, 4 enums, aliases, unsupported params), the description covers the essential usage patterns, error cases, and alternatives. The output schema exists, so return values are documented. The description could mention pagination behavior more explicitly, but the cursor parameter and next_cursor reference in the description cover it adequately.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The description adds value by summarizing key parameters (network, token_address, limit, cursor, sort_by, sort_dir) and explicitly flagging unsupported parameters (inversed, paired_token_address) that would error. It also clarifies aliases (sort_by/order_by, sort_dir/sort) which the schema also documents, but the description's summary helps the agent quickly understand the parameter landscape.

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 the liquidity pools that contain a specific token on one network' with specific output structure ('returned under results with has_next_page and next_cursor'). It distinguishes from siblings by mentioning network-scoping and pointing to getTokenDetails for price queries.

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

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

Provides explicit usage guidance: 'Use for which pools hold WETH on ethereum? or liquidity venues for 0x...' and 'For the token's own price use getTokenDetails'. Also gives clear when-not-to-use: 'Network-scoped, so run search first if unsure of the network' and notes unknown addresses return empty results.

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?

Expands beyond annotations: notes keyless access, pagination response format, and the critical caveat that sorting by raw price silently falls back to volume. Annotations already cover idempotent/read-only; description adds operational 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?

Concise yet comprehensive: first sentence states purpose, second gives usage guidance, third details parameters. No extraneous text; 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?

Covers all aspects: purpose, parameters, pagination, caveats, and alternative tool. Output schema exists so return format is adequately summarized. No 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?

Despite 100% schema coverage, description adds value: explains aliases (sort->sort_dir, order_by->sort_by), default/max for limit, cursor usage, and the price sorting fallback. Schema alone doesn't provide this context.

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

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

Clearly states the tool retrieves top tokens ranked by various metrics (volume, liquidity, etc.) and gives concrete examples ('top gainers on Solana'). Distinguishes from sibling filterNetworkTokens.

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

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

Explicitly says when to use (top tokens by specific metrics) and when not to (arbitrary numeric filters or time window), directing to filterNetworkTokens. Also mentions read-only and keyless.

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 readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details: 'Read-only and keyless', and explains that no matches return empty arrays not errors. It also clarifies limit is applied client-side.

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 well-organized paragraph that front-loads the main purpose, then covers return, usage context, behavior, and parameter details. No wasted words.

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

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

The description fails to mention the required 'rationale' parameter, which is present in the schema. This is a significant omission for a parameter that must be supplied. Otherwise, the description covers most other aspects adequately.

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

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

Schema coverage is 100% but the description adds examples for query (e.g., '0x...') and explains limit application. This provides practical guidance beyond the schema.

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

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

The description clearly states the tool searches across all networks for tokens, pools, and DEXes, returning three arrays. It distinguishes itself by specifying it is the cross-chain entry point when network is unknown, and advises switching to network-scoped tools once a slug is known.

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

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

The description explicitly provides when to use (when you do not know the network) and when not (once you have a network slug, use network-scoped tools). It also gives concrete search examples like 'find PEPE' and 'which chain is this token on?'.

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