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

Annotations already declare read-only, idempotent, closed-world behavior, so the description's job is to add context — and it does: it discloses that debt service includes FHA's 0.25% premium, that the output identifies which coverage/loan-ratio test binds, and that defaults are drawn from named official sources. The 'sketch, not a loan offer' disclaimer usefully signals the output is indicative, not binding.

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?

The purpose is front-loaded and every clause carries information, but the core sentence is a tangled run-on ('the loan each execution supports by coverage and by loan ratio, which test binds, and annual debt service...') that is hard to parse. The citation list (90 FR 45789, term sheets, URL path) consumes a full sentence that could be compressed.

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 10 parameters and no output schema, the description must explain what comes back, and it does: a loan amount per execution under coverage and loan-ratio tests, the binding constraint, and annual debt service. Missing only detail on what happens when `execution` is omitted (returns all four), which lives in the schema rather than the description.

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 90%, so the schema already carries most parameter meaning and the baseline is 3. The description adds that defaults (rate, vacancy, opex, reserves) are sourced from ML 2025-03, the MAP Guide, and agency term sheets with HUD median FHA note rates, which tells the agent the omitted values are authoritative rather than arbitrary — but it adds nothing per-parameter beyond that.

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 computation (first-mortgage sizing for a RAD property) and enumerates the four executions it covers, so the agent knows exactly what it produces. It does not explicitly contrast with the sibling tools (get_rad_rents, get_financing_quote_link), but their purposes are far enough apart that confusion is unlikely.

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 only implied: the agent can infer this is the tool to run when it needs sized debt rather than rents or program facts. There is no statement of preconditions (e.g., that units and monthly_rent must be known first), no when-not-to-use, and no pointer to an alternative sizer. The closing 'A sketch, not a loan offer' is a caveat, not routing guidance.

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