CalcBright Calculators

Home Affordability

home_affordability_calculator

Read-onlyIdempotent

$100,000 a year buys about a $337,657 home under the 28/36 rule. This home affordability calculator also applies UAE limits: 50% of salary and an 80% loan. Web page: https://calcbright.com/home-affordability-calculator

Input Schema

Name	Required	Description	Default
`dti`	No	Total DTI limit (back-end) (%)
`hoa`	No	HOA dues / month
`pmi`	No	PMI rate (under 20% down) (% / yr) Yearly % of the loan; ask your lender for a quote. 0 to ignore.
`down`	No	Down payment
`rate`	No	Mortgage rate (%)
`buyer`	No	Buyer and home	expat
`debts`	No	Monthly debt payments Car, personal and student loans, card minimums – not rent.
`front`	No	Housing ratio (front-end) (%)
`rules`	No	Lender rules UAE banks cap all installments at 50% of salary and the loan at a share of the price; US lenders use DTI guidelines and PMI.	us
`years`	No	Loan term (years)
`income`	No	Gross annual income Before tax – in the UAE, gross monthly salary × 12.
`costsPct`	No	Purchase costs paid in cash (%) DLD 4%, agent 2% + VAT, bank and registration fees – about 7.5% of the price with a mortgage.
`currency`	No	Currency	USD
`insurance`	No	Home insurance / year
`propertyTax`	No	Property tax (% / yr)

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 2, 2026

addedInput schema / properties / buyer

Added value: +{
+  "default": "expat",
+  "description": "Buyer and home",
+  "enum": [
+    "expat",
+    "national",
+    "second"
+  ],
+  "type": "string"
+}

addedInput schema / properties / costsPct

Added value: +{
+  "default": 7.5,
+  "description": "Purchase costs paid in cash (%) DLD 4%, agent 2% + VAT, bank and registration fees – about 7.5% of the price with a mortgage.",
+  "maximum": 20,
+  "minimum": 0,
+  "type": "number"
+}

changedInput schema / properties / debts / description

Previous value: -"Monthly debt payments Car, student, card minimums, etc."New value: +"Monthly debt payments Car, personal and student loans, card minimums – not rent."

changedInput schema / properties / down / maximum

Previous value: -1000000000New value: +10000000000

addedInput schema / properties / hoa

Added value: +{
+  "default": 0,
+  "description": "HOA dues / month",
+  "maximum": 10000000,
+  "minimum": 0,
+  "type": "number"
+}

changedInput schema / properties / income / description

Previous value: -"Gross annual income"New value: +"Gross annual income Before tax – in the UAE, gross monthly salary × 12."

addedInput schema / properties / pmi

Added value: +{
+  "default": 0.5,
+  "description": "PMI rate (under 20% down) (% / yr) Yearly % of the loan; ask your lender for a quote. 0 to ignore.",
+  "maximum": 5,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / rules

Added value: +{
+  "default": "us",
+  "description": "Lender rules UAE banks cap all installments at 50% of salary and the loan at a share of the price; US lenders use DTI guidelines and PMI.",
+  "enum": [
+    "us",
+    "ae"
+  ],
+  "type": "string"
+}

First observedOct 12, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered. The description adds some genuine methodology context (the 28/36 rule and the UAE 50%-of-salary / 80%-LTV caps), but it omits how the two 'rules' modes diverge in output, that every parameter is optional and defaulted, and the trailing web-page URL is inert for an agent under openWorldHint=false.

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?

Three short sentences, front-loaded with the most concrete signal (the worked example), with no filler prose. The calcbright.com URL is the one element that does not earn its place for an agent that cannot browse.

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?

The worked example effectively communicates the return value (a maximum affordable home price) despite there being no output schema. With all 15 parameters optional, defaulted and fully described in the schema, and safety covered by annotations, nothing critical is missing. A worked example plus rule framing is right-sized for a calculator of this complexity.

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 description coverage is 100%, so the schema already documents all 15 parameters thoroughly, including the 'rules' enum's US vs UAE meaning. The 28/36 and 50%/80% phrasing in the description merely echoes what the schema's own 'rules', 'front' and 'dti' descriptions already state, so it adds little beyond the baseline.

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 names the resource (home affordability calculator) and anchors it with a concrete input→output example ('$100,000 a year buys about a $337,657 home'), which makes the tool's function unmistakable. It also hints at scope via the two rule regimes, though it never explicitly distinguishes itself from close siblings like rent_affordability_calculator, dti or down_payment_calculator.

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?

Usage is only implied: an agent can infer you supply income plus loan assumptions to get a max purchase price. There is no explicit 'use this when…' statement, no mention of prerequisites, and no routing to or away from alternatives such as mortgage_calculator or rent_affordability_calculator.

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

All CalcBright Calculators 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?