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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: exact price points ($0.02 single, $0.25 bulk), USDC-on-Base-only settlement, the verdict taxonomy (registered/likely_unregistered/unknown), the rule that failed or throttled sources degrade to 'unknown, never available', and explicit non-guarantee/not-legal-advice disclaimers. This is exactly the extra behavioral layer annotations cannot 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?

Purpose and the 'does not pay' boundary are front-loaded, and every sentence carries distinct information (pricing, protocol, verdict semantics, failure mode, TLD exclusion). It is a dense single block that would scan better split into price/protocol/output/caveats groupings, which is the only thing keeping it off a 5.

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 input params and no output schema, the description carries the full burden and discharges it: what comes back (verdict plus age, status flags, RDAP/DNS/TLS, look-alike signal, optional OFAC screen), what happens on source failures, what the price is, and what is explicitly out of scope (.dev/.app, guarantees). An agent can decide and act without further data.

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 goes further by documenting the HTTP-level inputs the quote pertains to (domain query param, domains array, tier selection), which pre-answers how a caller would eventually invoke the underlying endpoint.

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?

Opens with a specific verb and resource ('Returns the payment terms for https://horizonpulse.dev/api/domain/precheck') and immediately draws the boundary that matters: 'this tool never runs the check or pays.' That distinguishes it from execution/check siblings such as x402_check or bazaar_check without the agent needing to open a 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?

It explains that consumption happens over HTTP with x402 v2 (GET for single tier, POST for bulk), which tells the agent this call is a pricing/terms lookup step, not the action itself. It also gives a concrete usage rule for .dev/.app names (refused before payment, stripped from bulk batches). It stops short of an explicit 'call this before X, otherwise use Y' routing statement naming a sibling.

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