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

Beyond readOnlyHint=true and openWorldHint=false, the description discloses important behavior: compact and full projections retain identical claims, coordinate context is a separate point observation rather than an inferred parcel match, and unavailable or ambiguous research is free while useful partial evidence counts as one answer. It also states that the result includes attributions and a professional-advice disclaimer that must be passed through. These details add real value beyond the 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 dense but front-loaded, starting with the core purpose and packet contents before covering projection behavior, coordinate caveats, billing semantics, and required output notices. Most sentences earn their place, though the paragraph is long for a single tool definition.

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 tool is complex, with 7 parameters and an output schema, and the description covers important behavioral and output-notice details. However, it leaves significant gaps around when to choose this tool over siblings and what most parameters mean, so it is only partially complete for an agent to invoke it confidently.

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%, so the description must carry parameter meaning, but it only clarifies 'projection' as compact/full with identical claims and explains that coordinate context is separate from parcel identity. It does not explain the semantics of 'local', 'sellerScenarios', 'permitLimit', or 'includePermits', leaving most top-level parameters under-specified.

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 states a specific verb and resource: get a bounded property research packet with exact identity matching, source-backed facts, calculations, conflicts, unknowns, and follow-ups. It clearly defines the packet's scope, but it never names sibling tools like wa_property_lookup or wa_seller_packet to help distinguish when this composite packet is the right choice.

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 some usage constraints, such as preserving qualifications and passing through attributions and disclaimers, but it does not state when to use this tool versus alternatives like wa_property_lookup, wa_site_context, wa_local_context, or wa_seller_packet. There are no explicit when-not-to-use conditions.

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