LIHTC properties reaching Year 15 by state and year, with dates and exit options.
Scored across 4 tools
find_year15_properties (filtered list) vs get_property (single item by HUD id) vs year15_summary (aggregate counts) are clearly distinct in both granularity and return shape. The only soft overlap is year15_exit_options, which recomputes credit-period/compliance-end/QCP/ROFR dates that get_property already returns for a given property, though the path-explanation focus differentiates it.
All names are snake_case and readable, with find_/get_ verb prefixes on the two lookup tools and a year15_ domain prefix on the other two. The set mixes verb-led and noun-phrase styles, which is a minor inconsistency but the intent of each name is immediately clear.
Four tools is well-matched to a narrow, read-only LIHTC Year 15 dataset: one list, one detail, one aggregate, one explanatory calculator. Nothing feels padded or redundant, though the surface is on the thin side and could be seen as slightly under-scoped.
As a read-only reference domain, the surface covers listing, detail lookup, aggregate counts, and exit-path logic without obvious dead ends. Minor gaps remain — no direct lookup by property name or multi-state comparison in one call — but agents can work around these via existing filters.
Lists tax credit properties in one state from HUD's LIHTC database (placed in service 2009 to 2018) with name, HUD id, city, units, low-income units, credit type and estimated compliance-period end year. Filter by end year (2023 to 2032), city, minimum units or credit type; returns the total matched and a page of rows.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City as HUD lists it, e.g. "Houston". | |
| limit | No | Rows to return (default 10, max 50). Sorted by units, largest first. | |
| state | Yes | Two-letter state or territory code, e.g. TX. | |
| offset | No | Rows to skip, for paging. | |
| min_units | No | Only properties with at least this many total units. | |
| credit_type | No | Credit type decoded from HUD's CREDIT field. | |
| compliance_end_year | No | Estimated year the 15-year compliance period ends (placed-in-service year + 14), e.g. 2027. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description adds genuinely useful non-annotation context: the HUD LIHTC source database and the 2009-2018 placed-in-service cohort, plus the fact that results are split into a total count and a paged row set. It does not disclose the sort order or paging limits (those live only in 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?
Two sentences, zero filler: the first front-loads what the tool returns and its source, the second enumerates filters and output shape. Nothing is repeated from the schema verbatim beyond necessary framing.
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?
For a 7-parameter read-only query with full schema coverage, the description covers source, cohort, filters, and return shape, which is enough to call it correctly. The only meaningful gap is routing: it does not explain how it relates to year15_summary or year15_exit_options, leaving sibling selection to inference.
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 filterable parameters (end year, city, min units, credit type) but adds no semantics beyond the schema, and it omits limit/offset entirely except via the loose phrase 'a page of rows'.
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?
Opens with a specific verb + resource + scope: 'Lists tax credit properties in one state from HUD's LIHTC database', and adds the placed-in-service window (2009-2018) and the fields returned. The parenthetical provenance and the 'total matched + page of rows' phrasing implicitly separate it from year15_summary (aggregates) and get_property (single record), but no sibling is named, so an agent must infer the split.
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 states the available filters (end year, city, min units, credit type), which implies the retrieval use case, but never says when to choose this over year15_summary or get_property. No exclusions, prerequisites, or 'use X instead when' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One tax credit property by HUD project id (e.g. TXA20120123): HUD's record (address, units, low-income units, placed-in-service and allocation years, credit type, monitoring flag) plus the estimated credit period, compliance-period end, qualified contract request date, right of first refusal date and minimum extended-use end.
| Name | Required | Description | Default |
|---|---|---|---|
| hud_id | Yes | HUD project id (HUD_ID): three letters and eight digits, e.g. AKA20090010. Find ids with find_year15_properties. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description does not need to restate those traits. It adds useful behavioral context by specifying the returned HUD fields and Year 15 dates; it does not describe not-found or error behavior, which keeps it short of a 5.
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 front-loaded with the core action and stays to one dense sentence with no filler. The parenthetical list of returned fields is justified because there is no output schema, though the sentence is long and slightly run-on.
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?
For a one-parameter lookup tool with rich annotations and full schema coverage, the description is largely complete: it states the lookup key and enumerates the returned HUD and Year 15 fields. It stops short of covering not-found behavior or explicitly routing users from the search sibling.
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 hud_id parameter already includes the regex pattern, an example, and a pointer to find_year15_properties. The description repeats an example ID but adds no format or semantic detail beyond the schema, so the baseline 3 is appropriate.
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 states that this tool returns one tax credit property by HUD project id and enumerates the HUD record and Year 15 date fields included. The singular, ID-based scope distinguishes it in practice from search/list siblings, though it does not explicitly name those alternatives.
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 'by HUD project id' implies this is the lookup tool when an ID is already known, and the schema notes that IDs can be found with find_year15_properties. However, the description itself gives no explicit when-to-use guidance or comparison to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The five Year 15 paths for a LIHTC property (investor buyout, right of first refusal, sale, qualified contract, resyndication) with the statutory price rules as this site publishes them, and, given a placed-in-service year, the credit period, compliance end, qualified contract and right of first refusal dates and extended-use end.
| Name | Required | Description | Default |
|---|---|---|---|
| extended_use_end_year | No | Extended use end year in the recorded agreement, if known and later than the federal minimum. | |
| placed_in_service_year | No | Year the building was placed in service, e.g. 2012. Omit for the exit paths only. | |
| credits_start_next_year | No | True if the owner elected on Form 8609 to start credits the year after placed in service. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world lookup. The description adds meaningful domain behavior: it enumerates the five exit paths, notes that statutory price rules are site-published, and explains which dates are produced when a placed-in-service year is supplied. It stops short of describing output formatting or assumptions.
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 front-loaded and dense, naming the five paths first and then the date outputs. It is a single long sentence with some clause stacking, but nearly every phrase carries useful scope information.
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?
For a tool with rich schema descriptions, annotations, and no output schema, the description is substantially complete. It explains the domain outputs and the conditional date calculations, though it could clarify the response form or how extended_use_end_year changes results.
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?
All three parameters have complete schema descriptions, so the schema already carries parameter meaning. The tool description only adds that placed_in_service_year drives the date calculations; it does not elaborate on credits_start_next_year or extended_use_end_year beyond the schema.
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 a specific resource and scope: the five Year 15 exit paths plus date calculations derived from a placed-in-service year. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings like year15_summary or find_year15_properties.
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 saying dates are returned 'given a placed-in-service year,' and the schema notes that the year may be omitted for exit paths only. It does not explicitly say when to use this tool versus the sibling summary/search tools or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts of tax credit properties, total units and low-income units whose estimated 15-year compliance periods end in each year from 2023 to 2032, for one state or the whole US, from HUD's LIHTC database (placed in service 2009 to 2018).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter state or territory code, e.g. CA. Omit for the national totals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, closed-world, and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond annotations: HUD LIHTC source, placed-in-service years 2009-2018, estimated 15-year compliance periods, and the 2023-2032 reporting window.
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 definition is a single tightly written sentence that front-loads the aggregation purpose and then layers in temporal, geographic, and provenance details. Every clause contributes useful scoping information with no repetition or 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?
For a simple one-parameter aggregation tool with no output schema, the description is complete enough to call correctly: it states the counted entities, year range, state/national coverage, data source, and underlying population. An agent does not need additional behavioral or return-shape detail to use this summary tool appropriately.
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 single optional state parameter is already documented with format and national-totals behavior. The description reinforces that the tool works for one state or the whole US, but adds no syntax or semantic detail beyond the schema.
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 gives a specific verb (Counts) and precisely names the resources counted: tax credit properties, total units, and low-income units. It also defines the temporal scope (2023-2032), geographic scope (one state or whole US), and data source, making clear this is an aggregate summary rather than a property-level listing like find_year15_properties.
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 when the tool is useful by stating what it counts and the year range, but it does not explicitly say when to choose it over sibling tools such as find_year15_properties, get_property, or year15_exit_options. No exclusions, prerequisites, or alternative-tool routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_year15_propertiesget_propertyyear15_exit_optionsyear15_summaryHUD Section 8 HAP contract expirations, below-FMR screen and property lookup by state.
LIHTC data: HUD income and rent limits, 2027 QCT/DDA checks, LIHTC properties, credit math.
Senior housing demand vs. licensed beds by state and county, CON, HUD 232, development calc.
Assisted living licensing, supply and HUD 232 loans by US state, from state, CDC and HUD data.
Add one secure layer between your agents and this server.