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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds meaningful context beyond that: it discloses the data provenance ('as multifamily.online lists them', 'the agency source document with its date and URL'), which tells the agent the values are third-party-sourced and dated rather than computed live. It does not discuss caching or how often the source data is refreshed.

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?

Two sentences: the first front-loads what is returned, the second enumerates covered programs. The program list is long but functional since it tells the agent the tool's full coverage. Minor redundancy between 'all of them' and the enumerated list, but no filler.

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 usefully compensates by enumerating the returned fields, and the read-only annotations cover the safety profile. The main residual gap is the lack of routing guidance relative to compare_programs, which matters for a tool whose sibling also spans multiple programs.

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% and the single enum parameter is fully documented with its default, so the schema carries the semantic load. The description's 'one ... or all of them' merely restates the schema's default behavior and adds no new parameter meaning.

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?

The description names a specific resource (published loan-program limits) and enumerates the exact fields returned (max LTV/LTC, min DSCR, term, amortization, prepayment, recourse, HUD insurance, source document). An agent immediately understands this is a reference-lookup tool. It stops short of distinguishing itself from the sibling compare_programs, which an agent could easily confuse with a multi-program query.

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 phrase 'for one multifamily loan program or all of them' implies the two usage modes, and the coverage list signals which loan types are in scope. However, there is no explicit when-to-use versus compare_programs or get_treasury_yields, and no stated exclusions or prerequisites.

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