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

With no annotations, the description carries the full burden and does substantial work: it discloses that verified-402 means one unauthenticated request received a real HTTP 402 challenge, that no payment was ever made, and that agent-refusing stores surface as findings rather than options. Remaining gaps are pagination, result ordering, and 'Index only' freshness, which are not spelled out.

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?

Dense but front-loaded: the resource scope comes first, then the item shape, then the verification semantics, then the exclusion rule. The field-list sentence is long and jargon-heavy but earns its place as a substitute for the missing output schema.

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 4-param, no-annotation, no-output-schema discovery tool, the description covers what an agent needs: what is searched, what comes back (agent_native fields), what verified means, and how refused stores are handled. The undefined 'limit' and absence of paging behaviour are the only material omissions.

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 25%, so the description must compensate — and it does for the critical enum: it defines verified-402 vs claimed, which directly governs rail_status, and enumerates the category space. It also explains the agent_native fields returned per item. Only 'limit' is left undefined in both schema and description.

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 opens with a precise resource definition — agent-payable stores without browser checkout — and enumerates the categories (L402/x402 APIs, VPN, eSIM, VPS, gift cards, nostr). This clearly separates it from generic siblings like search_merchants or find_offers. It lacks an explicit verb and never names a sibling, so it falls short of a 5.

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?

Use is implied by the domain framing and the closing 'Index only', which signals a curated-index lookup rather than live crawling. However, there is no explicit when-to-use or when-not-to-use guidance, and no pointer to find_offers / find_alternatives / search_merchants as alternatives.

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