402registry

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. Because there is no output schema, the description's enumeration of the returned JSON sections (quickstart, verdict meanings, packs, check rules, routes) is the only place the payload shape is disclosed, which is genuine added value; it could go further by warning that the full guide is a large single payload.

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?

One front-loaded sentence with a colon list that carries all the content information; zero filler and no repetition of the title or annotations.

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 parameters and no output schema, the description carries the payload description responsibility and does it adequately. The one residual gap is that the agent is not told the response is a large full-guide dump with no filtering option, which matters for context budgeting.

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 tool takes zero parameters, so the schema has nothing to document and the baseline of 4 applies. Nothing in the description is needed to clarify parameter usage.

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 resource (the whole machine guide) and an explicit scope ('whole'), then enumerates the sections returned: quickstart, verdict meanings, packs, check rules, public routes. That is enough for an agent to know exactly what it gets, though it never explicitly contrasts itself with get_pricing, get_service_status, or lookup_site.

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?

Usage is only implied: an agent can infer it should call this to learn verdict semantics, pack behavior, and available routes, since those are named as contents. There is no explicit when-to-use statement, no ordering relative to siblings, and no exclusions.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context the annotations do not: this is a paid endpoint and the response carries the exact x402 v2 payment requirements and the query parameters a subsequent paid request needs, which is the key behavioral fact an agent must know.

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?

A single front-loaded sentence that leads with the resource and then the contents; the 'check (one payment, one check)' parenthetical is slightly cryptic, but there is no filler and the actionable instruction sits at the end where it is easy to catch.

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 must convey what comes back, and it does: product list, prices, required request parameters, and payment requirements. For a zero-parameter read tool this is essentially complete, though it doesn't cover ordering, filtering, or how many products are returned.

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 tool takes zero parameters, so the baseline is 4. The description's mention of 'the query parameters the paid request needs' describes the return payload rather than inputs, and doesn't confuse the no-argument signature.

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 the resource ('every product for sale') and enumerates what comes back with each entry: price, required query parameters, and x402 payment requirements. The verb is implicit (a listing/get rather than an explicit action verb), but the scope is concrete enough to distinguish it from get_docs, get_service_status, and lookup_site.

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?

It gives an explicit trigger — 'Call this before buying' — which tells the agent exactly when this tool is the right one. It doesn't name alternatives or exclusions, but no sibling covers product/pricing discovery, so nothing is left ambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is covered elsewhere. The description adds genuinely useful context beyond that: it explains the tool reports the *reason* when the service is not selling, and that this reflects configuration state rather than process liveness.

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?

Two sentences, front-loaded with the primary answer, with the second sentence doing real work by disambiguating against the health endpoint. No filler and nothing that needs to be read twice.

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 must carry the return-value burden, and it does reasonably well by enumerating what is reported (selling state, mode, network, failure reason). It could be slightly more explicit about the shape of the response, but for a zero-param read tool this is close to 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description correctly implies a no-argument status read.

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 states a concrete read of a specific resource state: whether the service is selling now, in which mode, on which network, and why not if it isn't. It also explicitly separates this resource from the liveness endpoint at /health. It does not differentiate from the sibling tools (get_docs, get_pricing, lookup_site), though those are in unrelated domains.

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?

"This is configuration, not liveness: the health endpoint is at /health" gives clear routing guidance, telling the agent when to use this tool versus the health endpoint. It stops short of naming an actual sibling tool or stating conditions such as caching or refresh behavior.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add the context that matters: the call is free of charge, it returns a stale/'last dated' verdict rather than a fresh check, unknown sites are non-errors, and how to obtain fresh data. That is meaningful behavior beyond what the structured fields convey.

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?

Four short sentences, front-loaded with the cost signal ('Free.') and the core semantics, then the error-expectation and the purchase route. Every sentence carries information an agent needs; nothing is padding.

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?

There is no output schema, so the description must carry the return-value burden and it does: verdict, score, date, badge, and the known flag. Combined with the cost and freshness caveats, an agent has everything needed to call this correctly without probing.

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 single `url` parameter already documents the accepted https URL/hostname format. The description adds no further syntax, normalization, or edge-case detail for the input, so the baseline of 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?

States a specific verb+resource ('look up the last dated verdict for a website') and enumerates exactly what comes back: verdict, score, date, badge. It also differentiates itself from get_pricing by noting that a fresh check must be purchased there, so an agent can route without opening any schema.

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?

Names the alternative tool explicitly ('To get a fresh check, buy one (see get_pricing)') along with the condition that selects it: this tool returns only previously cached verdicts. It further pre-empts a common misuse by stating an unknown site is a normal result (known: false), not an error.

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