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

Annotations already cover read-only/idempotent/no-side-effects, and the description adds real context beyond them: the data vintage (HUD FY2026 MTSP), the derivation method (IRS Publication 5913), that both gross and tenant-paid rent are returned, and that the formula is included. It stops short of noting edge cases such as how ambiguity in county lookup is resolved, though the schema handles that.

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, front-loaded with the outputs and followed by inputs, deduction, source and method. No filler, though the stacked clauses ('less an optional utility allowance, from HUD FY2026 MTSP limits by the IRS Publication 5913 method, with the formula') make it slightly harder to scan than it needs to be.

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, the description carries the burden of naming the return values, and it does (gross rent, tenant-paid rent, plus the formula). For a six-parameter computation tool that is adequately covered, missing only a note about the geographic-identifier precedence that the schema itself covers.

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 100%, so the baseline is 3. The description restates the core inputs (county, bedrooms, AMI, optional utility allowance) and clarifies that the allowance is subtracted, but adds no syntax or default detail beyond what the schema already documents for fips/state/county and the 0-5 bedroom range.

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?

A specific verb (calculate) and resource (maximum LIHTC gross and tenant-paid rent) with the exact scope of 'one unit'. It clearly separates itself from siblings like get_income_limits and calculate_credits by naming the MTSP rent limits and the Pub 5913 method.

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?

Usage is implied by the input set (county, bedrooms, AMI) and by 'one unit', but the description never states when to pick this over get_income_limits or calculate_credits, and gives no exclusions or prerequisites. An agent must infer the routing from the sibling names.

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