Skip to main content
Glama

TerraVue

by app.terravue
OverviewDiscussionsAdmin

affordability

Read-only

Can this buyer afford this home? Returns the monthly PITI payment, front-end and back-end debt-to-income ratios (what a lender qualifies on), the income needed at a 28% front-end ratio, estimated after-tax money left over each month, the cash cushion left after closing, and a plain Comfortable / Qualifiable-tight / Stretch verdict.

monthly_debts = recurring debt obligations a lender counts (car, student loan, minimum
credit-card) — NOT living costs; this feeds DTI. monthly_expenses = living costs (food,
utilities, childcare) used ONLY for the 'left over each month' life check, never DTI.
Pass `address` to ground property tax + insurance in the ZIP's real rates. Pass
`liquid_savings` to get the post-closing cash cushion (months of payment covered).

Input Schema

NameRequiredDescriptionDefault
addressNoFull US street address, or a bare 5-digit ZIP. Pass it whenever it is known: it grounds property tax, insurance and the appreciation forecast in that ZIP's real figures instead of national defaults.
fixed_rateNoMortgage interest rate as an annual PERCENT: 6.75 means 6.75%. Not a decimal (not 0.0675).
home_priceYesPurchase price in whole US dollars, e.g. 650000 (not 650 or 650k).
hoa_monthlyNoHOA or condo fee in US dollars per month. 0 for most single-family homes.
annual_incomeYesGross household income before tax, in whole US dollars per year, e.g. 140000.
monthly_debtsNoRecurring DEBT obligations a lender counts, in dollars per month: car payment, student loan, minimum credit-card payment. This feeds DTI. Do NOT put groceries, utilities or childcare here.
insurance_rateNoAnnual homeowners insurance as a PERCENT of home value: 0.45 means 0.45%/yr. Leave unset to use the regional default.
liquid_savingsNoCash available for down payment and closing costs, in US dollars. Supplying it adds the post-closing cash cushion and the cash-limited price check.
down_payment_pctNoDown payment as a PERCENT of price: 20 means 20%. Not a fraction (not 0.20).
monthly_expensesNoOrdinary living costs in US dollars per month — food, utilities, childcare. Used ONLY for the 'left over each month' life check and NEVER for DTI. Keep these separate from `monthly_debts`, which is the lender-visible figure.
marginal_tax_rateNoMarginal federal income tax rate as a PERCENT: 24 means 24%. Used only to estimate after-tax take-home for the monthly-slack figure.
property_tax_rateNoAnnual property tax as a PERCENT of home value: 0.55 means 0.55%/yr. Leave unset to use the ZIP's real rate when `address` is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • addedInput schema / properties / address / description
      Added value: +"Full US street address, or a bare 5-digit ZIP. Pass it whenever it is known: it grounds property tax, insurance and the appreciation forecast in that ZIP's real figures instead of national defaults."
    • addedInput schema / properties / annual_income / description
      Added value: +"Gross household income before tax, in whole US dollars per year, e.g. 140000."
    • addedInput schema / properties / down_payment_pct / description
      Added value: +"Down payment as a PERCENT of price: 20 means 20%. Not a fraction (not 0.20)."
    • addedInput schema / properties / fixed_rate / description
      Added value: +"Mortgage interest rate as an annual PERCENT: 6.75 means 6.75%. Not a decimal (not 0.0675)."
    • addedInput schema / properties / hoa_monthly / description
      Added value: +"HOA or condo fee in US dollars per month. 0 for most single-family homes."
    • addedInput schema / properties / home_price / description
      Added value: +"Purchase price in whole US dollars, e.g. 650000 (not 650 or 650k)."
    • addedInput schema / properties / insurance_rate / description
      Added value: +"Annual homeowners insurance as a PERCENT of home value: 0.45 means 0.45%/yr. Leave unset to use the regional default."
    • addedInput schema / properties / liquid_savings / description
      Added value: +"Cash available for down payment and closing costs, in US dollars. Supplying it adds the post-closing cash cushion and the cash-limited price check."
    • addedInput schema / properties / marginal_tax_rate / description
      Added value: +"Marginal federal income tax rate as a PERCENT: 24 means 24%. Used only to estimate after-tax take-home for the monthly-slack figure."
    • addedInput schema / properties / monthly_debts / description
      Added value: +"Recurring DEBT obligations a lender counts, in dollars per month: car payment, student loan, minimum credit-card payment. This feeds DTI. Do NOT put groceries, utilities or childcare here."
    • addedInput schema / properties / monthly_expenses / description
      Added value: +"Ordinary living costs in US dollars per month — food, utilities, childcare. Used ONLY for the 'left over each month' life check and NEVER for DTI. Keep these separate from `monthly_debts`, which is the lender-visible figure."
    • addedInput schema / properties / property_tax_rate / description
      Added value: +"Annual property tax as a PERCENT of home value: 0.55 means 0.55%/yr. Leave unset to use the ZIP's real rate when `address` is given."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real behavioral context beyond them: it clarifies that monthly_debts feeds DTI while monthly_expenses is deliberately excluded, and that supplying address switches from national defaults to ZIP-grounded tax/insurance figures. It does not disclose latency, caching, or external-call implications of the open-world lookup.

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?

Front-loaded with the core question and output list, then the two parameters that most change results. The trailing paragraph largely restates schema-level guidance, which is mild redundancy, but no sentence is filler and the sizing fits a 12-parameter financial tool.

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

Completeness5/5

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 takes on the burden of describing returns (PITI, DTI ratios, 28% income need, after-tax slack, cash cushion, verdict), and it explains how optional inputs change those returns. For a complex 12-parameter tool it covers everything an agent needs to call it correctly.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 12 parameters with units and percent-vs-fraction warnings. The description's distinct contribution is sharpening the monthly_debts vs monthly_expenses split, but the same distinction is already stated verbatim in the schema property descriptions, so the marginal value is small. Baseline 3 is appropriate.

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

Purpose4/5

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

The description states a specific question ('Can this buyer afford this home?') and enumerates the exact computed outputs (PITI, front/back-end DTI, 28% income requirement, after-tax slack, cash cushion, verdict), so the agent knows precisely what the tool answers. However, it never names or contrasts with the closest sibling, affordable_price, leaving the affordability-vs-max-price distinction to inference.

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

Usage Guidelines3/5

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

It gives conditional guidance for optional inputs ('Pass `address` whenever it is known', 'Pass `liquid_savings` to get the post-closing cash cushion'), which implies usage context. But there is no when-to-use-this-tool-vs-alternatives guidance, no exclusion conditions, and no mention of when buy_vs_rent or affordable_price would be the better call.

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

All TerraVue toolsInspect
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