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

Beyond the read-only and idempotent annotations, the description reveals the actual algorithm: buildable envelope computed from parcel and footprints, all plans placed and scored by size, bedrooms, pre-approval, and fit. It also discloses the return shape (best match plus alternates and URLs) and the LA-only limitation, giving the agent strong behavioral expectations.

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 information-dense and front-loads the core purpose before giving algorithm details, a use case, and an example. A small amount of redundancy exists between the opening clause and the example, but 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?

For a read-only matching tool with no output schema, the description covers inputs, process, output, use case, and geographic scope. The only minor gap is ambiguity around how the 'LA County only' restriction interacts with the county parameter, which also lists sd as an enum value.

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 schema already provides 100% coverage for all three parameters with detailed descriptions Equal and examples. The description adds a concrete address example and says 'Given an address or APN', but it does not materially extend the parameter semantics beyond what the input schema already offers, so the baseline of 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?

The description starts with a specific verb-object pair ('find which A-du Build plan sets physically fit the lot') and clearly identifies the resource and inputs (address/APN). It also specifies the output ('best match and up to three alternates with URLs'), making it easy to distinguish from generic plan-search siblings like search_plans.

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 explicitly names the target use case: 'Use for "which ADU plans would fit my backyard"' and adds a geographic constraint ('Los Angeles County only for the fit step'). However, it does not explicitly say when to use an alternative tool instead, so it stops just short of full sibling routing.

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