Route 232: HUD Section 232 programs, queue and timing

Which HUD Section 232 loan fits

which_232_program

Read-onlyIdempotent

Answers which HUD Section 232 program fits an assisted living, memory care or nursing home (223(f), 223(a)(7), new construction/substantial rehab or 241(a)) from the same questions as the Route 232 chooser, with eligibility warnings, and returns that program's published rules: who qualifies, loan limits, coverage, mortgage insurance and fees, required reports and the HUD median closing time. Pass "program" alone to get one program's rules.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "which_232_program"
  }
}

Input Schema

Name	Required	Description
`goal`	No	Only when has_fha_loan is true: a lower rate or payment, or money for improvements or an addition.
`program`	No	Skip the questions and return the rules of one program: 223f (refinance or purchase), 223a7 (streamlined refinance of an FHA loan), new-construction (new construction or substantial rehab) or 241a (supplemental loan).
`operating`	No	Only when has_fha_loan is false: is the building open and operating (false = building new or gutting it)?
`has_fha_loan`	No	Does the building have an FHA-insured (HUD) loan today?
`licensed_20_plus_beds`	No	Licensed or regulated by the state, with 20 or more beds?
`years_since_completion`	No	Only when operating is true: years since the building was completed or last substantially rehabilitated.
`independent_living_over_25pct`	No	Are more than a quarter of the beds independent living?

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it emits eligibility warnings in addition to rules, and it enumerates the returned rule categories (qualification, limits, coverage, insurance and fees, required reports, median closing time). It does not mention determinism of the chooser logic or what happens with contradictory answers, keeping it at 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary answer-selection behavior is front-loaded in the first clause, and the shortcut mode is a tight second sentence. The middle is a long comma-separated list of return categories, which is dense but each item is informative rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, no output schema, and zero required fields, the description does the necessary work of describing the return payload and the two-mode invocation. An agent can call it correctly without guessing. It could be more complete about what happens when answers are inconclusive (multiple eligible programs, warnings only).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds meaning the schema doesn't: the 'program'-only shortcut is a distinct invocation mode, not just an enum input. It does not restate the conditional gating of goal/operating/years_since_completion, which is why this isn't a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Answers which HUD Section 232 program fits') and enumerates the candidate outcomes (223(f), 223(a)(7), new construction/substantial rehab, 241(a)) plus the property types covered. It also names what comes back (eligibility warnings plus that program's published rules), which separates it cleanly from the timeline/closing-stats siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly explains the two invocation modes: answer the questionnaire, or 'Pass "program" alone to get one program's rules.' The schema goes further, gating goal/operating/years_since_completion on other answers. It stops short of naming siblings as alternatives (e.g. 'use estimate_232_timeline for scheduling'), so a 4 rather than a 5.

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

All Route 232: HUD Section 232 programs, queue and timing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?