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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the bar is lower, and the description still adds genuine behavior: multi-Location fan-out with 'all', per-Location output labelling, and unreachable Locations reported as 'skipped'. That fan-out/skip behavior is not derivable from annotations or schema and materially affects interpreting results.

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?

Purpose is front-loaded in one line, then each remaining block is dedicated to a single parameter with no repetition or hedging. The longer location paragraph earns its length because it encodes non-obvious fan-out and skip semantics.

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 shape need not be described. With six optional params and multi-location behavior, the definition covers the hard parts (Location resolution, fan-out, skipped locations) but leaves half the filter parameters unexplained, so an agent cannot know, for example, how portfolio and property_ids interact with location.

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 the load. It does well on two of six: active_on accepts 'YYYY-MM-DD' or 'today', and location accepts a single ID, a comma list, or 'all' with defined blank-default semantics. But portfolio, shortname, property_id, and property_ids are never mentioned, leaving a real gap despite the strong treatment of the two most complex params.

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?

Opening sentence states a specific verb and resource ('List leases') plus the two scoping axes (property, portfolio). It does not explicitly distinguish itself from the closely related sibling lease_expirations, so an agent must infer the difference, but the core purpose 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?

Gives concrete conditional guidance for the two tricky parameters: pass a Location when filtering by an ID because 'IDs (property, tenant, ...) belong to one Location', and use active_on to scope by date. It stops short of stating when to prefer this over lease_expirations or analyze_rent_roll, so no explicit alternatives or exclusions.

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