Senaro Personal Finance
Server Details
Credit card payoff, mortgages, refinancing, 401(k), rent vs buy. Every rule and default is cited.
- Status
- Healthy
- Uptime
- 100.0% over 48 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 18 tools
Every tool description carries explicit routing guidance ('pick this over X when ...'), and near-neighbor clusters such as calculate_cc_payoff / compare_payoff_strategies / compare_debt_consolidation / analyze_cash_advance, or calculate_emergency_fund / calculate_runway, are each carved apart by input shape and question type. calculate_compound_interest, calculate_opportunity_cost, and compare_payoff_vs_invest are similarly separated by what the alternative use of money is. No two tools share the same purpose, and the boundaries are stated rather than implied.
Names are uniformly snake_case and follow a verb_noun pattern: analyze_*, calculate_*, compare_*, list_*, optimize_*. The verb prefix also encodes the tool's role (single-scenario analysis vs. side-by-side comparison vs. reference lookup), which makes the set predictable. The only noun-only name, server_info, is a conventional MCP metadata tool and does not disrupt the pattern.
18 tools sit slightly above the comfortable 3-15 band, but each one covers a distinctly different personal-finance question (cards, mortgage, PMI, DTI, refi, rent-vs-buy, 401k, runway, defaults, metadata) rather than duplicating coverage. The two reference tools (list_defaults, server_info) are cheap additions, so the surface is not padded with filler.
The domain is stateless financial calculation, and the surface covers the main lifecycle: debt payoff, consolidation, mortgage purchase/refi/PMI, DTI qualification, liquidity sizing, opportunity cost, and 401(k) matching, plus a defaults catalog for assumptions. Gaps are minor and disclosed in-tool (no ARM mortgages, no FHA MIP modeling, no tax-filing or investment-portfolio return modeling), which agents can note but not work around.
Available Tools
18 toolsanalyze_cash_advanceCash Advance AnalyzerARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Deep analysis of a single card's cash advance showing payment allocation, CA interest cost, CA payoff months, and whether the CA is growing. Pick this over calculate_cc_payoff when one card's cash advance is the question: it shows how the CARD Act above-minimum allocation rule, 15 U.S.C. §1666c(b)(1), sends payment above the minimum to the highest-APR segment first, which is the cash advance whenever its rate is the higher one. Pick calculate_cc_payoff for a payoff timeline across several cards or a windfall schedule. The response includes chart_hints with rendering directives any client can use.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| minimum_payment | No | Issuer-stated minimum payment. Decimal, at least 0, at most 2 decimal places. Optional; defaults to auto-calculate when omitted. When supplied, this DOES bind: the per-month mandatory payment is min(max(the representative formula's minimum recomputed from the balance, minimum_payment), the remaining balance, total_monthly_payment). This differs from calculate_cc_payoff's default dynamic path, where the identically-named minimum_payment is parsed and validated but never applied unless fixed_payments = true: the two tools do not share behavior for this parameter, only its name. | |
| purchase_apr_pct | Yes | Purchase APR as a percentage, e.g. 24.99 not 0.2499. Decimal from 0 to 100. REQUIRED, no default. | |
| purchase_balance | Yes | Current balance carrying the purchase APR. Decimal, at least 0. REQUIRED, no default. | |
| cash_advance_apr_pct | Yes | Cash advance APR as a percentage. Decimal, greater than 0, at most 100. This tool has no promo input, so 0 is rejected: nothing would say when a 0% rate ends. For a promotional cash advance, use calculate_cc_payoff with a cash_advance segment carrying promo_expires_month and revert_apr_pct. REQUIRED, no default. | |
| cash_advance_balance | Yes | Current balance carrying the cash advance APR. Decimal, greater than 0. REQUIRED, no default. | |
| cash_advance_fee_min | No | Minimum dollar cash advance fee, e.g. 10 for $10. Decimal, at least 0. Optional; defaults to 0 when omitted. | |
| cash_advance_fee_pct | No | Cash advance fee as a percentage of the advance, e.g. 5 for 5%. Decimal, at least 0 and at most 100. Optional; defaults to 0 when omitted. | |
| total_monthly_payment | Yes | Total payment applied across both balances this month. Decimal, greater than 0, at most 2 decimal places. REQUIRED, no default. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real behavioral context: the CARD Act §1666c(b)(1) above-minimum allocation rule that drives the computation, the fact that the response carries chart_hints rendering directives, and an explicit not-advice disclaimer. It stops short of describing failure modes or input validation behavior, so 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but mostly earning its sentences; the allocation-rule explanation and output inventory are load-bearing. Minor redundancy: calculate_cc_payoff is named twice for routing, and the leading disclaimer boilerplate occupies the highest-value front position before the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does name the computed outputs (allocation, CA interest cost, payoff months, growth flag) and flags chart_hints, which is enough for an agent to know what comes back. Return shape and units are still only implied, so a small gap remains for a 9-parameter analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already carries all nine parameter semantics, including the cross-tool note about minimum_payment. The description adds no parameter-level meaning of its own, which is the correct baseline-3 situation when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('deep analysis of a single card's cash advance') and enumerates exactly what it reports: payment allocation, CA interest cost, CA payoff months, and whether the CA is growing. It names the sibling it is not (calculate_cc_payoff) and the condition that separates them, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit two-way routing: 'Pick this over calculate_cc_payoff when one card's cash advance is the question' and 'Pick calculate_cc_payoff for a payoff timeline across several cards or a windfall schedule.' It even notes the parameter-level divergence (minimum_payment binding here vs. not in the sibling), which is unusually precise guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_pmi_removalPMI Removal AnalysisARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Compute every standard PMI-removal pathway:
HPA automatic at 78% LTV
HPA borrower-requested at 80% LTV
optional re-appraisal at a simplified 75% of current market value; the actual Fannie Mae ceiling is seasoning- and property-type-dependent, 75% for a one-unit home seasoned two to five years, 80% for five-plus, and 70% for investment and two- to four-unit properties
Also returns current monthly PMI cost, total PMI dollars between now and automatic removal, and the effective annual return of paying the gap-to-80% (of the original value) as a lump sum today.
Supplying original_loan_term_months and loan_age_months also applies the 12 U.S.C. 4902(c) statutory final-termination midpoint, which bounds automatic removal at the earlier of the 78% schedule and that midpoint where HPA applies and the borrower is current.
Pairs with calculate_refi_breakeven for a refinance's rate-and-term break-even, and with compare_mortgage_terms when choosing between purchase mortgages. Scope: conventional mortgages only; FHA loans use MIP (Mortgage Insurance Premium) with different rules. This tool does not model MIP.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| annual_rate_pct | Yes | Mortgage APR as a percentage. Decimal from 0 to 20. REQUIRED, no default. | |
| current_balance | Yes | Today's loan balance. Decimal, greater than 0. REQUIRED, no default. | |
| loan_age_months | No | Months elapsed since origination. Integer from 0 to 480. Optional. Cannot exceed original_loan_term_months when both are supplied. Supplying either one without the other is rejected; both are required together. See original_loan_term_months. | |
| monthly_payment | Yes | Current P&I monthly payment, excluding tax, insurance, and PMI. Decimal, greater than 0. REQUIRED, no default. | |
| current_home_value | No | Current market value of the home. Decimal, greater than 0. Optional. When supplied AND greater than the HPA original value (the lesser of purchase price and any closing appraisal), the response also computes the re-appraisal pathway (some lenders allow PMI removal based on current market value with a fresh appraisal). | |
| annual_pmi_rate_pct | No | Annual PMI as a percentage of the current loan balance. Decimal from 0 to 5. Optional; omitting it uses the cited 0.5 default. Typical conventional-loan PMI ranges from 0.3% to 1.5%. | |
| extra_monthly_payment | No | Extra principal paid each month beyond the regular payment. Decimal, at least 0. Optional; defaults to 0 when omitted. | |
| original_purchase_price | Yes | What you paid for the home (the purchase-price side of the HPA basis; when a closing appraisal is lower, see original_appraised_value). Decimal, greater than 0. REQUIRED, no default. | |
| original_appraised_value | No | The home's appraised value at closing. Decimal, greater than 0. Optional. HPA sets the PMI trigger basis to the LESSER of purchase price and this appraisal (12 U.S.C. 4901); supply it when your closing appraisal came in below the purchase price. | |
| original_loan_term_months | No | The loan's original term in months. Integer from 1 to 480. Optional. Supplied together with loan_age_months, this computes the 12 U.S.C. 4902(c) statutory final-termination midpoint (12 U.S.C. 4901(7)) and bounds automatic_removal at the earlier of it and the 78% schedule date, where HPA applies and the borrower is current. Supplying either one without the other is rejected; both are required together. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial context: it is a calculation, not advice; it computes statutory midpoint behavior; the re-appraisal pathway depends on supplying current_home_value; and it does not model MIP. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the caveat 'Calculation, not advice,' then uses a bulleted list for pathways, followed by outputs, boundary conditions, statutory notes, and sibling routing. Every sentence adds distinct information, and there is no filler despite the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with no output schema, the description covers core outputs, exclusions, related tools, conditional parameters, and statutory boundaries. The only gap is that it does not specify the exact response object shape, but the schema's parameter descriptions and the listed outputs are sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real domain meaning beyond the schema: the HPA basis uses the lesser of purchase price and appraisal, current_home_value triggers the re-appraisal pathway, and original_loan_term_months plus loan_age_months activates the 12 U.S.C. 4902(c) midpoint. This earns an above-baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Compute') and resource ('every standard PMI-removal pathway'), then enumerates HPA automatic, borrower-requested, and re-appraisal pathways. It also lists concrete outputs and distinguishes itself from sibling mortgage tools via its conventional-only scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names related tools—calculate_refi_breakeven and compare_mortgage_terms—and states when they pair with this tool. It also draws a clear boundary: conventional mortgages only, FHA/MIP excluded. This gives an agent enough information to select the correct tool without opening schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_cc_payoffCredit Card Payoff CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Calculate credit card payoff timeline with month-by-month amortization. Pick this for a payoff timeline across credit cards under one strategy, including windfalls or fixed payments; pick compare_payoff_strategies to compare avalanche against snowball, calculate_loan_payoff for a single installment loan, and analyze_cash_advance when one card's cash advance is the question. Supports dual APR segments (purchase + cash advance), two strategies (avalanche, snowball), fixed/dynamic payment modes, and an optional schedule of one-time windfalls (tax refund, bonus, inheritance) applied at specific months.
Returns:
debt-free date, total interest, per-card payoff order
first_month_interest_ratio_frac (the first month's interest/payment fraction) and lifetime_interest_ratio_frac (whole-projection total_interest/total_paid fraction)
domain warnings emitted as warnings[].type (DEATH_SPIRAL, CA_TRAP, MIN_PAYMENT_TRAP, DAY_ZERO_COST, DEBT_GROWING, PROMO_CLIFF, PREDATORY_RATE, SPEND_EXCEEDS_PAYDOWN, PLAN_TERM_ELAPSED_WITH_BALANCE, NO_PAYOFF_WITHIN_PROJECTION), and, separately, validation disclosures emitted as warnings[].code (e.g. MINIMUM_PAYMENT_NOT_BINDING on the default dynamic-budget path, MINIMUM_PAYMENT_NOT_BINDING_IN_BASELINE when fixed_payments = true; these two shapes coexist in the same warnings[] array but are distinguishable by which keys each entry carries)
when a plan exists (extra_monthly_payment > 0, windfalls present, or fixed_payments = true), a min_payments_only baseline block with interest_saved_vs_min_payments and months_saved_vs_min_payments, the interest and time difference versus paying minimums only; when windfalls are also present the response additionally gains a baseline vs with_windfalls savings block with months_saved_vs_baseline and interest_saved_vs_baseline
The response echoes strategy (canonical lowercase 'avalanche' | 'snowball', the strategy the plan was actually simulated under) at the top level.
The response includes chart_hints with rendering directives any client can use.
Top-level entered_starting_balance echoes the caller's supplied balances by segment type (total, purchase, cash_advance, balance_transfer, promotional, installment_plan), before any fee, recurring spend, or interest posts; total is the sum of the other five. Top-level total_purchase_segment_fees_paid reports the portion of card fees (plan_fees_monthly plus annual_fee accruals) charged to the purchase segment across the projection, also present on every monthly_totals[] and analysis.buckets[] row.
These month counts are each a {status, value, explanation} object rather than a bare month count: months_to_payoff, card_payoff_order[].payoff_month, min_payments_only.months, minimums_only_baseline.months, and, when windfalls are supplied, baseline.months and with_windfalls.months. status is "defined" with an integer value when that plan reaches a zero balance, and "none" with value null when it does not, in which case explanation says why. The four savings fields (interest_saved_vs_min_payments, months_saved_vs_min_payments, months_saved_vs_baseline, interest_saved_vs_baseline) are {status, value, explanation} objects too: "defined" with the difference only when both compared runs reach a zero balance, and "none" with value null otherwise, in which case explanation names each run that does not.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | Credit cards to pay off, 1 to 20. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error ("cards is required and must be an array."); the two are not the same rejection. Every card may carry segments[]. Max 100 segments total across all cards in the request. Per-card, per-type caps: 1 purchase, 1 cash_advance, 5 balance_transfer, 1 promotional, 10 installment_plan. | |
| output | No | Valid values: 'summary' (default), 'inline'. summary returns a compact response with a data_preview block; inline returns the full payload. | |
| strategy | No | Payoff order: 'avalanche' pays the highest APR first, 'snowball' the smallest balance first. Optional; defaults to 'avalanche' when omitted. Matched case-insensitively, and the response echoes the canonical lowercase form actually simulated. | |
| windfalls | No | One-time principal payments, at most 12, e.g. a tax refund or a year-end bonus. Optional; a JSON null is treated as omitted. When non-empty the response gains baseline, with_windfalls, months_saved_vs_baseline, interest_saved_vs_baseline, windfalls_applied[] and windfalls_unused[]; an empty array returns the same shape as omitting it. | |
| chart_title | No | Override for the chart title. Optional; must not contain an em dash or en dash. Max 120 characters. | |
| per_segment | No | Whether each schedule row carries its per-segment breakdown. Optional; defaults to true when omitted. | |
| full_schedule | No | Whether to return the full per-card month-by-month schedule. Optional; defaults to false when omitted. The per-card monthly_schedule is capped at 1000 rows total across cards and months, so later months are omitted on a long multi-card payoff; the portfolio-level monthly_totals series is always complete and is the one to read for the whole timeline. | |
| apply_rate_cap | No | Whether to cap each card's APR at the regulatory ceiling before simulating. Optional; defaults to false when omitted. | |
| fixed_payments | No | Whether to hold each card's payment constant for the whole payoff. Optional; defaults to false when omitted. When true, each card's payment is locked at max(cards[].minimum_payment, that card's issuer minimum computed at month 1), and the total monthly budget (those locked amounts plus extra_monthly_payment) is held constant for the whole payoff, so once a card is paid off its freed-up payment rolls forward onto the remaining cards. This is the ONLY mode in which cards[].minimum_payment affects calculate_cc_payoff's result; compare_payoff_strategies has no fixed_payments parameter and binds minimum_payment on both of its strategy arms regardless. | |
| extra_monthly_payment | No | Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums. Optional; defaults to 0 when omitted. | |
| include_card_timeline | No | Whether to add the card_timeline block, a per-card view of when each card clears. Optional; defaults to false when omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it enumerates the warning taxonomy by type vs code, discloses that min_payments_only baselines only appear when a plan exists, and explains that the {status,value,explanation} shape returns 'none' when a run never reaches zero. Since there is no output schema, this return-semantics disclosure is exactly the burden the description must carry, and it carries it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and sibling routing are front-loaded, which is good, but the returns block becomes a dense multi-clause run-on covering warnings, baseline blocks, echo fields, and status objects without headers or bullets. The content is largely non-redundant given the missing output schema, but the packaging makes it hard to scan and some sentences chain five or more clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter, deeply nested calculator with no output schema, the description supplies the return structure (debt-free date, interest, payoff order, chart_hints, ratio fields, baseline savings blocks) and the failure semantics of month-count and savings objects. Combined with a 100%-covered input schema, an agent has what it needs to call this correctly and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 11 parameters including the fixed_payments/minimum_payment interaction and windfall entry shape. The description adds almost nothing parameter-specific beyond noting windfalls or fixed payments as mode selectors and that an empty windfalls array matches omitting it — useful but marginal. Baseline 3 is the right level when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate credit card payoff timeline with month-by-month amortization') and immediately scopes it to multi-card payoff under one strategy. It names the three nearest siblings (compare_payoff_strategies, calculate_loan_payoff, analyze_cash_advance) and the condition that selects each, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-pick guidance: 'pick this for a payoff timeline across credit cards under one strategy, including windfalls or fixed payments', plus named alternatives for strategy comparison, single installment loans, and cash-advance questions. The mode qualifiers (windfalls, fixed payments) tell the agent which optional inputs make this the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_compound_interestCompound Interest CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Standard compound interest calculator. Returns future value, total contributions, interest earned, effective annual rate, and milestones. Pick this for a balance that grows with contributions. Pick calculate_opportunity_cost when the money is recurring spending being priced against investing, and calculate_loan_payoff when the balance amortizes down under a fixed payment. The response includes chart_hints with rendering directives any client can use.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Time horizon in years. Integer, at least 1. REQUIRED, no default. | |
| principal | Yes | Starting balance. Decimal, at least 0. REQUIRED, no default. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| annual_rate_pct | Yes | Annual interest rate as a percentage, e.g. 7 not 0.07. Decimal from 0 to 100. REQUIRED, no default. | |
| rate_convention | No | 'nominal' or 'real'. 'real' unconditionally suppresses the inflation overlay; use when annual_rate_pct is already inflation-adjusted. Optional; defaults to 'nominal' when omitted. | |
| compounds_per_year | No | Compounding periods per year. Integer, greater than 0. Optional; defaults to 12 when omitted. | |
| inflation_rate_pct | No | Inflation rate as a percentage. Decimal: -1 (deprecated suppress, same as 0), 0 (no real-value overlay), or greater than 0 and less than 100 (explicit percentage, e.g. 3.5). Optional; defaults to 0 when omitted. | |
| monthly_contribution | No | Additional contribution added each month. Decimal, at least 0. Optional; defaults to 0 when omitted. | |
| apply_default_inflation | No | When true and inflation_rate_pct is 0, auto-selects inflation via MacroeconomicDefaults.ForHorizon. Ignored when inflation_rate_pct is greater than 0 or rate_convention is 'real'. Optional; defaults to false when omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, non-destructive profile. The description adds useful behavior beyond that: it discloses the full response shape (future value, total contributions, interest earned, effective annual rate, milestones) and the presence of chart_hints rendering directives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: calculation disclaimer, return values, use-case guidance, and chart_hints are each given one purposeful sentence. There is no filler or repetition of structured schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output list and chart_hints mention compensate for the absence of an output schema. Optional-parameter behaviors like inflation overlay and rate_convention are not described in prose, but the highly detailed schema covers them, so enough context exists for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'balance that grows with contributions' minimally reinforces principal and monthly_contribution, but the schema already provides complete meaning for all nine parameters, including units, defaults, and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('standard compound interest calculator') and enumerates the return metrics. It also distinguishes itself from sibling tools by naming what it is not, so an agent can pick it apart from calculate_opportunity_cost and calculate_loan_payoff without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool when a balance grows with contributions and names the conditions under which calculate_opportunity_cost or calculate_loan_payoff should be selected instead. The professional-verification caveat also frames when to treat results as advisory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_debt_to_incomeDebt-to-Income CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Calculate your debt-to-income ratio and check qualification for conventional, FHA, VA, and USDA mortgage programs. Accepts existing debts and an optional proposed new debt or home price. Pick this to measure DTI ratios and mortgage-program qualification against existing debts; pick compare_debt_consolidation when the question is whether a consolidation loan costs less than keeping the current credit cards, and pick compare_rent_vs_buy when the question is whether to buy a home at all rather than what DTI a given price implies.
Returns current DTI, front-end and back-end ratios with proposed housing, maximum affordable home price, and what-if scenarios showing the resulting DTI and which programs would then qualify if a given debt were paid off, plus income-increase and home-price-reduction variants. Includes the 10-month rule (Fannie Mae) for debts near payoff.
qualification.<program>.qualification_status is a tri-state verdict ('qualifies' | 'underwriting_dependent' | 'ineligible'):
'underwriting_dependent' means the manual-underwriting baseline is exceeded but further underwriting can still approve it, an automated-underwriting system for conventional and FHA, either automated or manual underwriting for USDA, or a supervisory underwriter's written justification under 38 CFR 36.4340(c)(2) for VA (never an automated decision), so
qualification.<program>.qualifies=falsedoes NOT by itself mean the borrower is blockedRead qualification_status, not the bare qualifies boolean, for the real answer;
qualification.<program>.noteexplains the specific underwriting or hard-cap context, naming which mechanism appliesVA's back-end overage alone never returns 'ineligible' either (38 CFR 36.4340(c)(2)/(c)(3) both contemplate approval above 41%), and conventional is now the only program that ever returns 'ineligible', since FHA, VA and USDA are each disclosure-only above their baselines
what_if.scenarios[].qualifies_vaandchanges_qualification_vaare decided on the scenario's unrounded VA ratio rounded to a whole percent under 38 CFR 36.4340(d), not onnew_back_end_dti_va(two decimals), so a scenario showing 41.44 can qualify;qualification.va.your_back_end_comparedstates the rounded figure VA's row compares withmax_back_end
| Name | Required | Description | Default |
|---|---|---|---|
| family_size | No | Household size for the VA residual income guideline. Supply family_size and property_state together, or neither. Optional; must be between 1 and 20. | |
| hoa_monthly | No | Monthly homeowners association dues in dollars. Optional; defaults to 0 when omitted. Must be zero or more. | |
| pmi_monthly | No | Monthly PMI (private mortgage insurance) in dollars. Optional; if omitted, auto-estimated at 0.5% of the loan annually when loan-to-value exceeds 80%. Feeds the conventional-basis PITI, so it moves with_proposed.front_end_dti, with_proposed.back_end_dti, with_proposed.front_end_breakdown, the conventional qualification row, and what_if.scenarios[].new_front_end_dti and new_back_end_dti. VA carries no PMI, and FHA and USDA always compute their own upfront-plus-annual mortgage insurance instead, at every loan-to-value, never this override. Must be zero or more. | |
| annual_income | No | Annual gross income in dollars, divided by 12 to get monthly income. Exactly one of gross_monthly_income or annual_income is required. Must be at least $0.01, one cent, the smallest amount of money. | |
| proposed_debt | No | A proposed new debt, as an alternative to proposed_home_price. Provide at most one of proposed_debt or proposed_home_price; providing neither computes the current DTI only. Optional; a JSON null is treated as omitted, the same as leaving the field out. | |
| existing_debts | No | Existing debts to include in the DTI calculation. Optional; omit it or send an empty array for no existing debts. A JSON null is rejected; omit the field instead. At most 50 debts are allowed. | |
| property_state | No | Two-letter USPS state code, or 'DC'/'PR'/'GU'/'VI'/'AS'/'MP'. Supply family_size and property_state together, or neither. Together these compute the VA residual income guideline (38 CFR 36.4340(e)) in va_residual_income_guideline: the dollar amount VA's tables require for this family size, region, and loan amount (derived from proposed_home_price; not computable without it), plus the 38 CFR 36.4340(c)(3) review-waiver figure. Computed only for family_size 1-7 and a property_state among the 50 states, DC, or PR (not GU, VI, AS, or MP; 38 CFR 36.4340(e) assigns no region to those four); outside those bounds, or without proposed_home_price, va_residual_income_guideline.status reads 'not_computable' with the reason instead. This block alone is a LOOKUP, not a verdict: it never compares against your actual residual income by itself. Optional. | |
| include_what_if | No | Whether to generate what-if scenarios showing how paying off a debt, increasing income, or reducing the home price would improve DTI. Optional; defaults to true when omitted. | |
| additional_income | No | Additional monthly income: side income, rental income, or bonuses. Optional; defaults to 0 when omitted. Must be zero or more. | |
| proposed_rate_pct | No | Proposed mortgage interest rate as a percent, e.g. 7.0 for 7.0%. Optional; the 7.0% default applies whenever this field is omitted, whether the proposal is proposed_debt or proposed_home_price. The default-rate warning fires only when proposed_home_price is used. Must be between 0 and 20. | |
| property_tax_annual | No | Annual property tax in dollars. Optional; if omitted, estimated at 0.88% of the proposed home price. Must be zero or more. | |
| proposed_home_price | No | Proposed home purchase price in dollars. Provide at most one of proposed_debt or proposed_home_price; providing neither computes the current DTI only. Auto-calculates full PITI (principal, interest, taxes, insurance). Optional; must be at least $0.01, one cent, the smallest amount of money. | |
| proposed_term_years | No | Proposed mortgage term in years. Optional; defaults to 30 when omitted. Must be between 1 and 40. | |
| transaction_purpose | No | Mortgage transaction purpose: 'purchase', 'refinance', or 'streamlined_assist'. Optional, defaults to 'purchase' when omitted. Affects USDA only, and only what is disclosed. USDA's 32% PITI and 44% Total Debt figures are purchase-transaction waiver conditions (HB-1-3555 11.3.A.2), disclosed rather than applied as ceilings: Senaro cannot observe how the file is underwritten, so a USDA ratio overage is never 'ineligible' on any transaction purpose. For a refinance, 11.3.B states debt ratios 'are not limited to the maximum purchase debt ratio thresholds', so where the note fires it names both figures and states that neither applies. Streamlined-assist refinances require no debt ratio calculation at all. Conventional, FHA and VA are unaffected. | |
| gross_monthly_income | No | Gross monthly income in dollars. Exactly one of gross_monthly_income or annual_income is required. Must be at least $0.01, one cent, the smallest amount of money. | |
| home_insurance_annual | No | Annual home insurance in dollars. Optional; if omitted, estimated at 0.65% of the proposed home price. Must be zero or more. | |
| proposed_down_payment_pct | No | Down payment as a percent of the proposed home price, e.g. 20 for 20%. Optional; defaults to 20 when omitted. Must be between 0 and 99.9 (100% cash purchases are not supported). | |
| va_funding_fee_financed_monthly | No | The additional monthly payment from financing a VA funding fee into the loan balance, if any. 38 CFR 36.4313(e)'s applicable percentage depends on down payment, prior VA-loan use, and service category, none of which Senaro collects, so there is no default. If omitted while any VA figure that depends on it is produced, meaning qualification.va.your_back_end and its verdict, any what_if VA ratio, what_if.max_affordable_home.va, or qualification.va.residual_income_comparison, a VA_FUNDING_FEE_NOT_MODELED warning discloses that no fee is assumed. The home-price-reduction what_if scenario's hypothetical price is fixed before the fee is considered, so a supplied fee is scaled to that EXACT hypothetical loan size, since 38 CFR 36.4313(e)'s fee is a percentage of loan principal. what_if.max_affordable_home.va is a two-pass approximation instead, so its supplied fee is scaled to an ESTIMATE of the hypothetical loan size, not the exact figure reported; the published price itself passes an exact forward VA check under 38 CFR 36.4340(d) with that reserved fee, and one dollar more fails it, so only this fee-scaling step is approximate. Without proposed_home_price there is no reference loan size to scale from either way, so the raw fee is reserved unscaled instead, and a VA_FUNDING_FEE_NOT_SCALED warning discloses it. This is mutually exclusive with VA_FUNDING_FEE_NOT_MODELED by construction, since one requires the fee omitted and the other requires it supplied. Optional; must be zero or more. | |
| monthly_maintenance_and_utilities | No | Estimated monthly maintenance and utilities for the proposed property. 38 CFR 36.4340 calls for a realistic estimate of this figure for the property and local utility rates and sets no numeric multiplier itself, but VA underwriting guidance (the Lender's Handbook, Pamphlet 26-7) publishes a per-square-foot multiplier for this same estimate. Applying it needs the property's square footage, which this tool does not currently collect, so Senaro has no default to offer here and you supply the aggregate monthly amount instead. Supplying BOTH this field and monthly_taxes_and_retirement_withholding, together with proposed_home_price and a computable family_size/property_state, computes qualification.va.residual_income_comparison: your ACTUAL monthly residual income, its ratio to the va_residual_income_guideline figure, and whether residual_income_meets_review_waiver_margin (residual income at or above 120% of the guideline) is met. The shelter expense used here excludes any PMI (VA loans carry no monthly PMI; 38 CFR 36.4313(e) sets a funding fee instead, commonly financed into the loan; see va_funding_fee_financed_monthly for the financed-fee field). 38 CFR 36.4340(c)(3)'s review-waiver condition is CONJUNCTIVE: it also requires the back-end debt-to-income ratio, rounded to a whole percent under 38 CFR 36.4340(d) (qualification.va.your_back_end_compared), to exceed 41%, which this field does not by itself confirm. Check both fields together. Even when both hold, (c)(3) only WAIVES a second-level review requirement; it is not itself an approval. Whether this file is actually approved is an underwriting determination Senaro does not make and no input combination here determines. Missing any one of the needed inputs reads qualification.va.residual_income_comparison.status 'not_computable' with every reason named. Optional; must be zero or more. | |
| monthly_taxes_and_retirement_withholding | No | Your federal, state, and FICA tax withholding, plus any amount paid or withheld for retirement, monthly. 38 CFR 36.4340(f)(13) treats these as one class of deduction from gross income. Optional; must be zero or more. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them: it discloses the tri-state `qualification_status` semantics, the meaning of the bare `qualifies` boolean, the CF A rounding rule for VA scenarios, and the conditional WARNING behavior for unmodeled VA fees. This is unusually rich behavioral context for a read-only calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and routing are correctly front-loaded, but the body is very long and duplicates blocks that the input schema already spells out verbatim (VA funding-fee scaling, PMI/tax/insurance defaults). For a domain this complex some length is earned, but the repetition with structured data costs it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 20 parameters, the description compensates well by describing return fields (current DTI, front/back-end ratios, max affordable price, what-if scenarios) and the tri-state verdict semantics. A few mechanics (e.g., what `changes_qualification_va` contains) are named but not fully unpacked, keeping it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter descriptions are themselves extremely detailed, so the schema does the heavy lifting. The description adds framing ('Accepts existing debts and an optional proposed new debt or home price') but no parameter-level syntax or constraints beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate your debt-to-income ratio and check qualification for conventional, FHA, VA, and USDA mortgage programs') and explicitly names the sibling tools it is not (`compare_debt_consolidation`, `compare_rent_vs_buy`). An agent can route to it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to pick this tool ('to measure DTI ratios and mortgage-program qualification against existing debts') and gives two named alternatives with the exact question each answers. This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emergency_fundEmergency Fund CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Size an emergency fund target based on the borrower's monthly essential expenses, job stability, dependents, and income redundancy. Returns a tier breakdown (minimum, target, conservative; the target row is omitted when it equals the 3-month minimum, and the conservative row is omitted when it equals the 12-month ceiling), the gap between current savings and the target, and time-to-target at the supplied monthly savings cadence. Pick this to size an emergency-fund target; pick calculate_runway when savings are already fixed and the question is how many months they will last, not what the target is. Pairs with debt-payoff content for the recurring 'save vs pay debt' question. Target months are clamped to [3, 12]: never below the 3-month personal-finance minimum, never above 12.
| Name | Required | Description | Default |
|---|---|---|---|
| dependents | No | Number of dependents. Integer from 0 to 20. +1 target month per dependent, capped at +3. Optional; defaults to 0 when omitted. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| job_stability | No | 'stable_w2' | 'variable_income' | 'self_employed' | 'between_jobs'. Drives the target-months multiplier: stable_w2 salaried W-2 with consistent paycheck (+0 months); variable_income W-2 with commission/bonus/shift-based pay (+1 month); self_employed 1099 contractor/freelancer/sole proprietor (+3 months); between_jobs actively job hunting, no current paycheck (+5 months). Optional; defaults to 'stable_w2' when omitted. | |
| current_savings | No | What you have in liquid emergency-accessible savings today. Decimal from 0 to $1,000,000,000. Optional; defaults to 0 when omitted. | |
| has_dual_income | No | When true, partner income reduces the buffer by 1 month. Optional; defaults to false when omitted. | |
| monthly_savings_capacity | No | What you can contribute toward the gap each month. Drives months_to_target. Decimal, either 0 or from $0.01 to $1,000,000,000. Optional; defaults to 0 when omitted. | |
| monthly_essential_expenses | Yes | Rent/mortgage + utilities + food + insurance + minimum debt payments. NOT discretionary spending. Decimal from $0.01 to $1,000,000,000. REQUIRED, no default. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds behavioral nuances beyond that: tier omission rules, clamping to [3,12], and the 'Calculation, not advice' caveat. It does not contradict annotations and adds algorithmic context. Slightly more depth (e.g., on error handling) could push to 5, but it is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-organized, starting with the core purpose and proceeding to outputs, usage guidance, and constraints. Every sentence earns its place, though it is somewhat long. It could be tightened without losing critical context, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains return values (tier breakdown, gap, time-to-target) and covers edge cases like tier omissions and clamping. It also includes the professional-verification caveat. For a calculator tool, nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter fully documented (types, ranges, defaults). The description summarizes the key inputs but does not add semantic detail beyond what the schema already states. Per the rubric, this is the baseline 3; it does not compensate or extend schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Size an emergency fund target based on the borrower's monthly essential expenses, job stability, dependents, and income redundancy.' It also names the output components (tier breakdown, gap, time-to-target), making the tool's function unmistakable. It directly differentiates from the sibling calculate_runway by contrasting the questions each answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit selection guidance: 'Pick this to size an emergency-fund target; pick `calculate_runway` when savings are already fixed and the question is how many months they will last, not what the target is.' Also adds context for the 'save vs pay debt' question, showing situational awareness. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_loan_payoffLoan Payoff CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Standard amortizing loan calculator. Pick this for a single fixed-rate installment loan (mortgage, auto, student, personal) with one amortization schedule; pick calculate_cc_payoff for a credit card, which carries revolving balances, multiple APR segments, and a snowball or avalanche strategy this tool does not model.
Returns:
monthly payment, total interest, and a payoff date (null when the loan does not clear within its term)
a bucketed Analysis suitable for chart rendering. The Analysis includes KPIs, annotations (e.g. crossover month), and summary strings
When extra_monthly_payment is supplied, every computed figure in the response outside with_extra describes this loan without the extra payment, including monthly_payment, payoff_months, total_paid, total_interest, remaining_balance_at_term, payoff_date, months_to_halfway_principal, months_to_interest_flip, and every value under analysis; a warnings[] entry names this.
The response includes chart_hints with rendering directives any client can use. This tool does not support output: 'inline' on any transport.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Valid values: 'summary' (default). 'summary' returns the full payload including analysis.buckets[] inline. | |
| loan_type | No | 'personal', 'auto', 'student', or 'mortgage'. Optional; defaults to 'personal' when omitted. | |
| principal | Yes | Loan principal to amortize. Decimal, greater than 0. REQUIRED, no default. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| term_months | Yes | Loan term. Integer, greater than 0. REQUIRED, no default. | |
| chart_bucket | No | Time-axis granularity of analysis.buckets[]: 'auto', 'monthly', 'quarterly', 'yearly', or 'biennial'. Optional; defaults to 'auto', which selects by term length (<=24 months: monthly; <=60: quarterly; <=360: yearly; else biennial). | |
| annual_rate_pct | Yes | Loan annual interest rate (the note rate in the loan contract, not the disclosed APR, which can differ when fees are financed), e.g. 6.5 not 0.065. Decimal from 0 to 100. REQUIRED, no default. | |
| extra_monthly_payment | No | Extra principal paid each month beyond the regular payment. Decimal, at least 0. Optional; defaults to 0 when omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive); the description adds non-obvious behavior the agent could not infer: when `extra_monthly_payment` is supplied, every top-level figure and every value under `analysis` describes the loan WITHOUT the extra payment, with a `warnings[]` entry naming this, and `payoff_date` is null when the loan does not clear within term. It also discloses that `output: 'inline'` is unsupported and that `chart_hints` provides rendering directives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads a disclaimer ('Calculation, not advice. Verify with a professional before acting.') before the purpose, which costs a sentence, but the rest is tightly organized into purpose, routing, and a returns block. The long field enumeration in the extra-payment paragraph is verbose yet necessary to the disclosure and is not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so: it names monthly payment, total interest, payoff date (with the null edge case), the bucketed Analysis with KPIs/annotations/summary strings, `chart_hints`, and `warnings[]`. For an 8-parameter calculation tool with edge cases, nothing needed to invoke or interpret it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so 3 is the baseline, but the description adds real semantics beyond the schema by explaining the counterintuitive effect of `extra_monthly_payment` on the other reported parameters and by listing the affected fields. It also flags the unsupported `output: 'inline'` value that the enum alone does not call out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Standard amortizing loan calculator') and pins the scope to a single fixed-rate installment loan with one amortization schedule. It explicitly names the sibling it is not — `calculate_cc_payoff` for revolving credit-card balances — 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule ('pick this for a single fixed-rate installment loan (mortgage, auto, student, personal)') paired with the when-not condition ('pick `calculate_cc_payoff` for a credit card, which carries revolving balances, multiple APR segments, and a snowball or avalanche strategy this tool does not model'). The contrast is concrete and operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_opportunity_costOpportunity Cost CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Calculate the true cost of recurring spending by showing what that money would be worth if invested. Pick this when the input is recurring spending. Pick calculate_compound_interest when the input is a balance and its contributions with no spending to price, and compare_payoff_vs_invest when the alternative to investing is paying down debt. The response includes chart_hints with rendering directives any client can use.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | What the spending is, e.g. 'coffee' or 'streaming subscriptions'. Optional. Max 120 characters. | |
| years | Yes | Time horizon in years. Integer, greater than 0. REQUIRED, no default. | |
| tax_year | No | Tax year, 2025 or 2026. Year 1 of the horizon, so the assumed sale of the investments falls in tax year tax_year + years - 1. Optional; defaults to 2026 when omitted. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| filing_status | No | Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax opportunity cost. | |
| tax_bracket_pct | No | Not used. Kept so older calls still work; an after-tax figure needs filing_status and annual_gross_income. Decimal from 0 to 100. Optional. | |
| monthly_spending | Yes | Monthly spending to price against investing. Decimal, at least $0.01. The opportunity cost of spending $0 is degenerate and is rejected. REQUIRED, no default. | |
| annual_return_pct | Yes | Effective annual investment return, e.g. 8 not 0.08; the monthly compounding step is (1+pct/100)^(1/12)-1. Decimal from 0 to 100. REQUIRED, no default. | |
| annual_gross_income | No | Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax opportunity cost. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a liability disclaimer ('Calculation, not advice. Verify with a professional before acting') and discloses that the response carries chart_hints rendering directives, which is useful context beyond the annotations. It does not elaborate further on output shape or edge-case handling, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Sentences are front-loaded with purpose and disclaimer, followed by routing guidance and an output note. Every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateless calculation tool with a fully documented schema and read-only annotations, the description covers purpose, routing, and output hint sufficiently. It mentions chart_hints but does not describe the numeric return shape, which leaves a small gap given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 nine parameters, including the conditional after-tax inputs and the deprecated tax_bracket_pct. The description adds no parameter-level syntax or defaults beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Calculate the true cost of recurring spending by showing what that money would be worth if invested') and explicitly distinguishes itself from two named siblings. An agent can tell it apart from calculate_compound_interest and compare_payoff_vs_invest without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit selection rule ('Pick this when the input is recurring spending') plus two named alternatives with the exact conditions that route to each (balance+contributions vs. debt payoff). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_refi_breakevenRefinance Break-Even AnalysisARead-onlyIdempotentInspect
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 (Senaro's formula: total refinance cost divided by monthly savings, rounded up to a whole month, built on the payback test the CFPB toolkit describes);
the interest delta over your remaining-term horizon, and each loan's interest over its whole schedule (the current loan's remaining term, the new loan's full term);
a term-matched scenario that isolates the rate cut from a term reset;
a term-reset-trap flag (a longer term and a lower payment, but more interest over the new loan's full term than over the current loan's remaining term); and
the economic break-even (net-worth crossover) month under an equal-outflow model: both sides spend the same each month; the side that keeps the current loan starts with the upfront refinance cost invested at month 0 (nothing when costs are rolled in); money not spent on a payment is invested at investment_return_pct. The search runs to the end of the longer loan term, and stops earlier where a loan's term ends with money still owed.
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, the CFPB toolkit's payback test). Scalar output, no chart series. payoff_months and payoff_month_shift use {status, value, explanation}; the two break-evens use {code, month, explanation}.
| Name | Required | Description | Default |
|---|---|---|---|
| points | No | Discount points paid at closing, where 1.0 means 1% of the loan amount: the current balance when costs are paid upfront, or, when roll_costs_into_loan is true, the new loan amount, which includes the financed closing costs and points. Decimal from 0 to 4. Optional; defaults to 0 when omitted. | |
| chart_title | No | Reserved for the chart pipeline; validated but not yet used. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| closing_costs | No | Explicit 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 current balance (LodeStar 2026). An IMMEDIATE break-even requires total upfront cost to be zero AND monthly_savings to be non-negative AND roll_costs_into_loan false, 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_balance | Yes | Outstanding principal you would refinance. Decimal, greater than 0 and at most 1,000,000,000. REQUIRED, no default. | |
| new_term_months | Yes | The new loan term in months. Integer from 1 to 480. REQUIRED, no default. | |
| new_annual_rate_pct | Yes | The offered refinance rate as a percentage. Decimal from 0 to 20. REQUIRED, no default. | |
| roll_costs_into_loan | No | Whether closing costs and points are added to the new principal instead of paid upfront. When true, points are a percentage of the new loan amount; cash-flow break-even reports COSTS_ROLLED_INTO_LOAN; and the economic break-even, when requested, compares the two loans with the financed costs in the new principal and no upfront cash. Optional; defaults to false when omitted. | |
| investment_return_pct | No | Annual return used for the economic (net-worth crossover) break-even, an EFFECTIVE ANNUAL rate: it compounds money not spent on a payment and, when costs are paid upfront, the upfront refinance cost that keeping the current loan leaves invested. 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_months | Yes | Months left on the current loan. Integer from 1 to 480. REQUIRED, no default. | |
| current_annual_rate_pct | Yes | Current loan's annual rate as a percentage, e.g. 6.5 not 0.065. Decimal from 0 to 20. REQUIRED, no default. | |
| current_monthly_payment | No | Your 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. Rounded to the cent, it must be greater than the first month's interest: current_balance rounded to the cent, times current_annual_rate_pct / 100 / 12, rounded to the cent. | |
| compute_economic_break_even | No | Whether to compute the economic (net-worth crossover) break-even. When false, economic_break_even reports NOT_REQUESTED; every other field is still returned. Optional; defaults to true when omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only/idempotent/non-destructive, and the description adds substantial context beyond them: it is deterministic and not advice, it names the exact break-even models and their assumptions (equal-outflow model, upfront cost invested at month 0, search horizon to end of longer term), discloses special status encodings (COSTS_ROLLED_INTO_LOAN, NEAR_ZERO_OR_NEGATIVE_SAVINGS, NOT_REQUESTED), and notes the scalar/no-chart-series output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the 'calculation, not advice' caveat and the core definition, then a dense bullet list where each item carries distinct information (formulas, sources, output encodings). It is long but nearly every sentence earns its place; the source citations and default provenance are the only slightly padded portion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers the return contract (scalar output, the {status,value,explanation} and {code,month,explanation} shapes), the model assumptions, scope limits, and where to get exact default values (list_defaults). An agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so 3 is the baseline. The description adds model-level meaning to how parameters interact — points being a percentage of the new loan amount when costs are rolled in, investment_return_pct being an effective annual rate with an explicit monthly compounding step, and the immediate-break-even condition requiring both closing_costs and points to be zero. That is real added semantics beyond field-level schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('deterministic mortgage refinance break-even analysis') and enumerates the exact quantities computed (monthly P&I savings, cash-flow break-even month, interest delta, term-matched scenario, term-reset-trap flag, economic break-even). It also names the sibling it is not (compare_mortgage_terms) and the distinction (existing loan refi vs. new purchase structure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: '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.' It also states scope exclusions (rate-and-term only; cash-out and tax effects out of scope).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_runwayCash Runway CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Deterministic cash-runway calculator. Given your liquid savings, monthly essential expenses, optional ongoing inflows (partner income, side income, severance paid as a monthly stream, unemployment benefits), and an optional expense-inflation rate, computes how many months the fund lasts before it hits zero, plus a month-by-month drawdown schedule.
Single scenario per call: to compare 'status quo' vs 'cutbacks' vs 'cutbacks + unemployment', call once per scenario with the matching expenses and inflows.
When inflows meet or exceed expenses (and expenses are not inflating), the fund does not draw down and a self-describing does-not-deplete outcome is returned instead of a month.
Yield on the fund is treated as 0% in v1 (conservative). All assumptions cite their source.
Pick this to project how many months current savings will last against expenses and inflows; pick calculate_emergency_fund when the question is the fund's target size, not how long it lasts.
HEAVY tool: use output='summary' (default) for the headline or output='inline' for the full schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Valid values: 'summary' (default), 'inline'. 'summary' returns headline scalars (depletion month or does-not-deplete) and citations with the schedule stripped. 'inline' returns the full payload including the month-by-month schedule[] for chart rendering. | |
| chart_title | No | Reserved for the chart pipeline; validated but not yet used. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| current_savings | Yes | Liquid fund available to draw down. Decimal from 0 to 1,000,000,000; 0 is valid (an already-empty fund). REQUIRED, no default. | |
| monthly_inflows | No | Ongoing monthly income that continues during the drawdown (partner income, side income, unemployment benefit, severance paid monthly), modeled as a flat monthly stream; a one-time severance lump and time-limited benefits are not modeled in v1. Decimal from 0 to 1,000,000,000. Optional; defaults to 0 when omitted. | |
| use_essential_expenses | No | Expense basis: true means essential-only spending (survival runway), false means total spending (current-pace runway). Labels the reported expense_basis. Optional; defaults to true when omitted. | |
| annual_inflation_rate_pct | No | Annual expense-inflation rate as a percentage. When greater than 0, expenses grow each month by the monthly equivalent of this annual rate; when 0, expenses are constant. Decimal, at least 0 and less than 100. Optional; defaults to 0 when omitted. | |
| monthly_essential_expenses | Yes | Monthly outflow at the chosen expense basis. Decimal, greater than 0 and at most 1,000,000,000. REQUIRED, no default. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: 'Calculation, not advice', 0% yield assumption in v1, the does-not-deplete edge case, and the HEAVY-tool output-mode behavior. These details go well beyond what the structured annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every section earns its place: safety disclaimer, core computation, single-scenario rule, edge-case behavior, assumptions, sibling differentiation, and output-mode warning. Key guidance is front-loaded and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying what summary returns ('headline scalars', 'depletion month or does-not-deplete', citations) and what inline returns ('month-by-month schedule[]'). It also covers assumptions, edge cases, and behavior limits sufficiently for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds interpretative meaning beyond the schema by framing current_savings as 'liquid savings', explaining that inflows include partner income, side income, severance-as-monthly-stream, and unemployment benefits, and clarifying the expense-inflation behavior in context. This is useful but somewhat redundant with already-rich schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a 'deterministic cash-runway calculator' that computes how many months a fund lasts before hitting zero. It also differentiates itself from calculate_emergency_fund by clarifying the question being answered is duration, not target fund size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Pick this to project how many months current savings will last' versus 'pick calculate_emergency_fund when the question is the fund's target size.' It also instructs users to call once per scenario for comparisons and to use output='summary' or 'inline' appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_debt_consolidationDebt Consolidation ComparisonARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Compares keeping cards vs. consolidation loan vs. optional balance transfer offers (single offer or head-to-head multi-offer comparison via bt_offers[]).
Supports partial balance transfers via bt_transfer_limit: transfers only up to that dollar amount (choosing cards by highest APR, highest balance, or manually), then runs a combined simulation of the BT card + remaining original-card balances together, so freed minimum payments are correctly redistributed.
Shows total cost, interest saved, monthly payment change, origination fee breakeven, hidden risks (reracking), promo-trap detection per offer, and what-if scenarios. Works with multiple cards including cash advance balances.
Pick this to weigh a consolidation loan (required input), plus any balance-transfer offers, against keeping current cards; pick calculate_cc_payoff for a single payoff timeline with no consolidation option, and pick compare_payoff_strategies to compare avalanche against snowball ordering on the cards as they stand.
The response includes chart_hints with rendering directives any client can use.
HEAVY tool: use output='summary' (default) for the headline comparison or output='inline' for the full payload.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | Credit cards to include, 1 to 20. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error ("cards must be a JSON array."); the two are not the same rejection. segments and stop_spend_month are not supported by this tool and are rejected; a non-zero monthly_spend, annual_fee, or plan_fees_monthly is rejected too, but zero (including an explicit 0) is accepted and dropped for all three: this tool always reads the flat purchase_balance / cash_advance_balance fields on each card below, never segments[] balances, and card-level fees and ongoing spend are not modeled here. Those five fields are supported by calculate_cc_payoff and compare_payoff_strategies instead. | |
| output | No | Valid values: 'summary' (default), 'inline'. summary: compact response with a data_preview block; no heavy array exists on this response today, so summary and inline are currently identical in content. inline: full payload (currently identical to summary; will diverge once a heavy array is added for chart rendering). | |
| bt_offers | No | Balance-transfer offers to compare head-to-head, 1 to 10, preferred over the four scalar bt_* fields above when comparing two or more offers: when supplied, bt_offers overrides bt_apr_pct, bt_promo_months, bt_regular_apr_pct, and bt_fee_pct, and their range checks are skipped. The response includes a balance_transfer_offers block with per-offer simulation results, selected_offer_index, selected_offer_label, selected_offer_reason, and all_offers_trap. Optional; a JSON null is rejected, unlike bt_manual_transfers and windfalls below, where a JSON null is treated as omitted. | |
| windfalls | No | One-time principal payments, at most 12, same shape as calculate_cc_payoff. Optional; a JSON null is treated as omitted, the same as leaving the field out. When non-empty, the response adds windfalls_applied[] and windfalls_unused[] on keep_cards, on each balance_transfer scenario (and on each offer in balance_transfer_offers.offers[]), on consolidation_loan (single-row per windfall since the loan is a single-balance instrument), and on optimized_consolidation.loan and optimized_consolidation.keep_subset (each windfall dollar is listed once across the two). All scenarios use with-windfalls totals so cross-option ranking stays apples-to-apples, except what_if.same_budget_accelerated, a windfall-free hypothetical about extra-payment behavior, not your actual lump-sum schedule. | |
| bt_apr_pct | No | Balance-transfer APR as a percentage, 0-100, e.g. 0 for a 0% promo. Required when include_balance_transfer is true and bt_offers is omitted. bt_offers, when supplied, overrides this and the other three bt_* scalars below. The 0-100 range applies only when include_balance_transfer is true and bt_offers is omitted; a non-number is rejected in every case. | |
| bt_fee_pct | No | Balance-transfer fee as a percentage of the transferred balance, 0-10. Optional; defaults to 3.0 when omitted. bt_offers, when supplied, overrides this. The 0-10 range applies only when include_balance_transfer is true and bt_offers is omitted; a non-number is rejected in every case. | |
| chart_title | No | Override for the chart title. Optional; must not contain an em dash or en dash. Max 120 characters. | |
| full_schedule | No | Whether to return the full month-by-month amortization schedule instead of the compact default. Optional; defaults to false when omitted. | |
| bt_promo_months | No | Balance-transfer promo period in months, 1-60. Optional; defaults to 18 when omitted. bt_offers, when supplied, overrides this. The 1-60 range applies only when include_balance_transfer is true and bt_offers is omitted; a non-number is rejected in every case. | |
| current_strategy | No | Your current payoff strategy, compared against the consolidation loan / balance-transfer alternative: 'avalanche' or 'snowball'. In partial consolidation it ranks the loan against the kept cards, and the part it ranks first, the loan or the kept cards, receives the extra payment and any windfalls. Optional; defaults to 'avalanche' when omitted. Case-sensitive. | |
| bt_transfer_limit | No | Cap on the total dollar amount transferred to the balance-transfer card, at least $0.01. When set, only this amount moves to the BT card; remaining balances stay on original cards, and a combined simulation runs both halves together, correctly redistributing freed minimum payments. Optional; when omitted, the entire balance is transferred (legacy behavior). Needs include_balance_transfer or bt_offers. | |
| bt_regular_apr_pct | No | APR that applies after the promo period ends, as a percentage, 0-100. Optional; defaults to 25.20 when omitted. bt_offers, when supplied, overrides this. The 0-100 range applies only when include_balance_transfer is true and bt_offers is omitted; a non-number is rejected in every case. | |
| consolidation_loan | Yes | Loan terms for the consolidation option. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error ("consolidation_loan must be an object."); the two are not the same rejection. | |
| bt_manual_transfers | No | Exact per-card transfer amounts. Required when bt_transfer_strategy is 'manual'; each entry's card_name must match a name in cards[]. Optional otherwise; a JSON null is treated as omitted, the same as leaving the field out. | |
| bt_transfer_strategy | No | How to choose which balances move when bt_transfer_limit is less than your total debt: 'highest_apr_first' (transfer from highest-APR segments first, maximizes interest savings), 'highest_balance_first' (transfer largest balances first), or 'manual' (use bt_manual_transfers to specify exact amounts per card). Optional; defaults to 'highest_apr_first' when omitted. Needs bt_transfer_limit. | |
| extra_monthly_payment | No | Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums for keep-cards and any balance transfer, and on top of the loan's own required payment for consolidation. In partial consolidation, the extra payment and any windfalls go to the part current_strategy ranks first, the loan or the kept cards. Optional; defaults to 0 when omitted. fixed_payments is not a parameter of this tool, unlike calculate_cc_payoff: the keep-cards baseline is always simulated under the canonical constant rolled-forward payment (see comparison_basis in the response); supplying fixed_payments returns an unknown_parameter error. | |
| include_balance_transfer | No | Whether to run a single-offer balance-transfer scenario using the four scalar bt_* fields below. Optional; defaults to false when omitted. Ignored once bt_offers is supplied; use bt_offers when comparing two or more offers. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantial context beyond that: it is a calculation not advice, it runs combined partial-transfer simulations, it reports hidden risks and promo-trap detection, and it is a heavy tool with summary/inline output modes. No annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical, but the 17-parameter nested schema justifies substantial detail. It is front-loaded with the purpose, disclaimer, and routing guidance, though some sentences duplicate schema-level documentation and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, nested inputs, 100% schema coverage, annotations, and no output schema, the description is complete enough for correct invocation. It covers required loan input, optional balance-transfer modes, partial-transfer behavior, and output-mode guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions bt_offers[], bt_transfer_limit, and output modes, but these details are already fully documented in the schema; it adds conceptual grouping rather than new parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific comparison: keeping cards vs. a consolidation loan vs. balance-transfer offers, including single-offer and multi-offer modes. It clearly distinguishes this tool from calculate_cc_payoff and compare_payoff_strategies by naming both alternatives and the conditions that select them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to pick this tool to weigh a consolidation loan plus optional balance-transfer offers against keeping current cards. It also names the sibling tools and when to choose them instead, so the agent has direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_mortgage_termsMortgage Terms ComparisonARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Compare two fixed-rate mortgage options side-by-side:
15 vs 30 year,
different rates,
points vs no points, or
any two terms.
Shows total interest, monthly payment breakdown (with tax, insurance, PMI, HOA), equity buildup, and, critically, what happens if you take the cheaper mortgage and invest the monthly savings. Finds the break-even investment return rate.
Includes tax deduction analysis (itemizing vs standard deduction), PMI auto-removal tracking per the Homeowners Protection Act, and, when invest_the_difference is on (the default) and filing_status and annual_gross_income are given, an after-tax net worth comparison.
Pick this to compare two mortgage structures on a purchase, such as 15 versus 30 year or points versus no points; pick calculate_refi_breakeven when the comparison is against your existing loan and a refinance offer, and pick compare_payoff_strategies when the question is payoff strategy on revolving debt, not a mortgage term.
Note: ARM (adjustable-rate) mortgages are not yet supported.
| Name | Required | Description | Default |
|---|---|---|---|
| option_a | Yes | The first fixed-rate mortgage option to compare. Required. | |
| option_b | Yes | The second fixed-rate mortgage option to compare, same shape as option_a. Required. Must differ from option_a on at least one of term_years, annual_rate_pct, or points. | |
| tax_year | No | Tax year, 2025 or 2026, selecting the IRS standard-deduction table for the itemize-vs-standard analysis. The after-tax view counts it as year 1 of the horizon, so the assumed sale of the investments falls in tax year tax_year + time_horizon_years - 1. Optional; defaults to 2026 when omitted. | |
| home_price | Yes | Home purchase price in dollars. Required. Must be positive and no more than $1,000,000,000. | |
| hoa_monthly | No | Monthly homeowners association dues in dollars. Optional; defaults to 0 when omitted. Must be zero or more and no more than $1,000,000,000. | |
| pmi_monthly | No | Monthly PMI (private mortgage insurance) in dollars, charged when down payment is below 20%. Optional; defaults to 0 when omitted. Must be zero or more and no more than $1,000,000,000. | |
| filing_status | No | Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax comparison. | |
| full_schedule | No | Whether to return the full month-by-month amortization schedule instead of the compact default. Optional; defaults to false when omitted. | |
| tax_bracket_pct | No | Marginal tax bracket as a percentage, 0-50. Optional; values the mortgage-interest deduction (interest_deduction_value) and the yearly deduction savings credited to each option's investments in the after-tax comparison. It is never applied to investment gains. | |
| closing_cost_pct | No | Closing costs as a percentage of the loan amount, 0-20, points excluded. Optional; defaults to the Urban Institute loan-size regressive schedule (about 4.6% at a $97K loan down to about 1.4% at a $679K loan) when omitted. Pass 0 to model zero closing costs. | |
| down_payment_pct | No | Down payment as a percent of home_price, e.g. 20 for 20%. Optional; defaults to 20 when omitted. Range 0-100 applies only when down_payment_amount is absent; when down_payment_amount is supplied, down_payment_pct is ignored entirely, including in provenance. | |
| standard_deduction | No | Standard deduction in dollars, compared against itemized mortgage-interest deductions. Optional; defaults to the IRS basic standard deduction for tax_year and filing_status when omitted (TY2026: 16100 single, 32200 married, 24150 head_of_household; TY2025: 15750 single, 31500 married, 23625 head_of_household; source Rev. Proc. 2025-32). Must be zero or more. | |
| time_horizon_years | No | Number of years to project the invest-the-difference comparison, 1-40. Optional; defaults to the maximum of both options' term_years when omitted. | |
| annual_gross_income | No | Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax comparison. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000. | |
| down_payment_amount | No | Down payment in dollars. Optional; overrides down_payment_pct entirely, including its provenance row, when supplied. Must be at least $0 and strictly below home_price. | |
| pmi_removal_ltv_pct | No | Loan-to-value percentage at which to model borrower-requested PMI removal, 50-100. Optional; when omitted, PMI is modeled as removed at the 78% HPA automatic-termination threshold instead. The rejection guard applies only when pmi_monthly is above 0 and the loan's own initial LTV is above 80 percent, the range where PMI applies: there, a value at or above that initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. When pmi_monthly is omitted or 0, no such check runs, whatever the LTV, and the supplied value is accepted but changes nothing in the response, because no PMI is modeled in that case. Either way PMI also stops at the statutory amortization midpoint of each option's own term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone. | |
| property_tax_annual | No | Annual property tax in dollars, for true monthly cost. Optional; defaults to 0 when omitted. Must be zero or more. | |
| extra_monthly_payment | No | Extra principal payment in dollars, applied equally to BOTH options every month. Optional; defaults to 0 when omitted. Must be zero or more and no more than $1,000,000,000. | |
| home_insurance_annual | No | Annual home insurance in dollars. Optional; defaults to 0 when omitted. Must be zero or more. | |
| invest_the_difference | No | Whether both options deploy the same total budget every month: the higher option's P&I plus any extra_monthly_payment plus the month-1 PMI both carry. The cheaper-mortgage holder invests the payment gap each month; an option that stops paying PMI earlier invests the freed cash; the option with the lower upfront points cost invests the difference at month 0; after payoff the full budget goes to investments. See comparison_basis in the response. Optional; defaults to true when omitted. | |
| investment_return_pct | No | Assumed investment return on the invested payment gap, as a percentage, an EFFECTIVE ANNUAL rate; the monthly compounding step is (1+pct/100)^(1/12)-1. Optional; defaults to the cited Senaro long-run S&P 500 nominal return, about 10%, when omitted. Range 0-30. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantial behavior: it is a calculation rather than advice, it emits total interest, monthly payment breakdown, equity buildup, a break-even investment return, tax deduction analysis, HPA-based PMI removal, and an after-tax net worth view gated on invest_the_difference plus filing_status and annual_gross_income. ARM non-support is disclosed rather than left for the agent to discover via a validation error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the caveat and one-line purpose, then a scannable bullet list for the supported comparison shapes, then a single routing sentence. For a 21-parameter tool the length is proportionate and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 21 parameters, nested objects, and no output schema, the description covers outputs (interest totals, equity, break-even return, after-tax net worth), the key default, the sibling routing, and a hard limitation. An agent has enough to decide whether to call it and how to frame the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes modestly beyond the per-field text by explaining the interaction that unlocks the after-tax comparison (invest_the_difference default-on together with filing_status and annual_gross_income), but it does not explain the tax_year horizon arithmetic or PMI removal semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (compare two fixed-rate mortgage options side-by-side) and enumerates the comparison cases (15 vs 30, different rates, points vs no points). It also names the sibling tools it is not, so an agent can distinguish it from calculate_refi_breakeven and compare_payoff_strategies without reading any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('Pick this to compare two mortgage structures on a purchase') plus when-not-to-use with the exact alternative for each case: refinance comparisons go to calculate_refi_breakeven, payoff-strategy questions go to compare_payoff_strategies. It also excludes ARM mortgages up front.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_payoff_strategiesPayoff Strategy ComparisonARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Compare avalanche and snowball payoff strategies side-by-side. Pick this to compare avalanche against snowball ordering on the same set of cards; pick calculate_cc_payoff once a strategy is chosen and the need is a single payoff timeline with windfalls or fixed payments.
Returns months, total interest, payoff order, savings, total_balance, weighted_average_apr_pct, monthly_interest_now, and cost_breakdown array. When an arm is not projected to reach a zero balance, the savings.* fields for that arm carry status: "none" with value: null and an explanation, not a number.
savings.strategies_convergence separately discloses the avalanche/snowball arms' own convergence:
"both_converge" (ordinary case),
"worst_never_amortizes" (the losing strategy arm does not reach a zero balance in this projection but the winning arm does, so savings.best_vs_worst_months/interest carry status: "none"), or
"neither_converges" (the WINNING strategy arm does not reach a zero balance either, so no dollar or month figure derived from either strategy arm is reportable).
lower_total_interest_strategy names whichever of avalanche or snowball has the lower total interest, or "tie" when the two arms' total interest and months are exactly equal. A "tie" can co-occur with savings.strategies_convergence="neither_converges". It reports only that comparison, never that either arm pays off.
chart_hints.title and chart_hints.annotations[0].label report a dollar figure only when the comparison they describe is Defined, and otherwise state plainly that no figure is reportable, matching the "none" status on the corresponding savings.* field. Unlike chart_hints, summary and savings.savings_summary hedge rather than decline a figure, and the two always carry the same sentence as each other: when the compared arm does not converge (savings.baseline_never_amortizes=true, or savings.strategies_convergence=worst_never_amortizes) but the winning side still does, both report a figure hedged as a floor, "saves at least $X and N months ..., so the true saving could be higher than reported". Only when strategies_convergence=neither_converges do summary and savings.savings_summary also state that no figure is reportable. No savings.* sentinel object carries a hedged floor in its value key; the only place a floor ever appears is the savings.savings_summary sentence.
This tool carries no domain-shaped warnings[].type entries (unlike calculate_cc_payoff); warnings[] here is exclusively validation disclosures emitted as warnings[].code, e.g. MINIMUM_PAYMENT_NOT_BINDING_IN_BASELINE plus the general portfolio findings (MANY_CARDS, HIGH_CARD_BALANCE, etc.) shared with every card-based tool.
The response includes chart_hints with rendering directives any client can use.
This tool takes no strategy, fixed_payments, full_schedule or per_segment parameter: it always compares avalanche against snowball over the full schedule, so all four are rejected as unknown_parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | Credit cards to compare, 1 to 20, the same shape calculate_cc_payoff takes. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error ("cards is required and must be an array."); the two are not the same rejection. Every card may carry segments[]. Max 100 segments total across all cards in the request. Per-card, per-type caps: 1 purchase, 1 cash_advance, 5 balance_transfer, 1 promotional, 10 installment_plan. | |
| output | No | Valid values: 'summary' (default), 'inline'. summary returns the headline comparison with a data_preview block; inline returns the full payload. | |
| chart_title | No | Override for the chart title. Optional; must not contain an em dash or en dash. Max 120 characters. | |
| apply_rate_cap | No | Whether to cap each card's APR at the regulatory ceiling before simulating. Optional; defaults to false when omitted. | |
| extra_monthly_payment | No | Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums. Optional; defaults to 0 when omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnly, idempotent, non-destructive, closed-world); the description carries the rest, disclosing non-obvious behavior: the 'none' sentinel semantics for non-converging arms, the hedge-vs-decline distinction between chart_hints and savings.savings_summary, and that warnings[] here holds only validation codes, not domain warnings. This is substantive behavior beyond what any structured field provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The routing rule and the calculation-not-advice caveat are front-loaded, and the dense return-value prose is justified because there is no output schema. It is long and some sentences are extremely packed (the strategies_convergence enumeration), but each carries non-redundant contract information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return values, and it does: it enumerates the returned fields (months, total interest, payoff order, savings, cost_breakdown, chart_hints) and then specifies the edge cases where figures are withheld or hedged. Nothing an agent needs to interpret a response correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by naming the four parameters that must NOT be sent (strategy, fixed_payments, full_schedule, per_segment) and by clarifying that minimum_payment binds on both arms here unlike calculate_cc_payoff's default path. It does not add much per-parameter detail on the five declared params, which keeps it off a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compare avalanche and snowball payoff strategies side-by-side') and explicitly distinguishes itself from the sibling `calculate_cc_payoff` ('pick `calculate_cc_payoff` once a strategy is chosen...'). An agent can select this tool 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule for this tool vs. `calculate_cc_payoff`, and adds a when-not clause: it always runs both arms over the full schedule, so `strategy`, `fixed_payments`, `full_schedule` and `per_segment` are rejected as unknown_parameter. That is exactly the guidance an agent needs to avoid a failed call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_payoff_vs_investDebt Payoff vs. InvestARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Compares the guaranteed return of debt payoff against expected investment returns over a time horizon.
Accounts for post-payoff investing, optionally taxes the investment gain once at the horizon (this needs filing_status and annual_gross_income), and finds the break-even investment return rate. Works for credit cards, auto loans, student loans, personal loans, and mortgages.
Pick this when the alternative to investing is paying down an existing debt balance; pick calculate_opportunity_cost when there is no debt in the picture and the alternative is simply forgoing recurring spending to invest it instead.
The response echoes debt_type (canonical lowercase enum the projection was computed for) and debt_type_label (display-ready string, e.g. 'student loan') at the top level.
HEAVY tool: use output='summary' (default) for the headline comparison or output='inline' for the full month-by-month schedule.
When no projection can be computed (very long horizon, very high rate, or very large amounts), the response is { meta, not_representable: { code, explanation } } instead.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Valid values: 'summary' (default), 'inline'. 'summary' returns headline comparison scalars, milestones, and citations with monthly_schedule stripped. 'inline' returns the full payload including the month-by-month monthly_schedule[]. | |
| tax_year | No | Tax year, 2025 or 2026. Year 1 of the time horizon, so the assumed sale of the investments falls in tax year tax_year plus the horizon in years, rounded up, minus 1. Optional; defaults to 2026 when omitted. | |
| debt_type | Yes | Debt type: 'credit_card', 'auto', 'student', 'personal', or 'mortgage'. REQUIRED, no default. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| debt_apr_pct | Yes | Debt annual percentage rate, e.g. 6.5 not 0.065. Decimal from 0 to 100. REQUIRED, no default. | |
| debt_balance | Yes | Current debt balance. Decimal, greater than 0. REQUIRED, no default. | |
| extra_monthly | Yes | Extra monthly amount available for debt payoff or investing, the amount in question. Decimal, greater than 0. REQUIRED, no default. | |
| filing_status | No | Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax comparison. | |
| full_schedule | No | Whether to return the full month-by-month schedule. Optional; defaults to false (compact schedule) when omitted. | |
| minimum_payment | No | Minimum monthly payment. Decimal, at least 0. Optional; auto-calculated for amortizing loans when omitted or 0. | |
| tax_bracket_pct | No | Marginal tax bracket, e.g. 22 not 0.22. Decimal from 0 to 100. Optional; used only for the mortgage or student loan interest deduction warning. It is never applied to investment gains. | |
| time_horizon_years | No | Projection horizon. Integer, greater than 0. Optional; defaults to the greater of the payoff horizon or 10 years when omitted. | |
| annual_gross_income | No | Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax comparison. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000. | |
| investment_return_pct | No | Expected investment return, an EFFECTIVE ANNUAL rate; the monthly compounding step is (1+pct/100)^(1/12)-1. Decimal from 0 to 30. Optional; defaults to the cited long-run S&P 500 nominal return, about 10%, when omitted. | |
| term_months_remaining | No | Months remaining on the debt. Integer, greater than 0. Required for non-credit-card debt types; optional for credit_card. | |
| investment_tax_advantaged | No | Whether the investments sit in a tax-advantaged account, e.g. 401k or IRA. Optional; defaults to false. When true, no after-tax comparison is computed: withdrawal tax depends on the account type, which this tool does not model. | |
| investment_volatility_pct | No | Investment volatility. Decimal. Optional; adds a volatility risk note when supplied. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/idempotent annotations by disclosing the tool is a HEAVY computation with a summary/inline output trade-off, the exact fallback shape when no projection is possible ({ meta, not_representable }), that tax on gains is applied only once at the horizon and requires filing_status plus annual_gross_income, and that the response echoes debt_type and debt_type_label. It also sets a non-advice expectation, which matters for a financial comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core comparison and the sibling disambiguation before the mechanics; every paragraph carries distinct information (disclaimer, tax mechanics, routing rule, response shape, output modes, failure mode). Slightly long, but justified by 17 parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return payload (echoed debt_type/debt_type_label), the heavy-tool output modes, and the not_representable error shape. Combined with full schema coverage, an agent has everything needed to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is already 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: filing_status and annual_gross_income must be supplied together to unlock the after-tax comparison, and output='summary' is the default vs 'inline' for the full schedule. It does not elaborate on less obvious params like tax_bracket_pct's deduction-only role beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compares the guaranteed return of debt payoff against expected investment returns over a time horizon') and explicitly names the sibling it must be distinguished from, calculate_opportunity_cost. An agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule ('Pick this when the alternative to investing is paying down an existing debt balance') and the inverse condition for the alternative tool ('when there is no debt in the picture and the alternative is simply forgoing recurring spending'). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_rent_vs_buyRent vs. Buy CalculatorARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Deterministic rent-vs-buy decision model. Given a home price, monthly rent, and mortgage rate, computes the breakeven month (when BUY net worth first equals or exceeds RENT net worth), per-horizon net-worth comparison (years 5, 10, 30 + user horizon), and the full year-by-year cost/wealth series for both paths.
Includes carrying costs (property tax, insurance, maintenance, PMI, HOA) on the BUY path and opportunity-cost investing on the RENT path.
Optional federal tax benefit model (Tier-3: apply_tax_benefit=true) with the statute's year-by-year SALT cap schedule (advancing with the horizon, not frozen at tax_year), mortgage interest deduction, PMI deductibility, and marginal-excess formula.
All assumptions cite primary sources (FHFA, BLS, Harvard JCHS, IRS Pub 936, OBBBA Pub. L. 119-21) and can be overridden.
Pick this for the buy-vs-rent tenure decision; pick compare_mortgage_terms when you are already buying and comparing two mortgage structures, compare_payoff_strategies to order credit-card payoff, and compare_payoff_vs_invest to weigh extra debt payments against investing.
HEAVY tool: use output='summary' (default) for scalar headline or output='inline' for chart series.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Valid values: 'summary' (default), 'inline'. 'summary' returns headline scalars and per-horizon snapshots with the heavy series stripped. 'inline' returns the full payload including yearly_series[] and monthly_series[] for chart rendering. | |
| pmi_pct | No | Annual PMI rate as a percentage of the loan. Decimal from 0 to 5. Optional; defaults to 0.5% when omitted. The removal threshold is set by pmi_removal_ltv_pct. Models borrower-paid PMI on a conventional loan; FHA, VA and USDA mortgage insurance is not modeled. | |
| tax_year | No | Tax year for year 1 of the horizon: 2025 or 2026. Integer. Required when apply_tax_benefit is true; otherwise not used. Horizon year y uses tax year (tax_year + y - 1) on both the tax benefit and the sale-side capital-gains tax; the SALT cap follows the statute's own schedule for that year, and every other indexed amount holds at its last-loaded table value beyond it. | |
| charitable | No | Charitable contributions. Decimal from 0 to 1,000,000,000; TY2026 and later apply a 0.5%-of-AGI floor per OBBBA §70425. Only used when apply_tax_benefit is true. Optional; defaults to 0 when omitted. | |
| home_price | Yes | Home purchase price. Decimal, greater than 0 and at most 1,000,000,000. REQUIRED, no default. | |
| pmi_annual | No | Annual PMI premium in dollars while PMI is active. Decimal from 0 to 1,000,000,000. Only used when apply_tax_benefit is true. Optional; when omitted it is derived from pmi_pct and the original loan amount. | |
| real_terms | No | Whether to deflate the output series to a real-terms view. Optional; defaults to false when omitted. | |
| blind_count | No | Number of blind filers, each adding the additional standard deduction. Integer from 0 to 2. Only used when apply_tax_benefit is true. Optional; defaults to 0 when omitted. | |
| chart_title | No | Override for the chart title. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| hoa_monthly | No | Monthly HOA dues on the BUY path. Decimal from 0 to 1,000,000,000. Optional; defaults to 0 when omitted. | |
| monthly_rent | Yes | Monthly rent on the RENT path. Decimal from 0 to 1,000,000,000; 0 is valid (a free-housing baseline). REQUIRED, no default. | |
| filing_status | No | Tax filing status: 'Single', 'MFJ', 'MFS' or 'HoH'. Required when apply_tax_benefit is true; otherwise not used. | |
| horizon_years | No | Projection horizon in years. Integer from 1 to 40. Optional; when omitted, the response returns snapshots at years 5, 10 and 30. | |
| inflation_pct | No | Inflation as a percentage, for the real_terms toggle. Decimal, at least 0 and less than 100. Optional; when omitted, a nominal run uses 2.5%, and a real_terms run uses the horizon-based default: 2.0% for a horizon of 7 years or less, 2.6% for 8 to 19 years, 2.5% for 20 years or more. | |
| sell_side_pct | No | Sell-side transaction cost as a percentage of the sale price. Decimal from 0 to 25. Optional; defaults to the cited 7.5% (Redfin post-NAR) when omitted; override for your market. | |
| maintenance_pct | No | Annual maintenance as a percentage of home value. Decimal from 0 to 20. Optional; defaults to the cited 1.5% (Harvard JCHS) when omitted; override for your market. | |
| rent_growth_pct | No | Annual rent escalation as a percentage. Decimal from -50 to 50. Optional; defaults to the cited 3.4% (BLS CPI ROPR) when omitted; override for your market. | |
| state_local_tax | No | State and local tax paid (state income or sales tax), for the SALT cap. Decimal from 0 to 1,000,000,000. Only used when apply_tax_benefit is true. Optional; defaults to 0 when omitted. | |
| down_payment_pct | No | Down payment as a percentage of the home price. Decimal from 0 to 100; 0 is valid (zero-down programs). Optional; defaults to 20% when omitted. | |
| loan_term_months | No | Mortgage term in months. Integer from 1 to 480. Optional; defaults to 360 (a 30-year fixed) when omitted. | |
| other_itemizable | No | Other itemizable deductions, such as medical expenses above 7.5% of AGI or casualty losses. Decimal from 0 to 1,000,000,000. Only used when apply_tax_benefit is true. Optional; defaults to 0 when omitted. | |
| property_tax_pct | No | Annual property tax as a percentage of home value. Decimal from 0 to 10. Optional; defaults to 0.88% when omitted; override for your market. | |
| age_65_plus_count | No | Number of filers aged 65 or older, each adding the additional standard deduction. Integer from 0 to 2. Only used when apply_tax_benefit is true. Optional; defaults to 0 when omitted. | |
| apply_tax_benefit | No | Whether to apply the federal tax benefit model (SALT cap following the statute's year-by-year schedule, mortgage interest deduction, PMI deductibility). When true, filing_status, tax_year and annual_gross_income are required. Optional; defaults to false when omitted. The §121 home-sale gain exclusion applies only at sale points 24 months or more after purchase (IRC §121(a) 2-of-5-year test); year 1 of yearly_series, months 1-23 in monthly_series, and any horizon under 24 months use no exclusion. Separately, IRC §1222(3) makes a holding period of 12 months or less short-term, taxed at ordinary rates instead of the long-term rates otherwise applied, on the home-sale gain and the renter's portfolio gain alike (24 months vs. 12 months are two different thresholds); this tool applies that split exactly to the home-sale gain, and to the renter's portfolio at annual grain: prior years' contributions are compounded together as one long-term lot rather than aged individually, so months inside a year understate short-term gain. | |
| mortgage_rate_pct | Yes | Mortgage annual rate as a percentage, e.g. 6.75 for 6.75%. Decimal, greater than 0 and at most 100. Never cached; provide the current rate. REQUIRED, no default. | |
| home_insurance_pct | No | Annual home insurance as a percentage of home value. Decimal from 0 to 15. Optional; defaults to 0.65% when omitted; override for your market. | |
| annual_gross_income | No | Annual gross income, the MAGI proxy for the bracket and the SALT cap. Decimal from 0 to 1,000,000,000. Required when apply_tax_benefit is true; otherwise not used. | |
| pmi_removal_ltv_pct | No | Loan-balance trigger for PMI removal, as a percentage loan-to-value. Decimal from 50 to 100. Optional; omitted, it is the 78% HPA automatic-termination threshold; provided (e.g. 80), it is whichever of 78% or your value is reached first. The rejection guard applies only when down_payment_pct is below 20 and the resolved pmi_pct is above 0, the range where PMI applies: there, a value at or above the loan's own initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. A value just below the initial LTV can also be reached by the first payment; then no month charges PMI either. When the resolved pmi_pct is 0, or down_payment_pct is 20 or more, no such check runs, whatever the LTV. Either way PMI also stops at the statutory amortization midpoint of the original term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone. Models borrower-paid PMI on a conventional loan; FHA, VA and USDA mortgage insurance is not modeled. | |
| purchase_year_points | No | Discount points paid at origination, as a percentage of the loan. Decimal from 0 to 4. Counted as cash paid at closing on every call. When apply_tax_benefit is true they are also deducted in year 1, assuming the IRS Pub 936 tests for a first-year deduction are met (main home bought with the loan, points customary and not above the local norm, cash method, not paid in place of separately listed fees, paid with your own money at or before closing, figured as a percentage of the loan and shown as points on the settlement statement), and only for the share the mortgage interest gets: the acquisition-debt limit divided by the year-1 average loan balance, when that is below 1. mortgage_rate_pct must already be the rate these points buy. Optional; defaults to 0 when omitted. | |
| home_appreciation_pct | No | Annual home price appreciation as a percentage. Decimal from -50 to 50. Optional; defaults to the cited 4.25% (FHFA HPI) when omitted; override for your market. | |
| investment_return_pct | No | RENT path annual return as a percentage, an EFFECTIVE ANNUAL rate; the monthly compounding step is (1+pct/100)^(1/12)-1. Decimal from -50 to 30. Optional; defaults to 10.0% when omitted. | |
| loan_origination_date | No | Mortgage origination date, YYYY-MM-DD. Selects the mortgage interest deduction cap: on or before 2017-12-15 the $1M cap, after it the $750k cap (Single and MFJ; MFS caps are half). Only used when apply_tax_benefit is true. Optional; omitting it uses the post-2017 cap. | |
| basis_capitalizable_pct_override | No | Percentage of the buy-side closing cost that is capitalizable into the §121 adjusted basis (IRS Pub 523 split: abstract fees, title search, recording fees, survey fees, transfer taxes, owner's title insurance). Decimal from 0 to 100; 0 means a HomePrice-only basis, 100 means the full closing cost is in basis. Optional; defaults to 50% (Senaro deterministic midpoint) when omitted. Supply your actual HUD-1 split when available. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds genuine behavioral context beyond that: it flags the tool as HEAVY and recommends output='summary' over 'inline', discloses that assumptions are sourced and overridable, and describes the optional tax-benefit tier and its statutory schedule. It stops short of stating cost/latency magnitude or pagination-style limits for the heavy payload, so it is a strong 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and computed outputs are front-loaded, followed by carrying-cost coverage, the tax tier, sourcing, sibling routing, and the output-mode note. Every section earns its place for a 33-parameter tool, though the opening disclaimer line sits ahead of the actual purpose and slightly delays the front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe returns, and it does: breakeven month, per-horizon net worth at years 5/10/30 plus a user horizon, and the year-by-year series, with 'summary' vs 'inline' explaining what is stripped or included. For a tool of this complexity, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across all 33 parameters, so the schema already carries per-parameter meaning including defaults, ranges and enum values. The description only alludes to the three required inputs and the output-mode toggle, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Deterministic rent-vs-buy decision model') and then enumerates exactly what it computes: the breakeven month, per-horizon net-worth snapshots, and the full year-by-year series for both paths. It also names the sibling tools it is not, so an agent can distinguish it from compare_mortgage_terms or compare_payoff_vs_invest without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Pick this for the buy-vs-rent tenure decision; pick compare_mortgage_terms when you are already buying and comparing two mortgage structures, compare_payoff_strategies to order credit-card payoff, and compare_payoff_vs_invest to weigh extra debt payments against investing.' Each alternative carries the condition that selects it, so when-to-use and when-not-to-use are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_defaultsDefault Assumptions CatalogARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting.
Returns named default values used by Senaro Finance tools with source citations. Use before calling other tools to understand what assumptions apply automatically. This tool does not accept an 'output' parameter; it always returns inline JSON.
JSON parameters (all optional):
category: string. Filter entries by category: the canonical MCP tool name that consumes the default, or "shared" for a default consumed by two or more tools (or not yet wired to a specific tool). Case-insensitive. The 14 valid values: calculate_cc_payoff, calculate_compound_interest, calculate_debt_to_income, calculate_emergency_fund, calculate_opportunity_cost, calculate_refi_breakeven, calculate_runway, compare_debt_consolidation, compare_mortgage_terms, compare_payoff_strategies, compare_payoff_vs_invest, compare_rent_vs_buy, optimize_401k_match, shared. An unrecognized value returns validation_error listing the accepted set.
name: string. Return one full entry. Requires category. Returns validation_error if not found.
verbose: boolean. Return all 10 citation fields per entry instead of just category+name. Ignored when name is also present (single entry always includes all fields). Omit category to get the full verbose catalog.
Default (no args): index mode. Every entry with just category and name fields (~20 KB).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional: return one full entry. Requires category. Returns validation_error if not found. | |
| verbose | No | Optional: return all 10 citation fields per entry instead of just category+name. | |
| category | No | Optional: filter entries by category, the canonical MCP tool name (e.g. "compare_rent_vs_buy") or "shared". Case-insensitive. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the description does not need to restate safety. It adds substantial behavioral detail: the 'calculation, not advice' disclaimer, the always-inline-JSON return, index vs verbose modes, ~20KB size, and validation_error behavior for unrecognized categories. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a disclaimer, purpose, usage note, and parameter details, and the key facts are front-loaded. It is somewhat lengthy due to the full category list, but each sentence earns its place. It could be slightly more concise, but it remains clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully carries the burden of explaining return formats: index mode returns only category+name (~20KB), verbose mode returns all 10 citation fields, and single-entry mode includes all fields. It also covers validation_error behavior and how this tool fits among the calculation siblings. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description goes beyond the schema by listing all 14 valid category values, explaining that name requires category, and clarifying that verbose is ignored when name is present. It also describes error responses for invalid categories, which is not in the schema. This adds meaningful usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns named default values used by Senaro Finance tools with source citations. It distinguishes itself from calculation siblings by explicitly framing itself as a catalog to consult before other tools, and notes it always returns inline JSON without an 'output' parameter. This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs agents to use this tool before calling other tools to understand applicable assumptions. It also clarifies that it does not accept an 'output' parameter and explains parameter interactions (name requires category, verbose ignored when name is present). Default behavior for no arguments is specified as index mode. This leaves no ambiguity about when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
optimize_401k_match401(k) Match OptimizerARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting. Deterministic 401(k) employer-match optimizer. Given your annual salary, pay frequency, current contribution percent, and your employer's match formula (as a named preset or a custom tier list), computes:
the annual match you receive today;
the maximum match available (full match entitlement);
the match forfeited at your current rate;
the minimum contribution percent to receive the full match;
whether front-loading contributions would forfeit match at a no-true-up plan; and
a per-period schedule showing level vs. front-load paths side by side.
Pick this to size 401(k) contributions against the employer match formula; pick compare_payoff_vs_invest when the question is putting an extra monthly amount toward a debt versus investing it (that tool takes no employer-match input), not how much of the match to receive.
IRS limits (402(g) elective deferral, 401(a)(17) compensation cap, 415(c) annual additions) are applied and cited in provenance. Catch-up contribution ceilings for ages 50+ and 60-63 (SECURE 2.0) are computed when participant_age is provided; when a catch-up allowance applies, applied_caps[].cap_name reads '402(g) elective deferral plus 414(v) catch-up' and limit_value carries the combined ceiling, not the bare 402(g) amount.
HEAVY tool: use output='summary' (default) for the headline scalars or output='inline' for the full per-period schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| output | No | Valid values: 'summary' (default), 'inline'. Response envelope. 'summary': headline scalars, period_schedule stripped. 'inline': full payload including period_schedule[]. | |
| chart_title | No | Override for the chart title. Reserved for the chart pipeline. Must not contain em-dashes or en-dashes. Max 120 characters. Optional. | |
| has_true_up | No | Whether the plan provides an annual true-up. false is the conservative assumption: surfaces front-loading forfeiture risk. Optional; defaults to false when omitted. | |
| match_tiers | No | Custom match-formula tier list. Example: [{"match_frac": 1.0, "up_to_deferral_pct": 3}, {"match_frac": 0.5, "up_to_deferral_pct": 2}] = safe_harbor_basic. Exactly one of match_preset or match_tiers is required. Optional; omit when supplying match_preset. | |
| match_preset | No | Named match-formula preset: 'safe_harbor_basic' (100% of first 3% + 50% of next 2%), 'safe_harbor_enhanced_simple' (100% of first 4%), 'qaca' (100% of first 1% + 50% of next 5%), 'fifty_pct_of_first_six_pct' (50% of first 6%). Exactly one of match_preset or match_tiers is required. Optional; omit when supplying match_tiers. | |
| annual_salary | Yes | Annual gross salary. Decimal > 0. REQUIRED, no default. | |
| participant_age | No | Determines which catch-up limit applies (age 50+, or age 60-63 SECURE 2.0 super catch-up). Integer >= 0. Optional; omit when age is unknown or participant is under 50. | |
| contribution_pct | Yes | Current employee contribution as a percent of gross pay. Decimal in [0, 100]. REQUIRED, no default. | |
| pay_periods_per_year | Yes | Pay periods per year (12=monthly, 24=semi-monthly, 26=biweekly, 52=weekly). Integer in [1, 365]. REQUIRED, no default. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description then adds substantial non-redundant behavior: determinism, the 'Calculation, not advice' disclaimer, IRS 402(g)/401(a)(17)/415(c) limits applied and cited in provenance, and precise catch-up semantics ('applied_caps[].cap_name reads \'402(g) elective deferral plus 414(v) catch-up\' and limit_value carries the combined ceiling'). It also flags output weight ('HEAVY tool') so agents can choose summary vs. inline. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded (brief disclaimer, then the 'Deterministic 401(k) employer-match optimizer' statement), and each subsequent block - computed outputs, sibling routing, IRS/catch-up behavior, output-mode guidance - earns its place. It is long, but the density is justified for a 9-parameter financial tool with complicated limit behavior; the catch-up paragraph is the densest and could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this complex with no output schema, the description is remarkably complete: it enumerates the computed results in prose, names the output envelope modes (summary/inline), specifies period_schedule and applied_caps[] behavior, and covers limits, conservative defaults, and when-not-to-use. Combined with 100% schema coverage and safety annotations, an agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all nine parameters thoroughly, putting the baseline at 3. The description adds genuine value by connecting participant_age to concrete output behavior (catch-up ceilings for ages 50+ and 60-63, plus the applied_caps cap_name/limit_value semantics) and by framing the preset-vs-custom-tier choice in prose. It does not restate per-parameter schema details, so 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific, differentiated purpose: a 'Deterministic 401(k) employer-match optimizer' that computes match entitlement from salary, pay frequency, contribution percent, and match formula. It lists six concrete computed outputs (current match, max match, forfeited match, minimum percent to full match, front-loading risk, per-period schedule) and explicitly distinguishes itself from sibling compare_payoff_vs_invest. An agent can tell exactly what this tool does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is embedded: 'Pick this to size 401(k) contributions against the employer match formula; pick `compare_payoff_vs_invest` when the question is putting an extra monthly amount toward a debt versus investing it.' It even notes the sibling takes no employer-match input, removing ambiguity. The 'HEAVY tool: use output=\'summary\'...' sentence also tells the agent when to invoke cheaply vs. request the full schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
server_infoSenaro Server InfoARead-onlyIdempotentInspect
Calculation, not advice. Verify with a professional before acting.
Returns metadata about the running Senaro MCP server: version, contract version, build commit, build timestamp, and the full list of supported tools. Call this once per session before drafting any content to verify the running process is not stale after a deploy. Idempotent, no side effects, < 50 ms. If server_version is below the minimum required by your skill, STOP and ask the user to restart Claude Desktop.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description reinforces idempotency and adds value beyond the annotations with 'no side effects' and a latency bound ('< 50 ms'), plus the staleness-check workflow. It does not add auth or rate-limit context, but the annotation coverage is strong, so a 4 is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The return fields and the once-per-session guidance are front-loaded and efficient. The leading 'Calculation, not advice. Verify with a professional before acting.' is boilerplate disclaimer that is relevant but not strictly about this tool, keeping it short of a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden, and it lists all returned fields explicitly. For a zero-parameter, read-only diagnostic tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter guidance because none is needed, and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns metadata about the running Senaro MCP server') and enumerates exactly what is returned: version, contract version, build commit, build timestamp, and supported tools. This clearly distinguishes it from the financial-calculation siblings, none of which are server/diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit timing ('Call this once per session before drafting any content') and the reason ('to verify the running process is not stale after a deploy'). It even prescribes a conditional action on the result: if server_version is below the required minimum, STOP and ask the user to restart. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
analyze_cash_advance1 field changed- changed
Input schema / properties / minimum_payment / descriptionPrevious value: -"Issuer-stated minimum payment. Decimal, at least 0, at most 2 decimal places. Optional; defaults to auto-calculate when omitted. When supplied, this DOES bind: the per-month mandatory payment is min(max(the issuer minimum recomputed from the balance, minimum_payment), the remaining balance, total_monthly_payment). This differs from calculate_cc_payoff's default dynamic path, where the identically-named minimum_payment is parsed and validated but never applied unless fixed_payments = true: the two tools do not share behavior for this parameter, only its name."New value: +"Issuer-stated minimum payment. Decimal, at least 0, at most 2 decimal places. Optional; defaults to auto-calculate when omitted. When supplied, this DOES bind: the per-month mandatory payment is min(max(the representative formula's minimum recomputed from the balance, minimum_payment), the remaining balance, total_monthly_payment). This differs from calculate_cc_payoff's default dynamic path, where the identically-named minimum_payment is parsed and validated but never applied unless fixed_payments = true: the two tools do not share behavior for this parameter, only its name."
3 tool updates
- Changed
analyze_cash_advance1 field changed- changed
Input schema / properties / cash_advance_apr_pct / descriptionPrevious value: -"Cash advance APR as a percentage. Decimal, greater than 0, at most 100. A cash advance always accrues interest immediately, so 0 is not a valid rate. REQUIRED, no default."New value: +"Cash advance APR as a percentage. Decimal, greater than 0, at most 100. This tool has no promo input, so 0 is rejected: nothing would say when a 0% rate ends. For a promotional cash advance, use calculate_cc_payoff with a cash_advance segment carrying promo_expires_month and revert_apr_pct. REQUIRED, no default."
- Changed
calculate_cc_payoff5 fields changed- changed
Input schema / properties / cards / items / properties / cash_advance_apr_pct / descriptionPrevious value: -"Cash advance APR as a percentage, greater than 0 and up to 100. Required when cash_advance_balance is greater than 0: cash advances have no promotional 0% product, so a 0% rate on a real advance balance is a data-entry error."New value: +"Cash advance APR as a percentage, greater than 0 and up to 100. Required when cash_advance_balance is greater than 0. These flat fields have no promo input, so 0 is rejected: nothing would say when a 0% rate ends. For a promotional cash advance, such as a 0% direct-deposit or check offer, use segments[] with a cash_advance segment carrying promo_expires_month and revert_apr_pct." - changed
Input schema / properties / cards / items / properties / segments / items / properties / apr_pct / descriptionPrevious value: -"Annual percentage rate for this segment, 0 to 100, e.g. 24.99 not 0.2499. Required when balance is greater than 0 on purchase, cash_advance, balance_transfer and promotional. On cash_advance it must be greater than 0 whenever a balance is carried. Must be 0 on installment_plan, which uses monthly_fee instead, so omitting it there is the correct shape."New value: +"Annual percentage rate for this segment, 0 to 100, e.g. 24.99 not 0.2499. Required when balance is greater than 0 on purchase, cash_advance, balance_transfer and promotional. On cash_advance with a balance it must be supplied and greater than 0, unless the segment also carries a usable promo_expires_month and revert_apr_pct: then it is the promotional rate and may be 0. Must be 0 on installment_plan, which uses monthly_fee instead, so omitting it there is the correct shape." - changed
Input schema / properties / cards / items / properties / segments / items / properties / promo_expires_month / descriptionPrevious value: -"Month at which apr_pct flips to revert_apr_pct, 1 to 480. Required on balance_transfer and promotional. Ignored on purchase, cash_advance and installment_plan."New value: +"Last month charged at apr_pct, 1 to 480; revert_apr_pct applies from the next month. Month 1 is the first statement cycle after the statement the balance comes from. From a statement, count the closing dates after it, up to and including the last one on or before the promo end date; a cycle the end date splits counts at revert_apr_pct. If no closing date qualifies, the promo ends inside month 1: enter the post-promo rate as both apr_pct and revert_apr_pct, with promo_expires_month 1. Required on balance_transfer and promotional. On cash_advance, supply it with revert_apr_pct, under the rule stated on revert_apr_pct. Ignored on purchase and installment_plan." - changed
Input schema / properties / cards / items / properties / segments / items / properties / revert_apr_pct / descriptionPrevious value: -"Rate this segment reverts to once its promo expires, 0 to 100, and at least apr_pct. Required on balance_transfer and promotional. Ignored on purchase and cash_advance. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate rather than repricing."New value: +"Rate this segment reverts to once its promo expires, 0 to 100, and at least apr_pct: the post-promo APR the offer disclosed, wherever the offer or the statement prints it. Only when neither prints one for this balance, take the regular rate of this balance's category, not the promo rate. A direct-deposit or check cash advance reverts to the cash-advance APR for those advances, which can differ from the bank cash-advance APR and is not the balance-transfer APR. Required on balance_transfer and promotional. On cash_advance, supply it with promo_expires_month: alone or invalid, the pair is not used and an INPUT_NOT_USED warning says why, except at an apr_pct of 0 with a balance, where the request is rejected. Ignored on purchase. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate rather than repricing." - changed
Input schema / properties / cards / items / properties / segments / items / properties / type / descriptionPrevious value: -"Segment type. REQUIRED on every segment: omitting it is rejected. Per-type field matrix. Every field below is classified for every segment type: REQUIRED (omitting it is rejected), OPTIONAL (accepted either way and read), IGNORED (accepted and never read for this type, though a value can still fail the field's own range check), or REJECTED (supplying a disallowed value is an error; the field's own rule below says exactly which values are disallowed). Value rules are stated separately from applicability, because a field can be accepted on a type and still be restricted there. The validators are the authority; this matrix describes them.\n- type: REQUIRED on every type. Values: one of purchase, cash_advance, balance_transfer, promotional, installment_plan.\n- balance: REQUIRED on every type. Values: $0 to $1,000,000,000; above $50,000 returns a HIGH_CARD_BALANCE warning, not an error.\n- apr_pct: REQUIRED on purchase, cash_advance, balance_transfer, promotional; OPTIONAL on installment_plan. Values: 0 to 100 as a percentage, e.g. 24.99 not 0.2499. The REQUIRED classification above applies when balance is greater than 0; a zero-balance segment may omit it. Must be greater than 0 on cash_advance carrying a balance. Must equal 0 on installment_plan, where omitting it is the correct shape.\n- revert_apr_pct: REQUIRED on balance_transfer, promotional; IGNORED on purchase, cash_advance; REJECTED on installment_plan. Values: 0 to 100, and at least apr_pct. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate.\n- promo_expires_month: REQUIRED on balance_transfer, promotional; IGNORED on purchase, cash_advance, installment_plan. Values: 1 to 480.\n- monthly_fee: OPTIONAL on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: $0 or more, and no greater than plan_payment_due, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- plan_payment_due: REQUIRED on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: greater than $0, at least monthly_fee, and no more than $1,000,000,000, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- remaining_payments: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 0 or more. 0 means the stated term has ALREADY ended and is valid with any balance. From 1 up, balance must be clearable within the stated term.\n- min_payment_order: OPTIONAL on every type. Values: 1 or more; breaks a tie only between segments sharing both the same current APR and the same installment-plan status.\n- extra_payment_order: OPTIONAL on every type. Values: 0 or more; 0 means skip. Breaks a tie only between segments sharing the exact same current APR.\n- merchant_name: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 120 characters or fewer.\n- monthly_spend: OPTIONAL on purchase; REJECTED on cash_advance, balance_transfer, promotional, installment_plan. Values: $0 to $50,000 per month. A negative value is rejected as NEGATIVE_BALANCE on every type, purchase included. On every type other than purchase a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; an explicit 0 is accepted.\n- stop_spend_month: OPTIONAL on purchase; IGNORED on cash_advance, balance_transfer, promotional, installment_plan. Values: 0 or more; range checked on every type, read only on purchase."New value: +"Segment type. REQUIRED on every segment: omitting it is rejected. Per-type field matrix. Every field below is classified for every segment type: REQUIRED (omitting it is rejected), OPTIONAL (accepted either way and read), PAIRED (read when supplied together with its partner as a usable pair: promo_expires_month and revert_apr_pct both supplied beside a supplied apr_pct, each within its value rule; a pair that is not usable is rejected when the segment carries a balance and its apr_pct is omitted, 0 or below, and otherwise is not used, with an INPUT_NOT_USED warning; omitting both, or sending both as null, is accepted), IGNORED (accepted and never read for this type, though a value can still fail the field's own range check), or REJECTED (supplying a disallowed value is an error; the field's own rule below says exactly which values are disallowed). Value rules are stated separately from applicability, because a field can be accepted on a type and still be restricted there. The validators are the authority; this matrix describes them.\n- type: REQUIRED on every type. Values: one of purchase, cash_advance, balance_transfer, promotional, installment_plan.\n- balance: REQUIRED on every type. Values: $0 to $1,000,000,000; above $50,000 returns a HIGH_CARD_BALANCE warning, not an error.\n- apr_pct: REQUIRED on purchase, cash_advance, balance_transfer, promotional; OPTIONAL on installment_plan. Values: 0 to 100 as a percentage, e.g. 24.99 not 0.2499. The REQUIRED classification above applies when balance is greater than 0; a zero-balance segment may omit it. Must be greater than 0 on cash_advance carrying a balance, unless that segment carries a usable promo pair (promo_expires_month and revert_apr_pct). Must equal 0 on installment_plan, where omitting it is the correct shape.\n- revert_apr_pct: REQUIRED on balance_transfer, promotional; PAIRED on cash_advance; IGNORED on purchase; REJECTED on installment_plan. Values: 0 to 100, and at least apr_pct. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate.\n- promo_expires_month: REQUIRED on balance_transfer, promotional; PAIRED on cash_advance; IGNORED on purchase, installment_plan. Values: 1 to 480.\n- monthly_fee: OPTIONAL on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: $0 or more, and no greater than plan_payment_due, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- plan_payment_due: REQUIRED on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: greater than $0, at least monthly_fee, and no more than $1,000,000,000, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- remaining_payments: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 0 or more. 0 means the stated term has ALREADY ended and is valid with any balance. From 1 up, balance must be clearable within the stated term.\n- min_payment_order: OPTIONAL on every type. Values: 1 or more; breaks a tie only between segments sharing both the same current APR and the same installment-plan status.\n- extra_payment_order: OPTIONAL on every type. Values: 0 or more; 0 means skip. Breaks a tie only between segments sharing the exact same current APR.\n- merchant_name: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 120 characters or fewer.\n- monthly_spend: OPTIONAL on purchase; REJECTED on cash_advance, balance_transfer, promotional, installment_plan. Values: $0 to $50,000 per month. A negative value is rejected as NEGATIVE_BALANCE on every type, purchase included. On every type other than purchase a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; an explicit 0 is accepted.\n- stop_spend_month: OPTIONAL on purchase; IGNORED on cash_advance, balance_transfer, promotional, installment_plan. Values: 0 or more; range checked on every type, read only on purchase."
- Changed
compare_payoff_strategies5 fields changed- changed
Input schema / properties / cards / items / properties / cash_advance_apr_pct / descriptionPrevious value: -"Cash advance APR as a percentage, greater than 0 and up to 100. Required when cash_advance_balance is greater than 0: cash advances have no promotional 0% product, so a 0% rate on a real advance balance is a data-entry error."New value: +"Cash advance APR as a percentage, greater than 0 and up to 100. Required when cash_advance_balance is greater than 0. These flat fields have no promo input, so 0 is rejected: nothing would say when a 0% rate ends. For a promotional cash advance, such as a 0% direct-deposit or check offer, use segments[] with a cash_advance segment carrying promo_expires_month and revert_apr_pct." - changed
Input schema / properties / cards / items / properties / segments / items / properties / apr_pct / descriptionPrevious value: -"Annual percentage rate for this segment, 0 to 100, e.g. 24.99 not 0.2499. Required when balance is greater than 0 on purchase, cash_advance, balance_transfer and promotional. On cash_advance it must be greater than 0 whenever a balance is carried. Must be 0 on installment_plan, which uses monthly_fee instead, so omitting it there is the correct shape."New value: +"Annual percentage rate for this segment, 0 to 100, e.g. 24.99 not 0.2499. Required when balance is greater than 0 on purchase, cash_advance, balance_transfer and promotional. On cash_advance with a balance it must be supplied and greater than 0, unless the segment also carries a usable promo_expires_month and revert_apr_pct: then it is the promotional rate and may be 0. Must be 0 on installment_plan, which uses monthly_fee instead, so omitting it there is the correct shape." - changed
Input schema / properties / cards / items / properties / segments / items / properties / promo_expires_month / descriptionPrevious value: -"Month at which apr_pct flips to revert_apr_pct, 1 to 480. Required on balance_transfer and promotional. Ignored on purchase, cash_advance and installment_plan."New value: +"Last month charged at apr_pct, 1 to 480; revert_apr_pct applies from the next month. Month 1 is the first statement cycle after the statement the balance comes from. From a statement, count the closing dates after it, up to and including the last one on or before the promo end date; a cycle the end date splits counts at revert_apr_pct. If no closing date qualifies, the promo ends inside month 1: enter the post-promo rate as both apr_pct and revert_apr_pct, with promo_expires_month 1. Required on balance_transfer and promotional. On cash_advance, supply it with revert_apr_pct, under the rule stated on revert_apr_pct. Ignored on purchase and installment_plan." - changed
Input schema / properties / cards / items / properties / segments / items / properties / revert_apr_pct / descriptionPrevious value: -"Rate this segment reverts to once its promo expires, 0 to 100, and at least apr_pct. Required on balance_transfer and promotional. Ignored on purchase and cash_advance. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate rather than repricing."New value: +"Rate this segment reverts to once its promo expires, 0 to 100, and at least apr_pct: the post-promo APR the offer disclosed, wherever the offer or the statement prints it. Only when neither prints one for this balance, take the regular rate of this balance's category, not the promo rate. A direct-deposit or check cash advance reverts to the cash-advance APR for those advances, which can differ from the bank cash-advance APR and is not the balance-transfer APR. Required on balance_transfer and promotional. On cash_advance, supply it with promo_expires_month: alone or invalid, the pair is not used and an INPUT_NOT_USED warning says why, except at an apr_pct of 0 with a balance, where the request is rejected. Ignored on purchase. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate rather than repricing." - changed
Input schema / properties / cards / items / properties / segments / items / properties / type / descriptionPrevious value: -"Segment type. REQUIRED on every segment: omitting it is rejected. Per-type field matrix. Every field below is classified for every segment type: REQUIRED (omitting it is rejected), OPTIONAL (accepted either way and read), IGNORED (accepted and never read for this type, though a value can still fail the field's own range check), or REJECTED (supplying a disallowed value is an error; the field's own rule below says exactly which values are disallowed). Value rules are stated separately from applicability, because a field can be accepted on a type and still be restricted there. The validators are the authority; this matrix describes them.\n- type: REQUIRED on every type. Values: one of purchase, cash_advance, balance_transfer, promotional, installment_plan.\n- balance: REQUIRED on every type. Values: $0 to $1,000,000,000; above $50,000 returns a HIGH_CARD_BALANCE warning, not an error.\n- apr_pct: REQUIRED on purchase, cash_advance, balance_transfer, promotional; OPTIONAL on installment_plan. Values: 0 to 100 as a percentage, e.g. 24.99 not 0.2499. The REQUIRED classification above applies when balance is greater than 0; a zero-balance segment may omit it. Must be greater than 0 on cash_advance carrying a balance. Must equal 0 on installment_plan, where omitting it is the correct shape.\n- revert_apr_pct: REQUIRED on balance_transfer, promotional; IGNORED on purchase, cash_advance; REJECTED on installment_plan. Values: 0 to 100, and at least apr_pct. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate.\n- promo_expires_month: REQUIRED on balance_transfer, promotional; IGNORED on purchase, cash_advance, installment_plan. Values: 1 to 480.\n- monthly_fee: OPTIONAL on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: $0 or more, and no greater than plan_payment_due, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- plan_payment_due: REQUIRED on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: greater than $0, at least monthly_fee, and no more than $1,000,000,000, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- remaining_payments: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 0 or more. 0 means the stated term has ALREADY ended and is valid with any balance. From 1 up, balance must be clearable within the stated term.\n- min_payment_order: OPTIONAL on every type. Values: 1 or more; breaks a tie only between segments sharing both the same current APR and the same installment-plan status.\n- extra_payment_order: OPTIONAL on every type. Values: 0 or more; 0 means skip. Breaks a tie only between segments sharing the exact same current APR.\n- merchant_name: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 120 characters or fewer.\n- monthly_spend: OPTIONAL on purchase; REJECTED on cash_advance, balance_transfer, promotional, installment_plan. Values: $0 to $50,000 per month. A negative value is rejected as NEGATIVE_BALANCE on every type, purchase included. On every type other than purchase a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; an explicit 0 is accepted.\n- stop_spend_month: OPTIONAL on purchase; IGNORED on cash_advance, balance_transfer, promotional, installment_plan. Values: 0 or more; range checked on every type, read only on purchase."New value: +"Segment type. REQUIRED on every segment: omitting it is rejected. Per-type field matrix. Every field below is classified for every segment type: REQUIRED (omitting it is rejected), OPTIONAL (accepted either way and read), PAIRED (read when supplied together with its partner as a usable pair: promo_expires_month and revert_apr_pct both supplied beside a supplied apr_pct, each within its value rule; a pair that is not usable is rejected when the segment carries a balance and its apr_pct is omitted, 0 or below, and otherwise is not used, with an INPUT_NOT_USED warning; omitting both, or sending both as null, is accepted), IGNORED (accepted and never read for this type, though a value can still fail the field's own range check), or REJECTED (supplying a disallowed value is an error; the field's own rule below says exactly which values are disallowed). Value rules are stated separately from applicability, because a field can be accepted on a type and still be restricted there. The validators are the authority; this matrix describes them.\n- type: REQUIRED on every type. Values: one of purchase, cash_advance, balance_transfer, promotional, installment_plan.\n- balance: REQUIRED on every type. Values: $0 to $1,000,000,000; above $50,000 returns a HIGH_CARD_BALANCE warning, not an error.\n- apr_pct: REQUIRED on purchase, cash_advance, balance_transfer, promotional; OPTIONAL on installment_plan. Values: 0 to 100 as a percentage, e.g. 24.99 not 0.2499. The REQUIRED classification above applies when balance is greater than 0; a zero-balance segment may omit it. Must be greater than 0 on cash_advance carrying a balance, unless that segment carries a usable promo pair (promo_expires_month and revert_apr_pct). Must equal 0 on installment_plan, where omitting it is the correct shape.\n- revert_apr_pct: REQUIRED on balance_transfer, promotional; PAIRED on cash_advance; IGNORED on purchase; REJECTED on installment_plan. Values: 0 to 100, and at least apr_pct. Rejected on installment_plan with FIELD_NOT_ALLOWED_HERE: an expired plan's residual keeps its existing rate.\n- promo_expires_month: REQUIRED on balance_transfer, promotional; PAIRED on cash_advance; IGNORED on purchase, installment_plan. Values: 1 to 480.\n- monthly_fee: OPTIONAL on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: $0 or more, and no greater than plan_payment_due, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- plan_payment_due: REQUIRED on installment_plan; REJECTED on purchase, cash_advance, balance_transfer, promotional. Values: greater than $0, at least monthly_fee, and no more than $1,000,000,000, on installment_plan. On every other type a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; 0 and a negative value are accepted and dropped there.\n- remaining_payments: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 0 or more. 0 means the stated term has ALREADY ended and is valid with any balance. From 1 up, balance must be clearable within the stated term.\n- min_payment_order: OPTIONAL on every type. Values: 1 or more; breaks a tie only between segments sharing both the same current APR and the same installment-plan status.\n- extra_payment_order: OPTIONAL on every type. Values: 0 or more; 0 means skip. Breaks a tie only between segments sharing the exact same current APR.\n- merchant_name: OPTIONAL on installment_plan; IGNORED on purchase, cash_advance, balance_transfer, promotional. Values: 120 characters or fewer.\n- monthly_spend: OPTIONAL on purchase; REJECTED on cash_advance, balance_transfer, promotional, installment_plan. Values: $0 to $50,000 per month. A negative value is rejected as NEGATIVE_BALANCE on every type, purchase included. On every type other than purchase a POSITIVE value is rejected with FIELD_NOT_ALLOWED_HERE; an explicit 0 is accepted.\n- stop_spend_month: OPTIONAL on purchase; IGNORED on cash_advance, balance_transfer, promotional, installment_plan. Values: 0 or more; range checked on every type, read only on purchase."
2 tool updates
- Changed
calculate_opportunity_cost4 fields changed- added
Input schema / properties / annual_gross_incomeAdded value: +{ + "default": null, + "description": "Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax opportunity cost. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000.", + "maximum": 1000000000, + "minimum": 0, + "type": [ + "number", + "null" + ] +} - added
Input schema / properties / filing_statusAdded value: +{ + "default": null, + "description": "Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax opportunity cost.", + "enum": [ + "single", + "married", + "head_of_household", + null + ], + "type": [ + "string", + "null" + ] +} - changed
Input schema / properties / tax_bracket_pct / descriptionPrevious value: -"Tax bracket as a percentage, applied as a flat haircut to the investment gain. Decimal from 0 to 100. Optional."New value: +"Not used. Kept so older calls still work; an after-tax figure needs filing_status and annual_gross_income. Decimal from 0 to 100. Optional." - added
Input schema / properties / tax_yearAdded value: +{ + "default": null, + "description": "Tax year, 2025 or 2026. Year 1 of the horizon, so the assumed sale of the investments falls in tax year tax_year + years - 1. Optional; defaults to 2026 when omitted.", + "maximum": 2026, + "minimum": 2025, + "type": [ + "integer", + "null" + ] +}
- Changed
compare_payoff_vs_invest5 fields changed- added
Input schema / properties / annual_gross_incomeAdded value: +{ + "default": null, + "description": "Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax comparison. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000.", + "maximum": 1000000000, + "minimum": 0, + "type": [ + "number", + "null" + ] +} - added
Input schema / properties / filing_statusAdded value: +{ + "default": null, + "description": "Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax comparison.", + "enum": [ + "single", + "married", + "head_of_household", + null + ], + "type": [ + "string", + "null" + ] +} - changed
Input schema / properties / investment_tax_advantaged / descriptionPrevious value: -"Whether the investment is tax-advantaged, e.g. 401k or IRA. Optional; defaults to false when omitted."New value: +"Whether the investments sit in a tax-advantaged account, e.g. 401k or IRA. Optional; defaults to false. When true, no after-tax comparison is computed: withdrawal tax depends on the account type, which this tool does not model." - changed
Input schema / properties / tax_bracket_pct / descriptionPrevious value: -"Tax bracket, e.g. 22 not 0.22. Decimal from 0 to 100. Optional; enables an after-tax comparison when supplied."New value: +"Marginal tax bracket, e.g. 22 not 0.22. Decimal from 0 to 100. Optional; used only for the mortgage or student loan interest deduction warning. It is never applied to investment gains." - added
Input schema / properties / tax_yearAdded value: +{ + "default": null, + "description": "Tax year, 2025 or 2026. Year 1 of the time horizon, so the assumed sale of the investments falls in tax year tax_year plus the horizon in years, rounded up, minus 1. Optional; defaults to 2026 when omitted.", + "maximum": 2026, + "minimum": 2025, + "type": [ + "integer", + "null" + ] +}
1 tool update
- Changed
compare_mortgage_terms4 fields changed- added
Input schema / properties / annual_gross_incomeAdded value: +{ + "default": null, + "description": "Annual gross income in dollars, used as adjusted gross income for the tax on investment gains at the horizon. Optional; with filing_status it enables the after-tax comparison. Held at this amount in the year of the assumed investment sale. Must be zero or more and no more than $1,000,000,000.", + "maximum": 1000000000, + "minimum": 0, + "type": [ + "number", + "null" + ] +} - changed
Input schema / properties / filing_status / descriptionPrevious value: -"Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively."New value: +"Tax filing status: 'single', 'married', or 'head_of_household'. Optional; matched case-insensitively. Required, with annual_gross_income, for the after-tax comparison." - changed
Input schema / properties / tax_bracket_pct / descriptionPrevious value: -"Marginal tax bracket as a percentage, 0-50. Optional; enables after-tax investment return and mortgage interest deduction analysis when supplied. The after-tax comparison credits each option's annual deduction savings to its investments at year end."New value: +"Marginal tax bracket as a percentage, 0-50. Optional; values the mortgage-interest deduction (interest_deduction_value) and the yearly deduction savings credited to each option's investments in the after-tax comparison. It is never applied to investment gains." - changed
Input schema / properties / tax_year / descriptionPrevious value: -"Tax year, 2025 or 2026, selecting the IRS standard-deduction table for the itemize-vs-standard analysis. Optional; defaults to 2026 when omitted."New value: +"Tax year, 2025 or 2026, selecting the IRS standard-deduction table for the itemize-vs-standard analysis. The after-tax view counts it as year 1 of the horizon, so the assumed sale of the investments falls in tax year tax_year + time_horizon_years - 1. Optional; defaults to 2026 when omitted."
4 tool updates
- Changed
calculate_loan_payoff1 field changed- changed
Input schema / properties / annual_rate_pct / descriptionPrevious value: -"Loan annual percentage rate, e.g. 6.5 not 0.065. Decimal from 0 to 100. REQUIRED, no default."New value: +"Loan annual interest rate (the note rate in the loan contract, not the disclosed APR, which can differ when fees are financed), e.g. 6.5 not 0.065. Decimal from 0 to 100. REQUIRED, no default."
- Changed
calculate_refi_breakeven6 fields changed- changed
Input schema / properties / closing_costs / descriptionPrevious value: -"Explicit 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."New value: +"Explicit 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 current balance (LodeStar 2026). An IMMEDIATE break-even requires total upfront cost to be zero AND monthly_savings to be non-negative AND roll_costs_into_loan false, 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." - changed
Input schema / properties / compute_economic_break_even / descriptionPrevious value: -"Whether 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."New value: +"Whether to compute the economic (net-worth crossover) break-even. When false, economic_break_even reports NOT_REQUESTED; every other field is still returned. Optional; defaults to true when omitted." - changed
Input schema / properties / current_monthly_payment / descriptionPrevious value: -"Your 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."New value: +"Your 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. Rounded to the cent, it must be greater than the first month's interest: current_balance rounded to the cent, times current_annual_rate_pct / 100 / 12, rounded to the cent." - changed
Input schema / properties / investment_return_pct / descriptionPrevious value: -"Annual 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."New value: +"Annual return used for the economic (net-worth crossover) break-even, an EFFECTIVE ANNUAL rate: it compounds money not spent on a payment and, when costs are paid upfront, the upfront refinance cost that keeping the current loan leaves invested. 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." - changed
Input schema / properties / points / descriptionPrevious value: -"Discount points paid at closing, where 1.0 means 1% of the loan. Decimal from 0 to 4. Optional; defaults to 0 when omitted."New value: +"Discount points paid at closing, where 1.0 means 1% of the loan amount: the current balance when costs are paid upfront, or, when roll_costs_into_loan is true, the new loan amount, which includes the financed closing costs and points. Decimal from 0 to 4. Optional; defaults to 0 when omitted." - changed
Input schema / properties / roll_costs_into_loan / descriptionPrevious value: -"Whether 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."New value: +"Whether closing costs and points are added to the new principal instead of paid upfront. When true, points are a percentage of the new loan amount; cash-flow break-even reports COSTS_ROLLED_INTO_LOAN; and the economic break-even, when requested, compares the two loans with the financed costs in the new principal and no upfront cash. Optional; defaults to false when omitted."
- Changed
compare_debt_consolidation3 fields changed- changed
Input schema / properties / current_strategy / descriptionPrevious value: -"Your current payoff strategy, compared against the consolidation loan / balance-transfer alternative: 'avalanche' or 'snowball'. Optional; defaults to 'avalanche' when omitted. Case-sensitive."New value: +"Your current payoff strategy, compared against the consolidation loan / balance-transfer alternative: 'avalanche' or 'snowball'. In partial consolidation it ranks the loan against the kept cards, and the part it ranks first, the loan or the kept cards, receives the extra payment and any windfalls. Optional; defaults to 'avalanche' when omitted. Case-sensitive." - changed
Input schema / properties / extra_monthly_payment / descriptionPrevious value: -"Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums for keep-cards and any balance transfer, and on top of the loan's own required payment for consolidation. Optional; defaults to 0 when omitted. fixed_payments is not a parameter of this tool, unlike calculate_cc_payoff: the keep-cards baseline is always simulated under the canonical constant rolled-forward payment (see comparison_basis in the response); supplying fixed_payments returns an unknown_parameter error."New value: +"Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums for keep-cards and any balance transfer, and on top of the loan's own required payment for consolidation. In partial consolidation, the extra payment and any windfalls go to the part current_strategy ranks first, the loan or the kept cards. Optional; defaults to 0 when omitted. fixed_payments is not a parameter of this tool, unlike calculate_cc_payoff: the keep-cards baseline is always simulated under the canonical constant rolled-forward payment (see comparison_basis in the response); supplying fixed_payments returns an unknown_parameter error." - changed
Input schema / properties / windfalls / descriptionPrevious value: -"One-time principal payments, at most 12, same shape as calculate_cc_payoff. Optional; a JSON null is treated as omitted, the same as leaving the field out. When non-empty, the response adds windfalls_applied[] and windfalls_unused[] on keep_cards, on each balance_transfer scenario (and on each offer in balance_transfer_offers.offers[]), on consolidation_loan (single-row per windfall since the loan is a single-balance instrument), and on optimized_consolidation.keep_subset. All scenarios use with-windfalls totals so cross-option ranking stays apples-to-apples, except what_if.same_budget_accelerated, a windfall-free hypothetical about extra-payment behavior, not your actual lump-sum schedule."New value: +"One-time principal payments, at most 12, same shape as calculate_cc_payoff. Optional; a JSON null is treated as omitted, the same as leaving the field out. When non-empty, the response adds windfalls_applied[] and windfalls_unused[] on keep_cards, on each balance_transfer scenario (and on each offer in balance_transfer_offers.offers[]), on consolidation_loan (single-row per windfall since the loan is a single-balance instrument), and on optimized_consolidation.loan and optimized_consolidation.keep_subset (each windfall dollar is listed once across the two). All scenarios use with-windfalls totals so cross-option ranking stays apples-to-apples, except what_if.same_budget_accelerated, a windfall-free hypothetical about extra-payment behavior, not your actual lump-sum schedule."
- Changed
compare_rent_vs_buy3 fields changed- changed
Input schema / properties / pmi_pct / descriptionPrevious value: -"Annual PMI rate as a percentage of the loan. Decimal from 0 to 5. Optional; defaults to 0.5% when omitted. The removal threshold is set by pmi_removal_ltv_pct."New value: +"Annual PMI rate as a percentage of the loan. Decimal from 0 to 5. Optional; defaults to 0.5% when omitted. The removal threshold is set by pmi_removal_ltv_pct. Models borrower-paid PMI on a conventional loan; FHA, VA and USDA mortgage insurance is not modeled." - changed
Input schema / properties / pmi_removal_ltv_pct / descriptionPrevious value: -"Loan-balance trigger for PMI removal, as a percentage loan-to-value. Decimal from 50 to 100. Optional; omitted, it is the 78% HPA automatic-termination threshold; provided (e.g. 80), it is whichever of 78% or your value is reached first. The rejection guard applies only when down_payment_pct is below 20 and the resolved pmi_pct is above 0, the range where PMI applies: there, a value at or above the loan's own initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. When the resolved pmi_pct is 0, or down_payment_pct is 20 or more, no such check runs, whatever the LTV. Either way PMI also stops at the statutory amortization midpoint of the original term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone."New value: +"Loan-balance trigger for PMI removal, as a percentage loan-to-value. Decimal from 50 to 100. Optional; omitted, it is the 78% HPA automatic-termination threshold; provided (e.g. 80), it is whichever of 78% or your value is reached first. The rejection guard applies only when down_payment_pct is below 20 and the resolved pmi_pct is above 0, the range where PMI applies: there, a value at or above the loan's own initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. A value just below the initial LTV can also be reached by the first payment; then no month charges PMI either. When the resolved pmi_pct is 0, or down_payment_pct is 20 or more, no such check runs, whatever the LTV. Either way PMI also stops at the statutory amortization midpoint of the original term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone. Models borrower-paid PMI on a conventional loan; FHA, VA and USDA mortgage insurance is not modeled." - changed
Input schema / properties / purchase_year_points / descriptionPrevious value: -"Discount points paid at origination, as a percentage of the loan. Decimal from 0 to 4. Counted as cash paid at closing on every call; when apply_tax_benefit is true they are also deducted in year 1. Optional; defaults to 0 when omitted."New value: +"Discount points paid at origination, as a percentage of the loan. Decimal from 0 to 4. Counted as cash paid at closing on every call. When apply_tax_benefit is true they are also deducted in year 1, assuming the IRS Pub 936 tests for a first-year deduction are met (main home bought with the loan, points customary and not above the local norm, cash method, not paid in place of separately listed fees, paid with your own money at or before closing, figured as a percentage of the loan and shown as points on the settlement statement), and only for the share the mortgage interest gets: the acquisition-debt limit divided by the year-1 average loan balance, when that is below 1. mortgage_rate_pct must already be the rate these points buy. Optional; defaults to 0 when omitted."
3 tool updates
- Changed
calculate_debt_to_income2 fields changed- changed
Input schema / properties / monthly_maintenance_and_utilities / descriptionPrevious value: -"Estimated monthly maintenance and utilities for the proposed property. 38 CFR 36.4340 calls for a realistic estimate of this figure for the property and local utility rates and sets no numeric multiplier itself, but VA underwriting guidance (the Lender's Handbook, Pamphlet 26-7) publishes a per-square-foot multiplier for this same estimate. Applying it needs the property's square footage, which this tool does not currently collect, so Senaro has no default to offer here and you supply the aggregate monthly amount instead. Supplying BOTH this field and monthly_taxes_and_retirement_withholding, together with proposed_home_price and a computable family_size/property_state, computes qualification.va.residual_income_comparison: your ACTUAL monthly residual income, its ratio to the va_residual_income_guideline figure, and whether residual_income_meets_review_waiver_margin (residual income at or above 120% of the guideline) is met. The shelter expense used here excludes any PMI (VA loans carry no monthly PMI; 38 CFR 36.4313(e) sets a funding fee instead, commonly financed into the loan; see va_funding_fee_financed_monthly for the financed-fee field). 38 CFR 36.4340(c)(3)'s review-waiver condition is CONJUNCTIVE: it also requires the back-end debt-to-income ratio (qualification.va.your_back_end) to exceed 41%, which this field does not by itself confirm. Check both fields together. Even when both hold, (c)(3) only WAIVES a second-level review requirement; it is not itself an approval. Whether this file is actually approved is an underwriting determination Senaro does not make and no input combination here determines. Missing any one of the needed inputs reads qualification.va.residual_income_comparison.status 'not_computable' with every reason named. Optional; must be zero or more."New value: +"Estimated monthly maintenance and utilities for the proposed property. 38 CFR 36.4340 calls for a realistic estimate of this figure for the property and local utility rates and sets no numeric multiplier itself, but VA underwriting guidance (the Lender's Handbook, Pamphlet 26-7) publishes a per-square-foot multiplier for this same estimate. Applying it needs the property's square footage, which this tool does not currently collect, so Senaro has no default to offer here and you supply the aggregate monthly amount instead. Supplying BOTH this field and monthly_taxes_and_retirement_withholding, together with proposed_home_price and a computable family_size/property_state, computes qualification.va.residual_income_comparison: your ACTUAL monthly residual income, its ratio to the va_residual_income_guideline figure, and whether residual_income_meets_review_waiver_margin (residual income at or above 120% of the guideline) is met. The shelter expense used here excludes any PMI (VA loans carry no monthly PMI; 38 CFR 36.4313(e) sets a funding fee instead, commonly financed into the loan; see va_funding_fee_financed_monthly for the financed-fee field). 38 CFR 36.4340(c)(3)'s review-waiver condition is CONJUNCTIVE: it also requires the back-end debt-to-income ratio, rounded to a whole percent under 38 CFR 36.4340(d) (qualification.va.your_back_end_compared), to exceed 41%, which this field does not by itself confirm. Check both fields together. Even when both hold, (c)(3) only WAIVES a second-level review requirement; it is not itself an approval. Whether this file is actually approved is an underwriting determination Senaro does not make and no input combination here determines. Missing any one of the needed inputs reads qualification.va.residual_income_comparison.status 'not_computable' with every reason named. Optional; must be zero or more." - changed
Input schema / properties / va_funding_fee_financed_monthly / descriptionPrevious value: -"The additional monthly payment from financing a VA funding fee into the loan balance, if any. 38 CFR 36.4313(e)'s applicable percentage depends on down payment, prior VA-loan use, and service category, none of which Senaro collects, so there is no default. If omitted while any VA figure that depends on it is produced, meaning qualification.va.your_back_end and its verdict, any what_if VA ratio, what_if.max_affordable_home.va, or qualification.va.residual_income_comparison, a VA_FUNDING_FEE_NOT_MODELED warning discloses that no fee is assumed. The home-price-reduction what_if scenario's hypothetical price is fixed before the fee is considered, so a supplied fee is scaled to that EXACT hypothetical loan size, since 38 CFR 36.4313(e)'s fee is a percentage of loan principal. what_if.max_affordable_home.va is a two-pass approximation instead, so its supplied fee is scaled to an ESTIMATE of the hypothetical loan size, not the exact figure reported; the PMI, tax, and insurance reservation itself is an EXACT closed-form solve, so only this fee-scaling step is approximate. Without proposed_home_price there is no reference loan size to scale from either way, so the raw fee is reserved unscaled instead, and a VA_FUNDING_FEE_NOT_SCALED warning discloses it. This is mutually exclusive with VA_FUNDING_FEE_NOT_MODELED by construction, since one requires the fee omitted and the other requires it supplied. Optional; must be zero or more."New value: +"The additional monthly payment from financing a VA funding fee into the loan balance, if any. 38 CFR 36.4313(e)'s applicable percentage depends on down payment, prior VA-loan use, and service category, none of which Senaro collects, so there is no default. If omitted while any VA figure that depends on it is produced, meaning qualification.va.your_back_end and its verdict, any what_if VA ratio, what_if.max_affordable_home.va, or qualification.va.residual_income_comparison, a VA_FUNDING_FEE_NOT_MODELED warning discloses that no fee is assumed. The home-price-reduction what_if scenario's hypothetical price is fixed before the fee is considered, so a supplied fee is scaled to that EXACT hypothetical loan size, since 38 CFR 36.4313(e)'s fee is a percentage of loan principal. what_if.max_affordable_home.va is a two-pass approximation instead, so its supplied fee is scaled to an ESTIMATE of the hypothetical loan size, not the exact figure reported; the published price itself passes an exact forward VA check under 38 CFR 36.4340(d) with that reserved fee, and one dollar more fails it, so only this fee-scaling step is approximate. Without proposed_home_price there is no reference loan size to scale from either way, so the raw fee is reserved unscaled instead, and a VA_FUNDING_FEE_NOT_SCALED warning discloses it. This is mutually exclusive with VA_FUNDING_FEE_NOT_MODELED by construction, since one requires the fee omitted and the other requires it supplied. Optional; must be zero or more."
- Changed
compare_debt_consolidation1 field changed- changed
Input schema / properties / consolidation_loan / properties / annual_rate_pct / descriptionPrevious value: -"Annual interest rate for the consolidation loan, as a percentage, 0-36, e.g. 10.99. Required."New value: +"Annual interest rate for the consolidation loan, as a percentage, 0-36, e.g. 10.99. This is the loan's note interest rate, not the disclosed APR. The APR already reflects the origination fee, so entering it here counts the fee twice. Required."
- Changed
compare_rent_vs_buy2 fields changed- changed
Input schema / properties / apply_tax_benefit / descriptionPrevious value: -"Whether to apply the federal tax benefit model (TY2025/TY2026 SALT caps, mortgage interest deduction, PMI deductibility). When true, filing_status, tax_year and annual_gross_income are required. Optional; defaults to false when omitted. The §121 home-sale gain exclusion applies only at sale points 24 months or more after purchase (IRC §121(a) 2-of-5-year test); year 1 of yearly_series, months 1-23 in monthly_series, and any horizon under 24 months use no exclusion. Separately, IRC §1222(3) makes a holding period of 12 months or less short-term, taxed at ordinary rates instead of the long-term rates otherwise applied, on the home-sale gain and the renter's portfolio gain alike (24 months vs. 12 months are two different thresholds); this tool applies that split exactly to the home-sale gain, and to the renter's portfolio at annual grain: prior years' contributions are compounded together as one long-term lot rather than aged individually, so months inside a year understate short-term gain."New value: +"Whether to apply the federal tax benefit model (SALT cap following the statute's year-by-year schedule, mortgage interest deduction, PMI deductibility). When true, filing_status, tax_year and annual_gross_income are required. Optional; defaults to false when omitted. The §121 home-sale gain exclusion applies only at sale points 24 months or more after purchase (IRC §121(a) 2-of-5-year test); year 1 of yearly_series, months 1-23 in monthly_series, and any horizon under 24 months use no exclusion. Separately, IRC §1222(3) makes a holding period of 12 months or less short-term, taxed at ordinary rates instead of the long-term rates otherwise applied, on the home-sale gain and the renter's portfolio gain alike (24 months vs. 12 months are two different thresholds); this tool applies that split exactly to the home-sale gain, and to the renter's portfolio at annual grain: prior years' contributions are compounded together as one long-term lot rather than aged individually, so months inside a year understate short-term gain." - changed
Input schema / properties / tax_year / descriptionPrevious value: -"Tax year: 2025 or 2026. Integer. Required when apply_tax_benefit is true; otherwise not used."New value: +"Tax year for year 1 of the horizon: 2025 or 2026. Integer. Required when apply_tax_benefit is true; otherwise not used. Horizon year y uses tax year (tax_year + y - 1) on both the tax benefit and the sale-side capital-gains tax; the SALT cap follows the statute's own schedule for that year, and every other indexed amount holds at its last-loaded table value beyond it."
22 tool updates
- Changed
analyze_cash_advance5 fields changed- added
Input schema / properties / cash_advance_apr_pct / exclusiveMinimumAdded value: +0 - added
Input schema / properties / cash_advance_apr_pct / maximumAdded value: +100 - added
Input schema / properties / cash_advance_fee_pct / maximumAdded value: +100 - added
Input schema / properties / cash_advance_fee_pct / minimumAdded value: +0 - added
Input schema / properties / chart_title / maxLengthAdded value: +120
- Changed
analyze_pmi_removal6 fields changed- added
Input schema / properties / chart_title / maxLengthAdded value: +120 - added
Input schema / properties / current_balance / minimumAdded value: +0.01 - added
Input schema / properties / current_home_value / minimumAdded value: +0.01 - added
Input schema / properties / monthly_payment / minimumAdded value: +0.01 - added
Input schema / properties / original_appraised_value / minimumAdded value: +0.01 - added
Input schema / properties / original_purchase_price / minimumAdded value: +0.01
- Changed
calculate_cc_payoff12 fields changed- changed
Input schema / properties / cards / items / properties / minimum_payment / descriptionPrevious value: -"Minimum payment in dollars, $0 to $1,000,000,000 (optional, omit or set 0 to auto-calculate). Where it binds, the card is locked at max(minimum_payment, that card's issuer minimum computed at month 1), and that locked amount is paid every month. On calculate_cc_payoff it binds ONLY when fixed_payments = true; on the DEFAULT path (fixed_payments = false) it is NOT used, because the plan recomputes each card's issuer minimum from its current balance every month, and the response discloses that as MINIMUM_PAYMENT_NOT_BINDING. On compare_strategies there is no fixed_payments parameter and supplying one is rejected: the avalanche and snowball arms ALWAYS run locked, so the value DOES bind and moves both arms, while the minimum-payments-only baseline always recomputes and ignores it, disclosed as MINIMUM_PAYMENT_NOT_BINDING_IN_BASELINE."New value: +"Minimum payment in dollars, $0 to $1,000,000,000 (optional, omit or set 0 to auto-calculate). Where it binds, the card is locked at max(minimum_payment, that card's issuer minimum computed at month 1), and that locked amount is paid every month. On calculate_cc_payoff it binds ONLY when fixed_payments = true; on the DEFAULT path (fixed_payments = false) it is NOT used, because the plan recomputes each card's issuer minimum from its current balance every month, and the response discloses that as MINIMUM_PAYMENT_NOT_BINDING. On compare_payoff_strategies there is no fixed_payments parameter and supplying one is rejected: the avalanche and snowball arms ALWAYS run locked, so the value DOES bind and moves both arms, while the minimum-payments-only baseline always recomputes and ignores it, disclosed as MINIMUM_PAYMENT_NOT_BINDING_IN_BASELINE." - added
Input schema / properties / cards / items / properties / name / maxLengthAdded value: +120 - added
Input schema / properties / cards / items / properties / purchase_apr_pct / maximumAdded value: +100 - added
Input schema / properties / cards / items / properties / purchase_apr_pct / minimumAdded value: +0 - added
Input schema / properties / cards / maxItemsAdded value: +20 - added
Input schema / properties / chart_title / maxLengthAdded value: +120 - changed
Input schema / properties / fixed_payments / descriptionPrevious value: -"Whether to hold each card's payment constant for the whole payoff. Optional; defaults to false when omitted. When true, each card's payment is locked at max(cards[].minimum_payment, that card's issuer minimum computed at month 1), and the total monthly budget (those locked amounts plus extra_monthly_payment) is held constant for the whole payoff, so once a card is paid off its freed-up payment rolls forward onto the remaining cards. This is the ONLY mode in which cards[].minimum_payment affects calculate_cc_payoff's result; compare_strategies has no fixed_payments parameter and binds minimum_payment on both of its strategy arms regardless."New value: +"Whether to hold each card's payment constant for the whole payoff. Optional; defaults to false when omitted. When true, each card's payment is locked at max(cards[].minimum_payment, that card's issuer minimum computed at month 1), and the total monthly budget (those locked amounts plus extra_monthly_payment) is held constant for the whole payoff, so once a card is paid off its freed-up payment rolls forward onto the remaining cards. This is the ONLY mode in which cards[].minimum_payment affects calculate_cc_payoff's result; compare_payoff_strategies has no fixed_payments parameter and binds minimum_payment on both of its strategy arms regardless." - changed
Input schema / properties / output / enumPrevious value: -[ - "summary", - "inline" -]New value: +[ + "summary", + "inline", + null +] - changed
Input schema / properties / output / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Input schema / properties / strategy / enumAdded value: +[ + "avalanche", + "snowball", + null +] - added
Input schema / properties / windfalls / items / properties / label / maxLengthAdded value: +120 - added
Input schema / properties / windfalls / maxItemsAdded value: +12
- Added
calculate_compound_interest - Changed
calculate_debt_to_income13 fields changed- added
Input schema / properties / annual_income / minimumAdded value: +0.01 - changed
Input schema / properties / existing_debts / items / properties / name / descriptionPrevious value: -"Optional label for this debt, e.g. 'Car Loan'."New value: +"Optional label for this debt, e.g. 'Car Loan'. At most 120 characters." - added
Input schema / properties / existing_debts / items / properties / name / maxLengthAdded value: +120 - changed
Input schema / properties / existing_debts / items / properties / type / descriptionPrevious value: -"Debt type: 'auto', 'student', 'credit_card', 'personal', 'mortgage', 'heloc', 'child_support', or 'other'. Optional, defaults to 'other' when omitted; an unrecognized value warns rather than rejects."New value: +"Debt type: 'auto', 'student', 'credit_card', 'personal', 'mortgage', 'heloc', 'child_support', or 'other'. Optional, defaults to 'other' when omitted. An unrecognized value of at most 120 characters warns rather than rejects; a longer one is rejected." - added
Input schema / properties / existing_debts / items / properties / type / maxLengthAdded value: +120 - added
Input schema / properties / existing_debts / maxItemsAdded value: +50 - added
Input schema / properties / family_size / maximumAdded value: +20 - added
Input schema / properties / gross_monthly_income / minimumAdded value: +0.01 - changed
Input schema / properties / proposed_debt / properties / name / descriptionPrevious value: -"Optional label for this proposed debt."New value: +"Optional label for this proposed debt. At most 120 characters." - added
Input schema / properties / proposed_debt / properties / name / maxLengthAdded value: +120 - added
Input schema / properties / proposed_debt / properties / type / enumAdded value: +[ + "credit_card", + "auto", + "student", + "personal", + "mortgage", + "heloc", + "child_support", + "other", + null +] - added
Input schema / properties / proposed_home_price / minimumAdded value: +0.01 - added
Input schema / properties / transaction_purpose / enumAdded value: +[ + "purchase", + "refinance", + "streamlined_assist", + null +]
- Changed
calculate_emergency_fund3 fields changed- added
Input schema / properties / chart_title / maxLengthAdded value: +120 - added
Input schema / properties / job_stability / enumAdded value: +[ + "stable_w2", + "variable_income", + "self_employed", + "between_jobs", + null +] - added
Input schema / properties / monthly_essential_expenses / minimumAdded value: +0.01
- Changed
calculate_loan_payoff6 fields changed- added
Input schema / properties / chart_bucket / enumAdded value: +[ + "auto", + "monthly", + "quarterly", + "yearly", + "biennial", + null +] - added
Input schema / properties / chart_title / maxLengthAdded value: +120 - added
Input schema / properties / loan_type / enumAdded value: +[ + "personal", + "auto", + "student", + "mortgage", + null +] - changed
Input schema / properties / output / enumPrevious value: -[ - "summary" -]New value: +[ + "summary", + null +] - changed
Input schema / properties / output / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Input schema / properties / term_months / maximumAdded value: +480
- Changed
calculate_opportunity_cost4 fields changed- added
Input schema / properties / chart_title / maxLengthAdded value: +120 - changed
Input schema / properties / label / descriptionPrevious value: -"What the spending is, e.g. 'coffee' or 'streaming subscriptions'. Optional."New value: +"What the spending is, e.g. 'coffee' or 'streaming subscriptions'. Optional. Max 120 characters." - added
Input schema / properties / label / maxLengthAdded value: +120 - added
Input schema / properties / monthly_spending / minimumAdded value: +0.01
- Added
calculate_refi_breakeven - Changed
calculate_runway3 fields changed- added
Input schema / properties / chart_title / maxLengthAdded value: +120 - changed
Input schema / properties / output / enumPrevious value: -[ - "summary", - "inline" -]New value: +[ + "summary", + "inline", + null +] - changed
Input schema / properties / output / typePrevious value: -"string"New value: +[ + "string", + "null" +]
- Changed
compare_debt_consolidation13 fields changed- added
Input schema / properties / bt_manual_transfers / items / properties / card_name / maxLengthAdded value: +120 - added
Input schema / properties / bt_offers / items / properties / apr_pct / maximumAdded value: +100 - added
Input schema / properties / bt_offers / items / properties / apr_pct / minimumAdded value: +0 - added
Input schema / properties / bt_offers / items / properties / label / maxLengthAdded value: +120 - added
Input schema / properties / bt_offers / maxItemsAdded value: +10 - added
Input schema / properties / bt_transfer_limit / minimumAdded value: +0.01 - changed
Input schema / properties / cards / descriptionPrevious value: -"Credit cards to include, 1 to 20. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error (\"cards must be a JSON array.\"); the two are not the same rejection. segments and stop_spend_month are not supported by this tool and are rejected; a non-zero monthly_spend, annual_fee, or plan_fees_monthly is rejected too, but zero (including an explicit 0) is accepted and dropped for all three: this tool always reads the flat purchase_balance / cash_advance_balance fields on each card below, never segments[] balances, and card-level fees and ongoing spend are not modeled here. Those five fields are supported by calculate_cc_payoff and compare_strategies instead."New value: +"Credit cards to include, 1 to 20. Required: omitting the field answers contract_error MISSING_REQUIRED_FIELD, while an explicit JSON null answers parse_error (\"cards must be a JSON array.\"); the two are not the same rejection. segments and stop_spend_month are not supported by this tool and are rejected; a non-zero monthly_spend, annual_fee, or plan_fees_monthly is rejected too, but zero (including an explicit 0) is accepted and dropped for all three: this tool always reads the flat purchase_balance / cash_advance_balance fields on each card below, never segments[] balances, and card-level fees and ongoing spend are not modeled here. Those five fields are supported by calculate_cc_payoff and compare_payoff_strategies instead." - added
Input schema / properties / cards / items / properties / name / maxLengthAdded value: +120 - added
Input schema / properties / chart_title / maxLengthAdded value: +120 - added
Input schema / properties / current_strategy / enumAdded value: +[ + "avalanche", + "snowball", + null +] - changed
Input schema / properties / output / enumPrevious value: -[ - "summary", - "inline" -]New value: +[ + "summary", + "inline", + null +] - changed
Input schema / properties / output / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Input schema / properties / windfalls / items / properties / label / maxLengthAdded value: +120
- Changed
compare_mortgage_terms7 fields changed- added
Input schema / properties / filing_status / enumAdded value: +[ + "single", + "married", + "head_of_household", + null +] - added
Input schema / properties / option_a / properties / label / maxLengthAdded value: +120 - added
Input schema / properties / option_b / properties / label / maxLengthAdded value: +120 - added
Input schema / properties / tax_bracket_pct / maximumAdded value: +50 - added
Input schema / properties / tax_bracket_pct / minimumAdded value: +0 - added
Input schema / properties / tax_year / maximumAdded value: +2026 - added
Input schema / properties / tax_year / minimumAdded value: +2025
- Added
compare_payoff_strategies - Added
compare_payoff_vs_invest - Added
compare_rent_vs_buy - Removed
compare_strategies - Removed
compound_interest - Changed
list_defaults1 field changed- changed
Input schema / properties / category / descriptionPrevious value: -"Optional: filter entries by category, the canonical MCP tool name (e.g. \"rent_vs_buy\") or \"shared\". Case-insensitive."New value: +"Optional: filter entries by category, the canonical MCP tool name (e.g. \"compare_rent_vs_buy\") or \"shared\". Case-insensitive."
- Changed
optimize_401k_match9 fields changed- added
Input schema / properties / chart_title / maxLengthAdded value: +120 - added
Input schema / properties / contribution_pct / maximumAdded value: +100 - added
Input schema / properties / contribution_pct / minimumAdded value: +0 - added
Input schema / properties / match_preset / enumAdded value: +[ + "safe_harbor_basic", + "safe_harbor_enhanced_simple", + "qaca", + "fifty_pct_of_first_six_pct", + null +] - added
Input schema / properties / match_tiers / maxItemsAdded value: +10 - changed
Input schema / properties / output / enumPrevious value: -[ - "summary", - "inline" -]New value: +[ + "summary", + "inline", + null +] - changed
Input schema / properties / output / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Input schema / properties / pay_periods_per_year / maximumAdded value: +365 - added
Input schema / properties / pay_periods_per_year / minimumAdded value: +1
- Removed
payoff_vs_invest - Removed
refi_breakeven - Removed
rent_vs_buy
9 tool updates
- Changed
calculate_cc_payoff4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"Response verbosity: 'summary' (default) | 'inline' | 'capture'. summary returns a compact response with a data_preview block; inline returns the full payload; capture writes the full payload to this server's local disk for the chart-render pipeline and returns a capture_ref URI. capture is available on the local stdio transport only, and the hosted HTTP transport rejects it with a structured error naming 'summary' and 'inline' as the valid alternatives, since a capture_ref would be a dead link for a remote caller. Optional; defaults to 'summary' when omitted."New value: +"Valid values: 'summary' (default), 'inline'. summary returns a compact response with a data_preview block; inline returns the full payload." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
calculate_loan_payoff4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"'summary' (default) or 'capture'. 'inline' is not a valid value for this tool on any transport. 'summary' returns the full payload including analysis.buckets[] inline. 'capture' writes the full payload to ~/.senaro/captures/ and returns capture_ref, stripping analysis from the wire response; available on the local stdio transport only, since the hosted HTTP transport rejects 'capture' and names 'summary' as the only alternative."New value: +"Valid values: 'summary' (default). 'summary' returns the full payload including analysis.buckets[] inline." - added
Input schema / properties / output / enumAdded value: +[ + "summary" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
calculate_runway4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"'summary' (default), 'inline', or 'capture'. 'summary' returns headline scalars (depletion month or does-not-deplete) and citations with the schedule stripped. 'inline' returns the full payload including the month-by-month schedule[] for chart rendering. 'capture' writes the full payload to ~/.senaro/captures/ and returns capture_ref; available on the local stdio transport only, since the hosted HTTP transport rejects 'capture' and names 'summary' and 'inline' as the valid alternatives."New value: +"Valid values: 'summary' (default), 'inline'. 'summary' returns headline scalars (depletion month or does-not-deplete) and citations with the schedule stripped. 'inline' returns the full payload including the month-by-month schedule[] for chart rendering." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
compare_debt_consolidation6 fields changed- changed
Input schema / properties / extra_monthly_payment / descriptionPrevious value: -"Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums. Optional; defaults to 0 when omitted. fixed_payments is not a parameter of this tool, unlike calculate_cc_payoff: the keep-cards baseline is always simulated under the canonical constant rolled-forward payment (see comparison_basis in the response); supplying fixed_payments returns an unknown_parameter error."New value: +"Extra monthly payment in dollars, $0 to $1,000,000,000, applied on top of the required minimums for keep-cards and any balance transfer, and on top of the loan's own required payment for consolidation. Optional; defaults to 0 when omitted. fixed_payments is not a parameter of this tool, unlike calculate_cc_payoff: the keep-cards baseline is always simulated under the canonical constant rolled-forward payment (see comparison_basis in the response); supplying fixed_payments returns an unknown_parameter error." - removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"Response verbosity: 'summary' (default) | 'inline' | 'capture'. summary: compact response with a data_preview block; no heavy array exists on this response today, so summary and inline are currently identical in content. inline: full payload (currently identical to summary; will diverge once a heavy array is added for chart rendering). capture: full payload written to this server's local disk for the chart-render pipeline; capture_ref URI returned. Available on the local stdio transport only; the hosted HTTP transport rejects 'capture' with a structured error naming 'summary' and 'inline' as the valid alternatives. Optional; defaults to 'summary' when omitted."New value: +"Valid values: 'summary' (default), 'inline'. summary: compact response with a data_preview block; no heavy array exists on this response today, so summary and inline are currently identical in content. inline: full payload (currently identical to summary; will diverge once a heavy array is added for chart rendering)." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string" - changed
Input schema / properties / windfalls / descriptionPrevious value: -"One-time principal payments, at most 12, same shape as calculate_cc_payoff. Optional; a JSON null is treated as omitted, the same as leaving the field out. When non-empty, the response adds windfalls_applied[] and windfalls_unused[] on keep_cards, on each balance_transfer scenario (and on each offer in balance_transfer_offers.offers[]), on consolidation_loan (single-row per windfall since the loan is a single-balance instrument), and on optimized_consolidation.keep_subset. All scenarios use with-windfalls totals so cross-option ranking stays apples-to-apples."New value: +"One-time principal payments, at most 12, same shape as calculate_cc_payoff. Optional; a JSON null is treated as omitted, the same as leaving the field out. When non-empty, the response adds windfalls_applied[] and windfalls_unused[] on keep_cards, on each balance_transfer scenario (and on each offer in balance_transfer_offers.offers[]), on consolidation_loan (single-row per windfall since the loan is a single-balance instrument), and on optimized_consolidation.keep_subset. All scenarios use with-windfalls totals so cross-option ranking stays apples-to-apples, except what_if.same_budget_accelerated, a windfall-free hypothetical about extra-payment behavior, not your actual lump-sum schedule."
- Changed
compare_mortgage_terms1 field changed- changed
Input schema / properties / pmi_removal_ltv_pct / descriptionPrevious value: -"Loan-to-value percentage at which to model borrower-requested PMI removal, 50-100. Optional; when omitted, PMI is modeled as removed at the 78% HPA automatic-termination threshold instead. When the loan's own initial loan-to-value is above 80 percent, the range where PMI applies, a value at or above that initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. At or below 80 percent, no such check runs. Either way PMI also stops at the statutory amortization midpoint of each option's own term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone."New value: +"Loan-to-value percentage at which to model borrower-requested PMI removal, 50-100. Optional; when omitted, PMI is modeled as removed at the 78% HPA automatic-termination threshold instead. The rejection guard applies only when pmi_monthly is above 0 and the loan's own initial LTV is above 80 percent, the range where PMI applies: there, a value at or above that initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. When pmi_monthly is omitted or 0, no such check runs, whatever the LTV, and the supplied value is accepted but changes nothing in the response, because no PMI is modeled in that case. Either way PMI also stops at the statutory amortization midpoint of each option's own term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone."
- Changed
compare_strategies4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"Response verbosity: 'summary' (default) | 'inline' | 'capture'. summary returns the headline comparison with a data_preview block; inline returns the full payload; capture writes the full payload to this server's local disk for the chart-render pipeline and returns a capture_ref URI. capture is available on the local stdio transport only, and the hosted HTTP transport rejects it with a structured error naming 'summary' and 'inline' as the valid alternatives, since a capture_ref would be a dead link for a remote caller. Optional; defaults to 'summary' when omitted."New value: +"Valid values: 'summary' (default), 'inline'. summary returns the headline comparison with a data_preview block; inline returns the full payload." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
optimize_401k_match4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"Response envelope. 'summary' (default): headline scalars, period_schedule stripped. 'inline': full payload including period_schedule[]. 'capture': full payload written to ~/.senaro/captures/, capture_ref URI returned; local stdio transport only, rejected with a structured error on the hosted HTTP transport naming 'summary' and 'inline' as the valid alternatives."New value: +"Valid values: 'summary' (default), 'inline'. Response envelope. 'summary': headline scalars, period_schedule stripped. 'inline': full payload including period_schedule[]." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
payoff_vs_invest4 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"'summary' (default), 'inline', or 'capture'. 'summary' returns headline comparison scalars, milestones, and citations with monthly_schedule stripped. 'inline' returns the full payload including the month-by-month monthly_schedule[]. 'capture' writes the full payload to ~/.senaro/captures/ and returns capture_ref; available on the local stdio transport only, since the hosted HTTP transport rejects 'capture' and names 'summary' and 'inline' as the valid alternatives."New value: +"Valid values: 'summary' (default), 'inline'. 'summary' returns headline comparison scalars, milestones, and citations with monthly_schedule stripped. 'inline' returns the full payload including the month-by-month monthly_schedule[]." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string"
- Changed
rent_vs_buy5 fields changed- removed
Input schema / properties / output / defaultRemoved value: -null - changed
Input schema / properties / output / descriptionPrevious value: -"'summary' (default), 'inline', or 'capture'. 'summary' returns headline scalars and per-horizon snapshots with the heavy series stripped. 'inline' returns the full payload including yearly_series[] and monthly_series[] for chart rendering. 'capture' writes the full payload to ~/.senaro/captures/ and returns capture_ref; available on the local stdio transport only, since the hosted HTTP transport rejects 'capture' and names 'summary' and 'inline' as the valid alternatives."New value: +"Valid values: 'summary' (default), 'inline'. 'summary' returns headline scalars and per-horizon snapshots with the heavy series stripped. 'inline' returns the full payload including yearly_series[] and monthly_series[] for chart rendering." - added
Input schema / properties / output / enumAdded value: +[ + "summary", + "inline" +] - changed
Input schema / properties / output / typePrevious value: -[ - "string", - "null" -]New value: +"string" - changed
Input schema / properties / pmi_removal_ltv_pct / descriptionPrevious value: -"Loan-balance trigger for PMI removal, as a percentage loan-to-value. Decimal from 50 to 100. Optional; omitted, it is the 78% HPA automatic-termination threshold; provided (e.g. 80), it is whichever of 78% or your value is reached first. Either way PMI also stops at the statutory amortization midpoint of the original term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone."New value: +"Loan-balance trigger for PMI removal, as a percentage loan-to-value. Decimal from 50 to 100. Optional; omitted, it is the 78% HPA automatic-termination threshold; provided (e.g. 80), it is whichever of 78% or your value is reached first. The rejection guard applies only when down_payment_pct is below 20 and the resolved pmi_pct is above 0, the range where PMI applies: there, a value at or above the loan's own initial LTV is rejected, because the requested removal point would already be met at the first payment, so no PMI would be modeled for any month of the loan. When the resolved pmi_pct is 0, or down_payment_pct is 20 or more, no such check runs, whatever the LTV. Either way PMI also stops at the statutory amortization midpoint of the original term (12 U.S.C. §4901(7), §4902(c)), which this value cannot postpone."
Publisher details
- Operator
- Senaro · Publisher source
- Operator website
- https://senaro.ai
- Vendor relationship
- First-party
- Documentation
- https://mcp.senaro.ai/mcp
- Trust center
- Not available
- Restrictions
- None. Open endpoint with no authentication, no API key, no sign-up, no paid plan, no admin approval, and no regional restriction.
Related MCP Connectors
Cited, receipt-backed US home-buying data & calculators — education-only, every number sourced.
Deterministic US financial planning: retirement Monte Carlo, Roth conversion, RMD, tax, IRMAA, SS
2025 HMDA FHA denial statistics and dated US mortgage rule tables, with receipts you can verify.
Verbatim U.S. mortgage regulatory text with citations and effective dates. Read-only, no sign-in.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenance55 Concordance-tested financial models with published specs; responses cite assumptions and sources.MIT

WealthSchemaofficial
AlicenseAqualityCmaintenanceCited 2026 and 2027 U.S. financial-planning figures (IRS, SSA, CMS), synthetic household samples, and an AI financial-advice benchmark.8MIT- AlicenseBqualityCmaintenanceProvides 77 deterministic financial calculators, live market data, and a meta-advisor that chains tools into prioritized plans from plain-language descriptions.7738 PyPI6MIT
- AlicenseAqualityBmaintenanceEnables users to look up and search Australian SMSF rules — contribution caps, total super balance and Division 296 thresholds, pension minimums and lodgment deadlines — and to compute contribution headroom, every answer carrying an ato.gov.au or legislation.gov.au citation. It is read-only and deterministic, with no model calls or network access at call time.6MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.