Skip to main content
Glama

Senaro Personal Finance

Refinance Break-Even Analysis

calculate_refi_breakeven
Read-onlyIdempotent

Calculation, not advice. Verify with a professional before acting. Deterministic mortgage refinance break-even analysis. Given your current loan (balance, rate, remaining term) and a refinance offer (new rate, new term, closing costs, optional points), computes:

  • monthly P&I savings;

  • the cash-flow break-even month (total refinance cost divided by monthly savings, CFPB convention);

  • the lifetime interest delta over your remaining-term horizon;

  • a term-matched scenario that isolates the rate cut from a term reset;

  • a term-reset-trap flag (lower payment but higher lifetime interest from extending the term); and

  • the economic break-even (net-worth crossover) month using an equal-outflow invest-the-savings model.

Rate-and-term refis only (cash-out and tax effects are out of scope).

Pick this when refinancing your existing mortgage into a new rate and term is the question; pick compare_mortgage_terms when comparing two mortgage structures on a purchase you have not yet taken out.

All defaults cite primary sources (LodeStar/ALTA closing-cost data, CFPB break-even convention). Scalar output, no chart series.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pointsNoDiscount points paid at closing, where 1.0 means 1% of the loan. Decimal from 0 to 4. Optional; defaults to 0 when omitted.
chart_titleNoReserved for the chart pipeline; validated but not yet used. Must not contain em-dashes or en-dashes. Max 120 characters. Optional.
closing_costsNoExplicit closing costs in dollars, excluding points; total upfront cost is closing_costs plus the points cost. Decimal from 0 to 1,000,000,000. Optional; omitting it uses the cited default of 0.67% of the loan (LodeStar 2026). An IMMEDIATE break-even requires total upfront cost to be zero (or non-positive) AND monthly_savings to be non-negative, i.e. closing_costs AND points both 0, not closing_costs alone; a zero-total-cost refi into a worse deal (negative monthly_savings) reports NEAR_ZERO_OR_NEGATIVE_SAVINGS instead.
current_balanceYesOutstanding principal you would refinance. Decimal, greater than 0 and at most 1,000,000,000. REQUIRED, no default.
new_term_monthsYesThe new loan term in months. Integer from 1 to 480. REQUIRED, no default.
new_annual_rate_pctYesThe offered refinance rate as a percentage. Decimal from 0 to 20. REQUIRED, no default.
roll_costs_into_loanNoWhether closing costs and points are added to the new principal instead of paid upfront; cash-flow break-even then reports COSTS_ROLLED_INTO_LOAN. Optional; defaults to false when omitted.
investment_return_pctNoAnnual return used for the economic (invest-the-savings) break-even, an EFFECTIVE ANNUAL rate; the monthly compounding step is (1+pct/100)^(1/12)-1. Decimal from 0 to 30. Optional; omitting it uses the cited long-run S&P 500 nominal total-return default, about 10%; call list_defaults for the exact current value.
remaining_term_monthsYesMonths left on the current loan. Integer from 1 to 480. REQUIRED, no default.
current_annual_rate_pctYesCurrent loan's annual rate as a percentage, e.g. 6.5 not 0.065. Decimal from 0 to 20. REQUIRED, no default.
current_monthly_paymentNoYour actual statement P&I payment. Decimal, greater than 0 and at most 1,000,000,000. Optional; when supplied it overrides the formula-derived payment, so match your statement.
compute_economic_break_evenNoWhether to compute the economic (net-worth crossover) break-even. When false, only the cash-flow break-even and interest delta are returned, and economic_break_even reports NOT_REQUESTED. Optional; defaults to true when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the description builds on that. It adds meaningful behavioral context: deterministic calculation, scalar output with no chart series, 'calculation, not advice', source-cited defaults, and a term-reset-trap flag. This exceeds a baseline 3, though it does not describe the exact response envelope or error codes, which are not covered by an 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.

Conciseness4/5

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

The description is longer than minimal but every sentence earns its place: it front-loads the disclaimer, uses a concise bulleted output list, and closes with scope/alternatives. It could be tightened slightly by removing redundant phrasing like 'Calculation, not advice' but overall it is structured for scanning.

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 complex tool with 12 parameters, no output schema, and many computed results, the description is complete enough: it lists all six output categories, states the scope limitations, and references defaults sources. It does not enumerate output types or exact return conventions, but the parameter schema already documents the most intricate edge behaviors, so nothing critical prevents correct selection and invocation.

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 itself thoroughly explains every parameter, including default values and edge cases. The description only frames inputs at a high level ('closing costs, optional points') without increasing per-parameter meaning. Baseline 3 is appropriate when the schema carries the semantic load.

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?

The description states a specific verb ('calculates'), a clear resource ('mortgage refinance break-even analysis'), and enumerates the exact outputs. It also explicitly contrasts with sibling 'compare_mortgage_terms', so an agent can distinguish them without inspecting 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?

It gives explicit when-to-use guidance: 'pick this when refinancing your existing mortgage into a new rate and term is the question' and names the alternative for purchases not yet taken out ('compare_mortgage_terms'). It also states scope exclusions ('Rate-and-term refis only (cash-out and tax effects are out of scope)') and includes a professional-verification caution.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources