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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real behavioral value by revealing the fixed 40%→25% reclassification premise and that outputs are computed figures (annual tax reduction, refund demand), but it never states what happens when the fixed ratio assumption does not hold to the input data, nor whether the tool validates eligibility.

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?

A single dense sentence that leads with the action and the misclassification thresholds before naming the outputs and statutes. Nothing is padded, though the statutory citations compress a lot of meaning into one sentence with no structural break.

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 no output schema, 6 parameters, and a computational tool, the description should say more about the shape of the computed results and any preconditions. It does explain the core calculation and the retroactive window, which is the essential part, but leaves output format and the handling of edge cases 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 coverage is 100%, so every parameter is already documented in the schema; that sets the baseline at 3. The description clarifies which statutory computation consumes market_value and actual_use but adds no per-parameter meaning such as format, valid values, or the role of current_classification versus the fixed 40% premise.

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 ('audit property misclassification') plus the exact computation performed (40% Commercial → 25% Residential ratio, annual tax reduction, 3-year retroactive refund demand) and the governing statutes. This is far more specific than a title restatement, though it never names a sibling tool it might be confused with.

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?

Use case is only implied: an agent can infer it applies to parcels currently classified commercial that are actually residential. There is no explicit when-to-use statement, no exclusions, and no pointer to alternatives such as audit_retroactive_tax_recovery or audit_property_tax for adjacent queries.

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