Crypto Bot Honesty Audit (x402 paid)

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does clarify that the tool takes one file and returns findings for specific bug categories, which implies a read-only static analysis. It does not explicitly state side-effect freedom, error behavior, or limitations such as single-file scope beyond the first sentence.

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 compact sentence that front-loads the required input and then lists the distinct finding categories. Every clause contributes information; there is no filler or repetition.

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 no output schema and no annotations, the description should explain the return shape and usage context more fully. It lists finding categories but not their structure/severity, does not explain the optional filename parameter, and gives no guidance about the somewhat ambiguous sibling demo_audit.

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 only 50%: only 'code' has a description, and the description largely restates it ('one JS/TS source file (string)' vs 'one JS/TS file'). The optional 'filename' parameter is not explained in the description or schema, leaving its role unclear. Thus the description fails to compensate for the schema coverage gap.

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

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

The description states a specific verb and resource: audit crypto-bot source code, and enumerates five concrete bug classes it detects. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling tool demo_audit, which may overlap in 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 usage: pass one JS/TS source file and receive audit findings. However, it gives no explicit when-to-use guidance or reasons to choose this tool over demo_audit or the other siblings, so the agent must 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?

With no annotations, the description carries the burden. It usefully discloses that no payment is required and that the run uses a fixed built-in sample, which reduces risk of expecting a paid or user-supplied audit. However, it does not state limitations beyond the fixed sample, such as whether this is read-only, time-limited, or what exactly 'findings' covers.

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 tightly packed sentences state the action, resource, outcome, and cost behavior. No filler, and the most important qualifiers ('Free', 'no x402 payment') are prominent.

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 no-argument demo tool, this is nearly complete: it identifies what runs, what input is used, and that findings are returned. The lack of an output schema is mitigated by 'returns the findings' and the demo's low stakes, though a bit more detail on the findings format would make it fully 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 schema has zero parameters and 100% coverage, so the description has no parameter burden. The 'built-in sample' phrase reinforces that no user input is needed, which is useful 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?

Description states a specific verb ('Runs the scanner'), a concrete resource ('a small built-in bad-bot sample'), and an outcome ('returns the findings'). The title emphasizes 'Free demo ... fixed sample, no payment', which clearly distinguishes this from the sibling audit_bot_code.

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 and title give clear context for when to use it: it is a free no-payment demo on a fixed sample. It does not explicitly name the alternative audit_bot_code or state when not to use it, but the 'no x402 payment' and 'built-in sample' cues strongly imply trial-before-paid use.

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

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

No annotations are provided, so the description carries the full burden. It does well by disclosing the paid nature ('0.01 USDC via x402'), the pair-selection behavior ('Highest-liquidity pair'), and that data is live. It doesn't cover failure modes or rate limits, but for a single-parameter quote tool this is substantial non-obvious information.

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

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

Two short clauses plus a fragment, with zero filler. The core output fields are front-loaded, followed by chain scope, pair selection, and per-call cost. 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?

With no output schema, the description lists the expected return fields (spot price, liquidity, FDV, market cap, 24h volume) and explains the pair-selection logic, giving an agent a solid picture of what to expect. It does not describe error conditions or exact response nesting, but for a one-parameter, no-output-schema quote tool 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%: the 'address' parameter is fully documented with EVM and Solana format details. The description reiterates 'by contract address — EVM (Base/etc.) or Solana mint' but adds no new format or semantic details beyond the schema, so baseline 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 and resource: 'Live DEX spot price ... for any token by contract address' and enumerates exact outputs (price, liquidity, FDV, market cap, 24h volume). It also states the supported chains (EVM Base, Solana), which clearly separates it from sibling tools like audit_bot_code (audits) and search_tokens (discovery). The title reinforces the same scope.

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

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

The context is concrete: the tool is for tokens when you already have a contract address, on EVM (Base/etc.) or Solana, and need market data. It lacks an explicit 'don't use when...' or mention of search_tokens for address discovery, so exclusions are not spelled out, but the input requirement and chain scope give an agent enough to choose this tool appropriately.

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

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

With no annotations provided, the description carries the full disclosure burden. It does add value beyond the schema by revealing the cost (0.01 USDC via x402), the cross-chain scope, and the exact return fields. However, it omits edge-case behavior such as what happens when no matches are found, and it does not explicitly state this is a non-destructive read operation — leaving the agent to infer safety from the word 'search'.

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 efficient sentences with no wasted words. The purpose and return data are front-loaded in the first sentence, and the cost disclosure in the second adds specific value beyond the title's generic '(paid)' marker. 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 simple two-parameter search tool with no output schema, the description covers the core contract: search criteria, return fields, and cost. It is reasonably complete, but the 'limit' parameter semantics are entirely unaddressed in both schema and description, and there is no guidance on edge cases like zero matches or pagination behavior. Missing those leaves the agent partially uninformed when 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 coverage is only 50%: the 'query' parameter is documented in the schema ('token name or symbol, e.g. pepe or coinbase'), matching the description's phrasing. The 'limit' parameter has no schema description and the tool description does not compensate — it never explains that limit controls how many matched pairs are returned, though 'highest-liquidity matched pairs' loosely implies result selection. Partial compensation but a clear gap remains for the limit parameter.

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

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

The description states a specific verb and resource: 'Search crypto tokens by name or symbol' and specifies the return data (highest-liquidity matched pairs with price, liquidity, FDV and 24h volume across chains). This clearly distinguishes the search/match behavior from sibling get_token_price, which likely does a direct single-token lookup. The purpose is clear and specific, though it doesn't explicitly contrast itself against get_token_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?

The use case is only implied — search tokens by name/symbol — but there is no explicit statement of when to use this tool versus the sibling get_token_price, nor any exclusions. The payment disclosure ('Cheap per-call market lookup') hints at a cost consideration but never tells the agent how to choose between search_tokens and a direct price lookup. No when-not-to-use guidance is present.

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