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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context by listing the specific fields returned (ID, city/state/ZIP, coordinates, distance, sale type, dates) and reiterating that no hammer prices exist. This goes beyond annotations without contradicting them.

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 a single, well-structured sentence that front-loads the main purpose and follows with return fields and a clarifying caveat. It is informative without being verbose, though it could be split into two sentences for readability. Every sentence earns its 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 the tool's simplicity, full parameter documentation, and annotations covering safety, the description is largely complete. It lists the returned fields, clarifies the scope, and warns against a common misconception. Minor omissions like pagination or error handling are not critical for this search tool.

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 description adds no new parameter-specific semantics beyond what the schema already provides. The description's mention that the ZIP resolves the city/state mirrors the schema text. Since the schema does the heavy lifting, baseline 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?

The description clearly states the tool retrieves upcoming estate sales, moving sales, and auctions near a US ZIP code, naming the data source (EstateSales.NET). It specifies the resource and scope, making the purpose obvious. It doesn't explicitly differentiate from sibling tools like estatesales_sale or estatesales_companies, but the verb+resource is unambiguous.

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 explicitly clarifies that these are UPCOMING listings, not sold prices, which prevents a common misuse. This effectively tells the agent when not to use it (for historical prices) but does not name alternative tools or conditions that would route to siblings. The guidance is clear enough for typical use.

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