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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: output is labelled per Location and unreachable Locations are reported as skipped, and blank location falls back to all-or-only Location depending on the connection. That is real operational context 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 core purpose is front-loaded in one line, and the location rules follow in a compact paragraph. Minor waste from reStructuredText double-backtick markup and a parenthetical ``(property, tenant, ...)`` aside that is only loosely relevant.

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?

An output schema exists, so return-value explanation is not required, and the location dimension is well covered. But for a filtered-list tool, the relationship between ``property_id``, ``shortname`` and ``location`` (are they alternatives? combinable?) is left entirely to inference.

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 carries the burden. It compensates fully for ``location`` (single ID, comma list, "all", blank default), but ``shortname`` and ``property_id`` are never mentioned, leaving two of three parameters semantically opaque.

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?

Opens with a specific verb and resource ("List all units (lots/spaces) in a property") and even names the returned fields (UnitID, Name), which no sibling does. It is clearly distinct from list_properties/list_tenants, though the "in a property" framing sits slightly awkwardly with a location parameter that spans every Location.

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 location semantics are spelled out well and it routes to ``list_locations`` for discovery, plus warns that IDs belong to one Location so the Location must be passed when filtering. However, there is no guidance on when to use this tool versus list_properties, analyze_rent_roll, or get_unit_udfs, and no statement of what it does not return.

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