Skip to main content
Glama

Save for a home down payment

smartfin_calculate_down_payment
Read-onlyIdempotent

How long savings take to reach a home down payment, from what is saved so far plus the same amount each month growing at a fixed yearly rate, and, with reach_within_months, the monthly amount that reaches it by then, the way SmartFin's down payment calculator does. Returns the down payment, the loan amount it leaves, the months to reach it (within 50 years), the modeled savings split into saved so far, deposits and growth, and the monthly amount (rounded up to a whole currency unit) that reaches it within the chosen time. Use when someone asks how long it takes to save for a down payment, how much a month reaches one by a date, or what a percentage down is on a price. Do not use for how much to put down (it does not say), mortgage approval, closing costs (not included) or the mortgage payment (use smartfin_calculate_loan_payment). The growth rate is held constant, deposits are made at the end of each month and the home price stays the same. Amounts can be in any one currency; none is converted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
currencyNoCurrency for the amounts in the summary and the link. Default USD; amounts are never converted
home_priceYesPrice of the home. 1000 to 100000000
saved_so_farNoAmount saved toward it today. Default 0. 0 to 100000000
growth_rate_pctNoYearly rate the savings grow at, with compounding included (a savings account's APY in the US, AER in the UK), held the same every year. Default 3, an example, not a current rate. 0 to 20
down_payment_pctNoDown payment as % of the price. Give this or down_payment_amount. Default 20. 0 to 100
mortgage_rate_pctNoOptional: the mortgage rate, % a year, with mortgage_term_years, to suggest the follow-up call for the payment on the loan amount
saving_each_monthNoAmount added at the end of every month. Default 0. 0 to 10000000
down_payment_amountNoDown payment as an amount instead of a %; at most the home price. Give this or down_payment_pct
mortgage_term_yearsNoOptional: the mortgage term in years, with mortgage_rate_pct
reach_within_monthsNoA time to reach it by, in months, for the monthly amount that does: 48 is 4 years. 0 or omitted for none. 0 to 600

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
citeYesHow to credit this result
dataYes
nextYesSuggested follow-up calls
linksYes
how_toYesSteps for the user to see or redo this on smartfin.fyi
sourceYes
summaryYesPlain-language result the assistant can quote

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the read-only/idempotent/no-destruction profile, and the description goes further by disclosing modeling assumptions an agent could not infer: constant growth rate, deposits at end of each month, unchanging home price, and no currency conversion. These materially affect interpretation of the results.

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

Conciseness4/5

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

Front-loaded with purpose, then usage, then caveats, and almost every clause carries information. The opening sentence is a dense run-on that takes effort to parse, and the enumerating of return fields is partly redundant given the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema and fully covered parameters, the remaining description burden is scope and assumptions, both addressed (exclusions, constant rate, end-of-month deposits, no conversion). Some return-field restatement is unnecessary but harmless; nothing needed to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds role-level meaning beyond the schema: reach_within_months switches the tool into solving for the monthly amount, and down_payment_pct is framed as 'what a percentage down is on a price'. It does not add format/units detail beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific computation: time for savings (existing + monthly deposits at a fixed growth rate) to reach a down payment target, plus the reverse solve for a monthly amount given reach_within_months. It is clearly separable from sibling calculators, and it explicitly routes the mortgage-payment need to smartfin_calculate_loan_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggers ('how long it takes to save for a down payment', 'how much a month reaches one by a date', 'what a percentage down is on a price') and explicit exclusions ('Do not use for how much to put down', mortgage approval, closing costs) with the named alternative for the mortgage payment case.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources