Skip to main content
Glama

TerraVue

by app.terravue
OverviewDiscussionsAdmin

buy_vs_rent

Read-only

Should someone buy this home or keep renting? Runs the TerraVue engine: a deterministic 30-year simulation plus a 500-scenario Monte Carlo over correlated market paths. Returns the probability buying wins, the breakeven hold period, and net-worth outcomes.

monthly_rent = what the person would pay to rent THE SAME HOME to live in — an
owner-occupant buy-vs-rent decision, NOT rental income they'd collect as a landlord
(this tool does not model rental cash flow; that lens lives on terravue.app). A rent
far out of line with home_price is almost certainly a misunderstanding — confirm it
before trusting the verdict. If `address` is given, the ZIP's real appreciation forecast
and regional tax/insurance defaults are used (explicit parameters still win).

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.
monthly_rentYesWhat this person would pay per month, in US dollars, to rent THE SAME HOME to live in. This is an owner-occupant comparison — it is NOT rental income they would collect as a landlord.
analysis_yearsNoHold period in years. Use the horizon the person actually stated — if they say 'about five years', pass 5. Only default to 30 when no horizon was given.
down_payment_pctNoDown payment as a PERCENT of price: 20 means 20%. Not a fraction (not 0.20).
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.
home_appreciation_rateNoAnnual home appreciation as a PERCENT: 3.5 means 3.5%/yr. Prefer leaving this unset and passing `address` instead, so the ZIP's FHFA-derived forecast is used rather than a guess.
investment_return_rateNoAnnual return the renter earns on invested cash, as a PERCENT: 9.5 means 9.5%/yr, roughly long-run equities. This assumption drives the result more than any other — drop it to about 4.5 if the alternative is savings rather than the market, or if the person sounds risk-averse, and present both runs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 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 / analysis_years / description
      Added value: +"Hold period in years. Use the horizon the person actually stated — if they say 'about five years', pass 5. Only default to 30 when no horizon was given."
    • 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_appreciation_rate / description
      Added value: +"Annual home appreciation as a PERCENT: 3.5 means 3.5%/yr. Prefer leaving this unset and passing `address` instead, so the ZIP's FHFA-derived forecast is used rather than a guess."
    • addedInput schema / properties / home_price / description
      Added value: +"Purchase price in whole US dollars, e.g. 650000 (not 650 or 650k)."
    • addedInput schema / properties / investment_return_rate / description
      Added value: +"Annual return the renter earns on invested cash, as a PERCENT: 9.5 means 9.5%/yr, roughly long-run equities. This assumption drives the result more than any other — drop it to about 4.5 if the alternative is savings rather than the market, or if the person sounds risk-averse, and present both runs."
    • addedInput schema / properties / monthly_rent / description
      Added value: +"What this person would pay per month, in US dollars, to rent THE SAME HOME to live in. This is an owner-occupant comparison — it is NOT rental income they would collect as a landlord."
    • 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/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 adds genuinely non-obvious behavior — deterministic simulation plus Monte Carlo over correlated market paths, and the specific return values (win probability, breakeven, net worth). It also discloses the precedence rule that explicit parameters override ZIP defaults, which is behavioral context the annotations do not carry.

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 decision and the engine, then returns, then parameter caveats — good ordering with no filler. The monthly_rent paragraph partly restates the schema's own description, which is mild redundancy but defensible given how easy that field is to misread.

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?

For a 10-parameter financial simulation with no output schema, the description covers the mechanism, the return values, key parameter caveats, and the address-vs-explicit-parameter precedence. Nothing critical to calling it correctly is missing.

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 parameters are already documented, but the description adds real semantic value: it disambiguates `monthly_rent` as owner-occupant rent (not landlord income) and supplies the sanity heuristic that a rent far out of line with home_price signals a misunderstanding. That heuristic goes beyond anything in the schema.

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 opens with the exact decision the tool answers ('Should someone buy this home or keep renting?') and names the mechanism (TerraVue engine, 30-year deterministic simulation + 500-scenario Monte Carlo) plus the outputs (probability buying wins, breakeven hold period, net-worth outcomes). It is a specific verb+resource, though it never explicitly contrasts itself with siblings like affordability or affordable_price.

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?

It clearly frames the use case as an owner-occupant decision and routes the landlord/rental-income lens elsewhere, and it gives situational guidance ('confirm rent before trusting the verdict', pass `address` whenever known, prefer unset appreciation over a guess). There is no explicit when-not relative to the sibling tools, so it falls short of a 5.

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