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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that data is re-crawled periodically ('a few times a day, not real-time') and that results include 'our own uptime/probe data', which tells the user the data is probed and not live. It does not mention authentication, rate limits, or error behavior, but for a read-only search tool these are minor gaps. The description adds meaningful context beyond the raw schema.

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 three sentences: the first states the purpose with the primary scope and a helpful parenthetical about the stats tool, the second lists return fields, and the third gives the freshness caveat. Each sentence adds value and the most important information (purpose) is front-loaded. It is not overly verbose, though the third sentence could be merged with the first, giving it a slightly loose structure.

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, return values are likely defined there, so the description's listing of return fields is a bonus. However, the description does not explain how to use the search parameters (e.g., what q stands for, how alive or max_price_usd filter results), and with 0% schema coverage, that information is missing. The tool is moderately complex (7 optional parameters), so the description should offer at least minimal guidance on parameter usage to be fully 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 0%, so the description must compensate by explaining the parameters. It fails to do so: it mentions 'network' and 'USD price' only in the context of return fields, not as filter criteria. The parameters (q, alive, limit, offset, source, network, max_price_usd) are left entirely to inference from their names. While the names are somewhat self-explanatory, the description does not add meaning to them, which is a significant gap given zero schema coverage.

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 a specific verb ('Search') and a well-defined resource ('a health-probed directory of live x402 pay-per-call HTTP endpoints'), and it lists the return fields (id, resource URL, method, network, USD price, etc.). It also differentiates itself from sibling x402_index_stats by noting that tool gives the count, so an agent can distinguish this search from the stats tool.

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 when to use this tool (to search for endpoints) and explicitly mentions x402_index_stats as an alternative for count, which gives a cue for when not to use it. However, it does not name other siblings like x402_probe or x402_service, nor does it state explicit conditions for when to prefer this over them. The 'not real-time' caveat hints that real-time data is out of scope, but more direct exclusions would improve clarity.

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