FreeDailyPro Calculators

converters_affordability

Read-onlyIdempotent

Home affordability and debt-to-income calculator: maximum home price at the 28/36 guideline and 31/43 stretch limits

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ratePct": "<ratePct>"
    },
    "name": "converters_affordability"
  }
}

Input Schema

Name	Required	Description
`vaUse`	No	VA funding fee class (VA loans only).
`years`	No	Term in years (default 30).
`ratePct`	Yes	Annual mortgage rate in percent.
`loanType`	No	Default conventional.
`homePrice`	No	A price to check: adds the front and back ratios and a verdict for it.
`hoaMonthly`	No	Monthly HOA dues.
`pmiRatePct`	No	Conventional PMI rate in percent of the loan a year (default 0.6).
`downPayment`	No	Down payment as an amount. Send this or downPaymentPct (default 20%).
`annualIncome`	No	Gross yearly income. Send this or monthlyIncome.
`maxBackEndPct`	No	Your own total-debt-ratio limit in percent.
`monthlyIncome`	No	Gross monthly income.
`downPaymentPct`	No	Down payment as a percent of the price.
`maxFrontEndPct`	No	Your own housing-ratio limit in percent. When either limit is sent the response has one 'custom' result instead of guideline and stretch.
`propertyTaxPct`	No	Yearly property tax as a percent of the price (default 1.1).
`otherMonthlyDebts`	No	Other monthly debt payments (car, cards, student loans).
`homeInsuranceAnnual`	No	Yearly homeowners insurance.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description adds genuine context by naming the two output profiles the calculator returns (guideline vs stretch), which helps the agent anticipate the response shape despite there being no output schema.

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

Conciseness5/5

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

A single dense sentence that front-loads the tool's identity and ends with the concrete output. No filler or redundant restatement of the name.

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?

Given a 16-param tool with full schema coverage and no output schema, the description plus schema cover the essentials. It stops short of explaining what the 28/36 and 31/43 ratios mean or how custom limits alter the response, but the schema fills the custom-result detail, so nothing critical for correct invocation is missing.

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% across all 16 parameters, so the schema already carries full semantics including enums and defaults. The description adds no parameter-level detail beyond the schema, making baseline 3 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?

States a specific verb+resource ('Home affordability and debt-to-income calculator') and concretely says what it produces (maximum home price at 28/36 and 31/43 limits). It is distinguishable from converters_mortgage and calculate_loan by its affordability/DTI focus, though it never names those siblings explicitly.

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 implied by the name and the 28/36–31/43 phrasing, but there is no explicit when-to-use, when-not, or pointer to converters_mortgage/converters_refinance for related queries. An agent can infer the context but gets no routing guidance.

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

All FreeDailyPro 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?