Skip to main content
Glama

TerraVue

by app.terravue
OverviewDiscussionsAdmin

affordable_price

Read-only

What's the most this buyer can afford? The reverse of affordability — 'what price can I afford?' instead of 'can I afford this specific home?'. Solves for the maximum home price under standard lender limits: a front-end DTI cap (default 28% = housing / gross income) and a back-end cap (default 36% = housing + other debts / gross income). If liquid_savings is given, also caps by the cash available for down payment + closing and reports which limit binds. Returns the affordable price, the PITI and DTIs at that price, and the cash to close. Pass address to ground property tax + insurance in the ZIP's real rates.

This is a lender-limit ceiling, not a comfort recommendation — feed the result into
`affordability` (or buy_vs_rent) to check monthly slack and whether buying pencils.

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).
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.
back_end_dti_pctNoBack-end DTI cap as a PERCENT: housing plus other debts, divided by gross income. The lender standard is 36. Only change it if the user names a different limit.
down_payment_pctNoDown payment as a PERCENT of price: 20 means 20%. Not a fraction (not 0.20).
front_end_dti_pctNoFront-end DTI cap as a PERCENT: housing cost divided by gross income. The lender standard is 28. Only change it if the user names a different limit.
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. Changed11 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 / back_end_dti_pct / description
      Added value: +"Back-end DTI cap as a PERCENT: housing plus other debts, divided by gross income. The lender standard is 36. Only change it if the user names a different limit."
    • 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 / front_end_dti_pct / description
      Added value: +"Front-end DTI cap as a PERCENT: housing cost divided by gross income. The lender standard is 28. Only change it if the user names a different limit."
    • 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 / 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 / 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 / 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

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by disclosing the two default DTI caps, the conditional behavior when `liquid_savings` is supplied (adds cash cushion and reports which limit binds), and the returned fields. It does not contradict the annotations. Only missing piece is any note on precision/assumption limits of the solver.

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 core question, then the mechanism, then the caveat and downstream handoff. Dense and mostly waste-free, though the two-paragraph layout is slightly long for the content.

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?

For a complex 11-parameter solver with no output schema, the description explains the computation, the conditional outputs, and the returns (price, PITI, DTIs, cash to close). An agent has enough to invoke correctly.

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 description coverage is 100%, so baseline is 3, but the description adds real meaning beyond the fields — it ties `liquid_savings` to a limit-binding outcome and `address` to ZIP-grounded tax/insurance rates. This exceeds what the schema alone conveys.

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?

Names a specific computational verb+resource: it solves for the maximum affordable home price. It explicitly contrasts itself with the `affordability` sibling ('the reverse of affordability — what price can I afford? instead of can I afford this specific home?'), so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use, an exclusion ('This is a lender-limit ceiling, not a comfort recommendation'), and names the downstream alternatives (`affordability`, `buy_vs_rent`) to feed the result into. Usage is fully determined.

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