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

Goes beyond readOnlyHint/openWorldHint by disclosing the paid access model: $0.002 USDC per successful call via x402 on Base, Solana or Arc, with failed calls not charged. That payment/auth precondition is exactly the kind of context annotations can't carry. Missing rate limits and pagination behavior behind the limit parameter.

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 long enumerated field list (case number, address, county, list price, beds, baths, square feet, year built, ...) is largely redundant because an output schema exists, and it crowds out the more actionable payment sentence. Still front-loaded and readable, but sentences don't all earn their place.

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?

Given an output schema exists, the description needn't explain return values, and it covers the essentials: data source, geography, and the x402 payment flow. Somewhat complete for an agent to call it safely, though the payment mechanism deserves slightly more operational detail (how the x402 payment is presented).

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%, so the baseline is 3. The description reinforces the geographic scope (US state or city) but adds no meaning for limit or maxPrice beyond what the schema already documents.

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: HUD homes for sale by online bid from the official HUD Home Store FHA-foreclosure inventory, scoped to a US state or city. Explicitly names a sibling-adjacent product it replaces (Auction.com), so an agent can tell it apart from generic listing tools like realestate_zillow or realestate_loopnet.

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?

Clear usage context: use this for HUD/FHA foreclosure inventory in a given state or city, and the note that Auction.com blocks automated access explains why this exists. It stops short of explicit exclusions or naming which sibling to use for non-HUD or commercial listings.

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