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

Annotations only cover readOnlyHint/openWorldHint, and the description adds substantial behavior beyond them: the tool is paid ($0.01 USDC via x402), the data provenance (nohumans.directory probes, verified/unverified), the license, and critically that a call returns payment requirements rather than data. This is exactly the extra context an agent needs before invoking a metered tool.

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?

Front-loads the cost, then the resource, returned fields, filters, and call behavior in three dense sentences with no filler. Every clause earns its place and the most decision-relevant fact (the price) leads.

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 does explain the return shape (HTTP request + x402 payment requirements) and the payment model, so the agent knows what a call yields. The only gap is per-filter format detail, but overall it is complete enough for a paid search 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 0%, so the description must carry parameter meaning. It enumerates all six filters (q, category, chain, max_price, status=verified, limit<=100) which maps to every property, but gives no per-parameter format or unit detail (e.g., how max_price is expressed, what q matches against), so compensation is only partial.

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+resource: search ~8,900 live x402 pay-per-call APIs, and enumerates the returned fields (name, endpoint URL, category, price, chains, status, score). It is clearly distinguishable from a generic search, though it never names the adjacent sibling dump_x402_services, leaving a small ambiguity the agent must resolve from the name alone.

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?

Explains the calling model well: invoking it 'returns the exact HTTP request and x402 payment requirements; pay with any x402 client to get the data,' so the agent understands this is a two-step paid flow. It gives clear context for when to use it, but states no exclusions or explicit alternatives among the many sibling catalog tools.

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