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

Annotations already establish read-only behavior, but the description adds substantial source-level transparency: it names publishers, periods, file hashes, attribution requirements, and legal disclaimers. It also caveats that median listing price is an asking price, not a sale price, which is valuable behavioral context beyond structured annotations.

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 data sources and fields returned, and every sentence carries relevant information. It is a dense single paragraph, though, and could be more scannable if the attribution and disclaimer instructions were separated from the data description.

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?

Although an output schema exists, the description goes beyond it to explain required attribution pass-through, the professional-advice disclaimer, and the distinction between asking and sale prices. For a multi-source read-only market data tool, an agent has everything needed to call and present results responsibly.

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 coverage is 100%, and the schema already documents both area and regionType formats with examples. The description restates that the tool accepts a ZIP, county, city or metro but adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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 exactly what data is returned and at what geography: monthly listing inventory, FHFA HPI, Census permits, BLS unemployment and OFM population for a Washington ZIP, county, city or metro. The purpose is highly specific, though it never explicitly differentiates itself from siblings such as wa_market_snapshot or wa_comps.

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?

Provides clear output-handling rules (quote numbers verbatim with their period, reproduce required attributions, pass through the attributions array and disclaimer) and notes that unknown areas are free. However, it does not say when to choose this tool over adjacent tools like wa_market_snapshot, wa_local_context, or wa_comps.

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