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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read-only tool. The description adds useful context about data sources (public Base RPC + CDP catalog) and recomputability, which goes slightly beyond annotations. However, it does not disclose output format, pagination, or edge-case behavior such as invalid inputs or what happens when both parameters are supplied.

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 verbose and promotional, starting with a marketing claim ('no other seller offers') rather than a direct functional statement. It uses heavy formatting (CAPS, arrows, parentheticals) that could be streamlined. While all sentences contain some information, the overall structure is run-on and not front-loaded for quick 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 absence of an output schema, the description does a good job enumerating the return values for both modes, covering key metrics and data sources. However, it is ambiguous about parameter combination rules (the 'or' implies exclusivity but the schema allows both), and it lacks clarity on output format or error handling. The description is fairly complete but not fully polished given the tool's complexity.

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

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

The input schema only gives brief descriptions for 'wallet' and 'resource' (100% coverage). The tool description significantly enriches these by detailing what each parameter triggers: wallet yields behavioral attributes (catalog-walker vs real-customer verdict, USDC spend, distinct sellers), while resource yields a discoverability audit (CDP offset, freshness, crawl details). It does not clarify whether passing both is allowed or what happens if neither is provided, a minor gap.

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

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

The description clearly states the tool provides seller intelligence for x402 Bazaar with two modes: buyer behavior analysis (given a wallet) and discoverability audit (given a resource/domain). It uses specific verbs (pass, get, audit) and distinguishes itself by claiming 'no other seller offers' this, but the purpose is somewhat buried in promotional language and is less crisp than a direct 'retrieve' statement.

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 contexts (seller wanting buyer analytics or discoverability audit) but does not explicitly state when to use this tool versus any alternatives. It never names sibling tools or provides exclusions like 'use X instead when ...'. The claim 'no other seller offers' is more marketing than a usage guideline.

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