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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuine value by disclosing the breadth of the returned payload (compliance/extended-use years, county 50%/60% limits and rents, nearby properties) — important context since there is no output schema. No behavioral caveats about ambiguous identifier handling, though.

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?

Front-loaded with what gets returned, then a one-line invocation instruction. The long parenthetical field list is dense but earns its place by substituting for an absent output schema; there is 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?

The return-content inventory compensates well for the missing output schema, but with zero required parameters the definition never says what happens if the agent passes only `state`, both `id` and `url`, or nothing at all. For a lookup tool with three optional inputs, that ambiguity should have been resolved in 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 100%, so the baseline is 3. The description reinforces that either the page URL or the HUD project id is the entry key, but it says nothing about the `state` parameter or about precedence when both `id` and `url` are supplied — a notable omission given all three parameters are optional.

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 clearly frames this as a single-property lookup that returns the full HUD LIHTC record, enumerating the specific data domains (units, income tests, credit type, QCT/DDA status, limits, nearby properties). That enumeration distinguishes it in substance from siblings like search_properties and get_state_lihtc, though it never names those siblings explicitly.

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 closing sentence "Give the page url or the HUD project id" tells the agent how to invoke it once it has decided to, but there is no statement of when this tool is preferred over search_properties, get_state_lihtc, or check_qct_dda. No exclusions or prerequisites are given.

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