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

With no annotations, the description carries the transparency burden and mostly meets it by disclosing return fields and data provenance (own daily snapshots since 2026-06-16, no public source). It does not explicitly state that the check is read-only or cannot trigger a payment, though 'BEFORE paying it' strongly implies it.

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 front-loaded with the action, uses the middle sentences to justify the tool's necessity, and ends with a compact returns list and provenance. Every sentence contributes either behavioral or usage information, with no filler.

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?

The description covers the decision context, return contents, and data provenance, which is strong for a moderate-complexity tool. However, with no output schema and no parameter descriptions, the missing agent_id/resource mapping leaves a critical gap for constructing a correct call.

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%, and the description never maps the two required parameters. It mentions 'endpoint,' 'seller,' and 'receiving address,' but does not clarify whether resource is the endpoint and agent_id is the seller, leaving an agent unable to reliably construct arguments.

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 first sentence states a specific verb-resource pair ('Check ANY x402 endpoint') and adds a clear operational trigger ('BEFORE paying it'). The returns list—liveness, price, receiving address, and organic-vs-farm verdict—makes the tool's scope concrete and distinguishes it from generic checks like check_balance and check_domain.

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 gives an explicit when-to-use instruction: run this check before paying any x402 endpoint, supported by concrete rationale (irreversible payments, 1-in-6 dead services, wash-trading farms). It does not name sibling alternatives such as x402_seller_reputation or state when not to use the tool, so it lacks full when/when-not guidance.

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