Senior housing demand vs. licensed beds by state and county, CON, HUD 232, development calc.
Scored across 3 tools
The three tools have largely distinct roles: a financial calculator, an all-state ranking, and a single-state deep dive. The only mild overlap is between rank_states and state_demand_supply, which both surface state-level senior housing data, but their scopes (all states vs. one state plus counties) are clear enough to avoid misselection.
All names use snake_case, so casing is consistent, but the semantic pattern is mixed: rank_states is verb_noun while absorption_calc and state_demand_supply are noun phrases. The names remain readable and understandable, but they do not follow a single predictable convention.
Three tools is a reasonable, tightly scoped set for a specialized absorption and demand/supply analysis server. Each tool covers a distinct analytical need, though the surface is lean enough that a user might occasionally want an additional comparison or export operation.
The set covers the core workflow: running absorption math, ranking states by a chosen measure, and drilling into one state with county detail. Minor gaps exist around multi-state side-by-side comparison or accessing national aggregates directly, but the main analytical use cases are addressed.
Runs the Absorption development calculator on your inputs: total cost (land, hard, soft, construction interest, HUD fees), stabilized NOI, yield on cost and value, HUD 232 new construction loan (lowest of 90% of cost, the loan-to-value limit and 1.45x coverage), month-by-month lease-up to breakeven and stabilization, operating deficit and working capital escrows, and the equity left to fund. Unset inputs use the calculator page's example values.
| Name | Required | Description | Default |
|---|---|---|---|
| land | No | Land cost, dollars. | |
| units | No | Units or beds. | |
| nonprofit | No | Nonprofit borrower with an operating track record (higher loan-to-value limit). | |
| cap_rate_pct | No | Cap rate on stabilized NOI, % (your assumption). | |
| building_type | No | Assisted living or memory care, or skilled nursing (sets the HUD loan-to-value limit). | assisted_living |
| soft_cost_pct | No | Soft costs as % of hard cost. | |
| average_drawn_pct | No | Average share of the loan drawn during construction, % (for interest carry). | |
| hud_note_rate_pct | No | HUD 232 note rate, %. | |
| hard_cost_per_unit | No | Hard cost per unit, dollars (your contractor's number; no public benchmark exists). | |
| move_ins_per_month | No | Net move-ins per month. | |
| construction_months | No | Construction period, months. | |
| occupied_at_opening | No | Occupied units at opening. | |
| fixed_cost_per_month | No | Fixed operating cost per month (staff, utilities, overhead carried from day one), dollars. | |
| construction_rate_pct | No | Construction loan interest rate, %. | |
| monthly_revenue_per_unit | No | Monthly revenue per occupied unit, dollars. | |
| stabilized_occupancy_pct | No | Stabilized occupancy, %. | |
| variable_cost_per_unit_month | No | Variable cost per occupied unit per month, dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds real value beyond them by disclosing the computation chain and the loan sizing rule (lowest of 90% of cost, LTV limit, 1.45x coverage) plus the example-default fallback. It stops short of describing the shape of the returned results.
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 core action is front-loaded in the opening clause, and every listed item corresponds to a real computed output. The single long sentence is dense and slightly run-on, but no clause is 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?
For a 17-parameter calculator with no output schema, the description does the important work of naming the outputs and explaining defaults, and the annotations cover safety. It still leaves the exact return structure and units unspecified, which is a minor gap given there is no output schema.
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 per-parameter baseline is 3. The description goes beyond the schema by explaining that total cost bundles land, hard, soft, construction interest and HUD fees, and by spelling out the HUD 232 sizing logic and the default-to-example behavior, which clarifies how inputs interact.
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 ('Runs the Absorption development calculator') and enumerates the outputs it produces (yield on cost, HUD loan sizing, lease-up, escrows, equity). The purpose is unambiguous, though it never explicitly distinguishes itself from the sibling tools rank_states and state_demand_supply.
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 calculator framing, and the closing note that unset inputs fall back to example values is useful operational guidance. However, there is no explicit when-to-use/when-not or steering toward alternatives, so an agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks all 50 states and DC on one senior housing measure: 75+ or 85+ population, 75+ or 85+ growth since April 2020, nursing home beds per 1,000 aged 85+, assisted living beds per 1,000 aged 75+, or HUD 232 new construction loans since FY2001. Each row also carries growth, both bed ratios, certificate of need status and the state page link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return, 1 to 51 (default 10). | |
| order | No | Highest first or lowest first. Default: lowest for the two bed ratios (thinnest supply first), highest for everything else. | |
| metric | Yes | Measure to rank by. | |
| offset | No | Skip this many rows, for paging. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing what each row returns (growth, both bed ratios, certificate of need status, state page link) — important since there is no output schema — though it doesn't mention ordering defaults or paging behavior, which live 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, front-loaded with the verb and scope, with no filler. The near-duplication between the metric list and the row-contents clause is the only mild redundancy.
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 correctly compensates by enumerating the row fields an agent will receive, and it states the population covered (all states + DC). Only the ordering/paging mechanics are left unaddressed, and those are fully covered in the schema.
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 every parameter including the metric enum is documented, and the default-order behavior for the two bed ratios is spelled out in the schema itself. The description's plain-language restatement of the seven measures helps map user intent onto the enum but adds little beyond the schema, so baseline 3 fits.
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 (ranks) and a precise scope (all 50 states and DC) plus the full set of rankable measures. An agent can tell this is a cross-state ranking tool and not the sibling `state_demand_supply` (a single-state deep dive) or `absorption_calc` (a computation) without opening any schema.
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: use this when you need states ordered by one senior-housing measure. There is no explicit when-to-use/when-not, and the sibling tools `absorption_calc` and `state_demand_supply` are never named, so the agent must infer the boundary from the purpose statement alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One state's (or DC's) senior housing development picture: Census 75+ and 85+ population (April 2020 and July 2025) and growth vs the US, CMS certified nursing home beds and CDC assisted living beds per 1,000 older adults vs the US, certificate of need status for nursing homes and assisted living, HUD Section 232 new construction loans since FY2001, and a county table (largest, fastest-growing or thinnest nursing supply), or one county by name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Counties to return, 0 to 50 (default 10). | |
| state | Yes | Two-letter state code or full name, e.g. "FL" or "Florida". DC is included. | |
| county | No | Optional: one county to return, e.g. "Maricopa" or "Maricopa County". Not available for Connecticut. | |
| offset | No | Skip this many counties, for paging. | |
| county_sort | No | County list order: largest 75+ population; fastest 75+ growth (counties with 2,000+ aged 75+); fewest nursing beds per 1,000 aged 85+ (counties with 1,000+ aged 85+). | largest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is return content, and it delivers: it enumerates each dataset and the fact that metrics are benchmarked against the US. It stops short of noting caveats such as whether the July 2025 figures are projections or that the county table only appears with a positive limit.
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 that front-loads the state scope and then walks the data categories in a stable order. It is information-rich rather than padded, though the comma-list structure makes it harder to scan than a short bulleted breakdown would 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 telling the agent what comes back, and it covers every section of the payload including the county table variants. Minor omissions remain: how county, limit, and county_sort interact, and the Connecticut county restriction is only visible in the schema.
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 all five parameters are already documented, and the description only restates the county_sort options (largest / fastest-growing / thinnest nursing supply) at a high level. It adds no syntax guidance for state codes, county names, limit, or offset beyond the schema, so the baseline 3 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 is a detailed inventory of the resource: Census 75+/85+ population, CMS nursing beds, CDC assisted living beds, CON status, HUD Section 232 loans, and a county table. An agent can tell this is a per-state profile rather than a comparison, implicitly distinguishing it from rank_states. The verb is implied rather than stated ("One state's ... picture"), which keeps it out of 5 territory.
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?
Scope is implied: "One state's" signals a single-state lookup as opposed to a multi-state ranking, and "or one county by name" signals the county drill-down. However, no sibling is named and there is no explicit when-to-use / when-not-to-use guidance (e.g., vs absorption_calc or rank_states).
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.
absorption_calcrank_statesstate_demand_supplyAssisted living licensing, supply and HUD 232 loans by US state, from state, CDC and HUD data.
US nursing home owners, CMS ratings and matched HUD 232 loans, plus a 232 refinance sizer.
Skilled nursing benchmarks by state from CMS cost reports, plus SNF valuation and DSCR math.
HUD Section 232 program chooser, weekly ORCF queue, closing times and note rates.
Add one secure layer between your agents and this server.