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

Annotations already declare readOnly/idempotent/non-destructive, so the description only needs to add analytical context – which it does by disclosing the data source (report 69), the unit-type dimensions, and that values are expressed as shares of total. Nothing about auth, rate limits, or pagination is mentioned, keeping it short of a 5.

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 and the key split are front-loaded in the first sentence, and the example queries are compact and useful. Slightly verbose between the header line and the examples, but no sentence is wasted.

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?

With an output schema present, return values need not be explained, and the analytical framing is solid. However, the complete absence of parameter documentation for a zero-coverage schema leaves an agent unable to construct a well-formed call without guessing.

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% for all three parameters (portfolio, as_of_date, property_ids), so the description carries the full burden of explaining them. It says nothing about accepted formats, whether ids are comma-separated, or the default date behavior, leaving a real gap.

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 a specific verb and resource ('Scheduled-rent composition by unit type') plus the exact analytical split it performs (lot rent vs DOH vs RV vs apartments, base rent vs misc charges). This clearly differentiates it from sibling analyze_rent_roll, which supplies the underlying report 69.

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 trigger phrases ('how much of our rent is lot rent vs home rent', 'revenue mix by unit type') and names the source report, which implicitly routes agents away from analyze_rent_roll. It stops short of an explicit when-not-to-use or a named alternative for raw rent-roll data.

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