SmartFin

Future value of an amount

smartfin_calculate_future_value

Read-onlyIdempotent

What a single present amount grows to at a fixed yearly rate with interest added to the balance at a chosen frequency, and the growth over the starting amount (FV = PV x (1 + r/n)^(n x t)). Use for questions about what a lump sum becomes after some years at an assumed rate, or the effect of compounding more often. Do not use for regular contributions (use smartfin_project_savings_growth), for what a real stock did (use smartfin_calculate_investment_return), or for a forecast: one fixed rate is an assumption. To find the starting amount, rate or time instead of the future value, use smartfin_calculate_missing_variable.

Input Schema

TableJSON Schema

Name	Required	Description
`years`	Yes	Time in years; a part of a year is a decimal
`currency`	No	Currency symbol for the amounts in the summary only; amounts are never converted. The link opens the page in US dollars, and how_to says to pick the currency there. Default USD
`present_value`	Yes	Amount today in the currency chosen
`annual_rate_pct`	Yes	Yearly rate in %, above -100, e.g. 6
`compounding_frequency`	Yes	Times a year interest is added: 1 annually, 2 semiannually, 4 quarterly, 12 monthly, 52 weekly, 365 daily

Output Schema

TableJSON Schema

Name	Required	Description
`cite`	Yes	How to credit this result
`data`	Yes
`next`	Yes	Suggested follow-up calls
`links`	Yes
`how_to`	Yes	Steps for the user to see or redo this on smartfin.fyi
`source`	Yes
`summary`	Yes	Plain-language result the assistant can quote

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / currency

Added value: +{
+  "description": "Currency symbol for the amounts in the summary only; amounts are never converted. The link opens the page in US dollars, and how_to says to pick the currency there. Default USD",
+  "enum": [
+    "USD",
+    "EUR",
+    "GBP",
+    "CHF",
+    "AUD",
+    "CAD",
+    "SGD",
+    "HKD",
+    "INR",
+    "JPY"
+  ],
+  "type": "string"
+}

changedInput schema / properties / present_value / description

Previous value: -"Amount today in dollars"New value: +"Amount today in the currency chosen"

AddedOct 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's job is to add context beyond that. It does, by framing the output as an assumption-driven forecast rather than a real outcome ('one fixed rate is an assumption'), which is meaningful framing an agent should repeat to a user. It does not, however, mention constraints like the year cap or rate bounds, which the schema carries instead.

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 the operation and formula, then routing sentences, with zero filler. It is dense in places (three sibling redirects plus a forecast caveat), but each sentence earns its place by eliminating a specific mis-selection.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, and the description covers purpose, selection boundaries, and the interpretive caveat. For a five-parameter, fully documented calculation tool, an agent has everything needed to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100% and both enums are documented inline, so the baseline is 3. The description restates the parameter roles ('fixed yearly rate', 'chosen frequency') and the formula clarifies how the four required inputs interact, but it adds no syntax, default, or boundary detail beyond the schema.

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 precise verb+resource (what a single present amount grows to) and reinforces it with the exact formula FV = PV x (1 + r/n)^(n x t). It explicitly names the two closest siblings it is not (smartfin_project_savings_growth, smartfin_calculate_investment_return), so an agent can disambiguate 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.

Usage Guidelines5/5

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

Gives explicit when-to-use cases (a lump sum after some years, effect of compounding more often) and explicit when-not cases with named alternatives: regular contributions → project_savings_growth, actual stock performance → calculate_investment_return, and solving for another variable → calculate_missing_variable. 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.

All SmartFin tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?