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

With no annotations, the description carries the full burden and does so richly: it discloses the 5-free-lookups-per-UTC-day quota keyed to client=vc-mcp, the HTTP 402 x402 payment response, that the tool reports but does not pay, that payment never changes results or sort order, and that seller-broken services are returned under facts_only unsorted. These are exactly the behavioral facts an agent needs and none are in structured fields.

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 question-first opening is well front-loaded and the ranking rule follows immediately. The text is dense but mostly earns its place, though the final 'Payment never changes results, sort order or listings' sentence partially restates the earlier 'reports but does not pay' point.

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 6-parameter tool with no output schema and no annotations, the description covers the return shape (per-service receipts with time, tx, Basescan link, charged, delivered, pass/fail, last check time, stale flag) and the facts_only exception, plus the payment/quota model. An agent has what it needs to call and interpret this tool 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 description coverage is 100% and the schema already documents n (paid receipts per service, default 5), task, limit, payer, endpoint, and max_price_usd. The description echoes the role of n and the price cap but adds little syntax or meaning beyond what the schema already states, so the baseline 3 applies.

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 concrete resource (services in the catalog) and a concrete verb/query (lookup matching a task at or under max_price_usd, ranked by known-answer pass rate then price). It is far more specific than a tautology, but it never names the siblings get_service or search_catalog, so the agent must infer the boundary rather than being told it.

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 opening question ('Is an x402 endpoint reliable for a task at a price?') frames exactly the situation this tool is for, and the free-quota/402 text tells the agent what happens under load. However, there is no explicit statement of when to prefer search_catalog or get_service instead, so routing remains partly inferential.

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