LIHTC Atlas: income limits, QCT/DDA and LIHTC properties

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds real behavioral detail an agent cannot get from structured fields: credit_price silently defaults to the latest public median (an external-data dependency despite openWorldHint=false), and the applicable percentage falls back to the statutory floor unless overridden.

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 dense sentences with no filler, and the computed outputs are front-loaded. The listing of inputs is somewhat compressed into one long clause, but nothing is wasted.

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?

No output schema exists, so the description carries the burden of indicating return values, which it does by naming annual credits, 10-year credits, and equity. It omits units and the assumed credit period convention, but the inputs and defaults an agent needs are covered.

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 the baseline is 3. The description earns above that by surfacing the default for credit_price and the floor-vs-applicable_percentage precedence rule, which the schema states only obliquely ('when the floor does not apply').

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 precisely what is computed: annual and 10-year housing credits and equity from eligible basis, applicable fraction, credit type, boost and credit price. This is clearly distinct from siblings like calculate_max_rent or get_equity_pricing. It is a noun-phrase description rather than a verb-led one, which slightly weakens the imperative signal.

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?

There is no explicit when-to-use or when-not-to-use guidance and no reference to alternative tools, even though get_equity_pricing and get_applicable_percentages are close neighbors an agent might confuse it with. The closing note about sharing math with the lihtc.loans estimator is provenance, not routing guidance.

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

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.

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds genuine context beyond that: geocoding is performed by the Census Bureau, results are returned per list year, and newer HUD list years are included automatically — behavior an agent could not infer from the schema.

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?

Opens with the core question, then input modes, then return shape — front-loaded and free of filler. Every clause carries information the caller needs.

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 names what comes back (tract, county, ZCTA, metro area, one result per list year). It does not address failure modes such as an un-geocodable address or an out-of-range tract, which would round out a lookup of this type.

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 only 50%, but the description compensates by framing lat+lon as a pair and positioning address, lat/lon, and tract as mutually exclusive alternatives, which the bare schema (zero required params) does not convey. It still doesn't state formats such as coordinate ranges or what happens if multiple modes are supplied.

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 precise question verb-resource pair: whether a site falls in a Qualified Census Tract or Difficult Development Area on HUD's 2027 (and newer) lists. An agent can immediately distinguish this lookup from the sibling calculators and property tools.

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 description enumerates the three accepted input modes (address, lat+lon, tract) and the constraint 'or', which effectively tells the agent how to invoke it. It lacks an explicit statement of when NOT to use it or which sibling to pick for related queries, keeping it just below a 5.

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

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

The description explicitly states critical operational behavior, noting that the tool 'Defaults to the latest month' and provides historical data for 'the last 12' months. This is valuable context that goes beyond the structural annotations provided.

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 description is concise, packing the source, data types, and operational defaults into a single, highly efficient sentence with no wasted words.

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 definition is robust, covering the source, the specific rates retrieved, and the default operating parameters. It is complete enough for an agent to know exactly what data it will get and under what conditions.

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?

Given 100% schema coverage, the baseline is 3. The description adds semantic value by explaining the default behavior regarding the 'month' parameter and providing the temporal scope (last 12 months), which directly impacts how the parameter functions.

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 defines the resource (IRS applicable present value credit rates) and the specific data points provided (70/30, 9/4% rates). While specific, it relies heavily on the agent knowing the context of IRS ruling to be perfectly clear.

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 description implies usage by listing the types of rates (e.g., 'the rate a deal uses'), which provides sufficient context. However, it does not explicitly name or exclude competing calculation tools, making the usage guidance moderately implied rather than definitive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about the data source and series start date, but does not discuss return format, update cadence, or limitations beyond 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?

The description is a single, front-loaded sentence that states the metric, source, time scope, and pricing ranges without filler. Every phrase contributes to identifying the data returned.

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 and no parameters, the description carries the burden of explaining what comes back. It identifies the metric, source, series start, and national fund pricing ranges, which is sufficient for a simple read-only lookup, though it could clarify the exact return shape.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description does not need to compensate for missing schema details.

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 and metric: median net equity price per $1 of federal housing credit, with source and temporal scope. It is clear what the tool returns, though it does not explicitly distinguish itself from sibling tools such as calculate_credits or get_financing_quote_link.

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 description implies the tool is for equity pricing data but gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer its role relative to the many sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: 'Returns a link only; it submits nothing,' which preempts the natural assumption that a 'request a quote' page might initiate a submission. It does not say whether the link is static or expires, which is a minor gap.

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 sentence with no filler, and the key constraint ('returns a link only') is placed at the end where it lands clearly. It opens with a noun phrase rather than a verb, which is slightly less scannable than a direct action statement, and the parenthetical list of deal types makes the sentence long.

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 input schema to explain and no output schema, the description carries the return-value burden itself and does so by stating it returns a link. The domain context (who the lender is, what deal types the desk handles) is sufficient for an agent to route a user here. Only the link's nature (static vs. expiring, single-use) is left unstated.

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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema's additionalProperties=false confirms no input is expected.

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 states precisely what the tool returns: a link to the page where a developer or owner requests a LIHTC financing quote from Janover Capital LLC, enumerating deal types (4%/9%, construction, bond, bridge, permanent, Year 15). It is clearly distinct from the sibling calculators and property lookups, though it never names a sibling 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?

The intended caller and situation are implied (a developer or owner seeking a financing quote), and the closing clause rules out expecting a submission. However, there is no explicit 'use this when...' statement and no comparison to alternatives such as get_equity_pricing or get_applicable_percentages, leaving the agent to infer when this link is the right destination.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is data provenance — and it delivers: HUD FY2026 vintage, MTSP dataset, HERA Special "where HUD lists them," and the IRS Pub. 5913 rent-derivation method. It only lacks failure behavior (e.g., what happens on ambiguous or non-covered counties).

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, front-loaded with the data vintage and scope, and the location-input instruction is separated out where it is easy to find. The first sentence is a dense enumeration but every clause names a distinct returned dataset, so nothing is padding.

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 return-value burden and does so completely: levels, household sizes, HERA variants, AMI, and rent by bedroom. An agent knows exactly what it gets back and whether to supply names or a FIPS code.

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 baseline is 3; the description still adds value by framing the defaults — the full 20-80% range across 1-8 persons is returned unless narrowed — which explains the optional ami_level and household_size filters. It also restates the state+county-or-fips input pattern that the schema documents separately per field.

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 (HUD FY2026 MTSP income limits for a county/town) and then enumerates the exact contents: 20%-80% AMI levels, 1-8 persons, HERA Special, AMI, and max gross rent by bedroom. That enumeration distinguishes it from calculate_max_rent and get_applicable_percentages, which compute rather than retrieve.

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?

"Give state + county, or fips" covers how to supply location, but there is no explicit when-to-use guidance and no routing away from overlapping siblings such as calculate_max_rent or get_applicable_percentages. Usage is inferable from the payload list rather than stated.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context by disclosing exactly what payload comes back, including year-qualified figures (2026 ceiling, 2027 QCTs) and the per-capita/minimum basis breakdown — useful because no output schema exists. It does not say what happens for an unknown state code or a state with no published QAP, which is the remaining gap.

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 with no filler — every listed item is substantive return content. It is front-loaded with the resource identity, though the missing verb makes the opening slightly awkward and the list is longer than strictly needed.

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 return-value burden and does so thoroughly, naming each returned fact with its applicable year. It omits response format and invalid-state/empty-data behavior, which are the only meaningful omissions for a one-parameter read tool.

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 `state` parameter is fully documented in the schema (two-letter code or name, examples given). The description adds no additional meaning about the parameter, so the baseline 3 for schema-covered params applies.

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 enumerates the specific resource being fetched — a state's allocating agency, QAP, state credit, 2026 9% ceiling, bond cap, and 2027 QCT/DDA counts — so an agent can clearly distinguish it from calculate_credits or check_qct_dda. It lacks an explicit verb ("Get/Return"), reading as a noun-phrase inventory of return fields rather than a statement of action, which keeps it below a 5.

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: an agent infers this is the state-level lookup tool when it needs jurisdictional context. There is no explicit when-to-use, no named alternative (e.g., check_qct_dda for a specific address's QCT status), and no statement of prerequisites or exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered and the description wisely spends its words elsewhere. It adds genuinely non-inferable behavior: results are sorted largest first, only cities with 5+ monitored properties are covered, and each record carries a page URL and HUD project id. Gaps: 'largest first' never says largest by what measure, and pagination/truncation behavior past the limit is unstated.

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?

Three tight sentences with no filler, and the resource plus scope lead the first sentence. The 5-property coverage caveat is appended as a trailing clause where it is easy to skim past, when a coverage warning arguably deserves its own sentence.

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?

No output schema exists, so the description carries the return-value burden and does partly meet it by naming the URL and HUD project id each result carries. Combined with the coverage threshold and ordering, an agent knows enough to call this correctly. What is missing is the rest of the result shape plus behavior at the limit boundary (default 10, max 50).

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 75%, so baseline is 3. The description restates the state/city/name scoping already documented in the schema and adds only a hint about fuzzy name/street matching ('name or street fragment'), which goes slightly beyond 'Words from the property name or street address'. The limit parameter and its 1-50 range are never mentioned, and 'largest first' is not tied to limit or sort semantics.

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 resource (HUD-listed LIHTC properties still monitored for compliance) plus the exact scope of filtering (one state, optional city and name/street fragment) and ordering. That is well beyond a restated name. It stops short of distinguishing itself from the sibling get_state_lihtc, whose name suggests an overlapping state-scoped listing, so the agent must infer which one to reach for.

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?

Gives clear context for use: one required state, optional city/name narrowing, largest-first ordering, and a chaining instruction that result ids feed get_property. The 'cities with 5 or more monitored properties' caveat acts as a partial exclusion, warning that small-city queries will come back empty. No explicit statement of when to prefer get_state_lihtc or how it differs from a city-level lookup.

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