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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond that: it is a live snapshot, not_found has a defined meaning, and verbose=true includes the raw upstream payload. These details help the agent understand observable behavior 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?

The description is compact and front-loads the core purpose before listing supported chains and behavioral notes. Each sentence contributes useful information, though the chain-alias enumeration is duplicated in the schema and makes the description slightly dense.

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

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

Given that an output schema exists, the description does not need to explain return values. It covers supported chains, aliases, required pair address, not_found semantics, and the verbose flag, which is sufficient for correct invocation of a read-only snapshot tool. It could be more complete by naming sibling distinctions, but nothing essential for calling this tool 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%, with all three parameters already described in the input schema. The description mostly repeats the chain aliases and verbose behavior rather than adding substantial new parameter-level meaning; the only slight addition is the not_found error semantics, which is more about output behavior than parameter 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 the tool returns a live snapshot of one DexScreener pair and enumerates the fields included (price, liquidity, FDV, market cap, 24h volume, txns, price change windows, links, boosts). It identifies the resource and verb specifically, but it does not explicitly contrast itself with sibling tools like dex_search or dex_token_pairs, so it stops short of full 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?

The description tells the caller what inputs are needed (chain plus pair address), which chains/aliases are supported, and what not_found means. It does not explicitly state when to use this tool versus alternatives such as dex_search or jupiter_prices, so usage guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows it's safe and non-destructive. The description adds context about ticker ambiguity and the need for address confirmation, which is useful for correct usage, but it doesn't disclose other behaviors like error handling or rate limits. Given the annotation coverage, 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?

The description is a single, dense paragraph that front-loads the primary purpose and includes critical usage guidance. It is slightly long but every sentence contributes useful information, and it avoids redundancy.

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

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

Given the presence of an output schema and rich annotations, the description covers what the tool returns, parameter semantics, and important usage caveats. It lacks explicit mention of error cases or rate limits, but those are not critical for invocation correctness given the safety hints.

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 each parameter has a description (query type, limit range, verbose behavior). The description adds value by noting the default limit and the purpose of verbose, but it doesn't elaborate beyond what schema already provides. Baseline 3 is correct.

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 dexscreener by multiple query types and returns candidate pairs with specific fields. It distinguishes itself by mentioning the relevance ordering, which is unique among siblings, and the explicit note about ticker ambiguity prevents misuse.

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 advises confirming identity by contract address using dex_token_pairs/dex_pair before any safety check, which is crucial when to use complementary tools. It also specifies the limit range and default, and the verbose flag behavior, 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?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: results are sorted by liquidity descending, an empty list means the token is not indexed on that chain, and verbose=true exposes the raw upstream payload. 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: action, scope, sort order, output fields, chain support, limits, and edge-case behavior each get one clause. There is no filler or redundant content.

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

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

The tool is simple and well-covered by the input schema and output schema. The description supplies the missing runtime context: supported chains, default/max limit, empty-list interpretation, and verbose behavior. An agent has everything needed 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 coverage is 100%, so the baseline is 3. The description restates chain aliases and limit/verbose behavior, but adds little beyond what the parameter descriptions already provide. It does not deepen understanding of token_address formats or how parameters interact.

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 action and resource: 'list dexscreener pools for one token contract on one chain,' and names the returned fields. It is clearly scoped to token-level pool listing, which distinguishes it from sibling tools like dex_search and dex_pair.

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 invocation context: one chain, one token contract, sorted by liquidity, with a meaningful empty-list behavior. It does not explicitly name sibling alternatives or state when not to use the tool, but the context is unambiguous enough for correct selection.

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, and destructiveHint false, covering safety. The description adds behavioral context beyond these: it describes the simulation nature (not a real transaction), the meaning of empty results, and the effect of verbose=true (adds top holders and raw payload). This fully discloses behavior without contradicting 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 information-dense but each sentence contributes value. It front-loads the core purpose, then provides chain details, a routing note, and verbose behavior. It is slightly redundant (aliases are repeated in schema), but remains well-structured and avoids fluff.

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

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

The tool is complex (multiple chains, external service, optional verbose), and the description covers all necessary aspects: purpose, supported inputs, routing to alternatives, edge-case behavior (no pair), and output enhancement. An output schema exists, so return structure is covered elsewhere. 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 100%, so parameters are already documented. The description adds extra semantic value by explaining that verbose=true includes top holders with supply percentages and raw payload, and by reiterating the chain aliases in a readable format. It goes beyond the schema's minimal descriptions, though some duplication exists.

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 simulates a buy and sell of an EVM token via honeypot.is and enumerates the specific metrics it reports (is_honeypot, taxes, gas, risk flags, etc.). It names the exact resource and action, and differentiates from sibling rugcheck_report by explicitly directing Solana usage there.

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 states supported chains (ethereum, bsc, base) with aliases and instructs to use rugcheck_report for Solana, providing clear routing. It also clarifies that a null result means no simulated pair exists, which guides interpretation of the tool's output.

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 annotations, the description discloses useful edge-case behavior: unknown mints come back with found=false, a 50-mint limit exists, and verbose=true adds the raw payload. These details help the agent predict 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?

The description is two dense sentences with no filler. Purpose, limits, edge behavior, and usage context are all front-loaded economically.

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 an output schema and complete parameter documentation, the description covers purpose, source, limits, edge cases, and verbose behavior. It could be slightly stronger with an explicit when-not-to-use note, but 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?

Schema description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says: up to 50 mint addresses and verbose adding raw payload. It adds no genuinely new 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 the tool returns USD prices for up to 50 Solana mints from Jupiter, with liquidity, 24h change, decimals, and found=false for unknown mints. It identifies itself as a price source alongside dexscreener, but does not explicitly contrast with sibling tools like dex_search or dex_token_pairs.

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 use context: 'use as a second price source next to dexscreener.' However, it does not state when not to use this tool or name specific sibling alternatives, so it stops short of full when/when-not 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 carry readOnly/openWorld/idempotent/non-destructive safety context. The description adds useful behavioral detail beyond those annotations, such as what default vs verbose mode returns, including the capped raw payload. 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 concise sentences, front-loaded with the core action and output summary, then enriched with verbose-mode details and platform constraint. Every sentence earns its place without repeating structured fields.

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 an output schema, full parameter coverage, and strong annotations, the description covers purpose, mode behavior, result contents, and platform routing. Nothing essential is missing for correct tool selection and invocation.

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

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

Schema coverage is 100% so the baseline is 3. The description adds value beyond the schema by enumerating verbose-mode fields like mint/freeze authority, top holders with insider flags, metadata mutability, and Jupiter verification that the schema does not list.

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 action and resource: "fetch rugcheck.xyz's risk report for a solana mint" and enumerates the report's fields. It also explicitly distinguishes itself from honeypot_check by stating "solana only."

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

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

Gives clear routing guidance: use for Solana mint risk reports, use verbose=true for richer detail, and use honeypot_check for EVM tokens. This directly tells an agent when to use this tool vs alternatives.

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