Amaltash Investment & Retirement Calculators

Investment Calculator

plan_recurring_investment

Read-onlyIdempotent

Investment growth calculator with an interactive chart. Works out what regular deposits could grow to at a long-run market average or a yearly rate you choose. Use it for monthly investment plans and questions like what $10 a day or $500 a month could become in 20 or 30 years. Single stocks cannot be run forward.

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount": "<amount>",
      "cadence": "<cadence>",
      "years": "<years>"
    },
    "name": "plan_recurring_investment"
  }
}

Input Schema

Name	Required	Description
`asset`	No	A long-run rate to use. Give this or custom_annual_percent, not both.
`years`	Yes	Whole years, 1 to 60.
`amount`	Yes	Dollars put in each time, above 0.
`cadence`	Yes	How often the amount goes in.
`starting_amount`	No	Dollars already invested. Defaults to 0.
`custom_annual_percent`	No	Your own yearly return in percent, so 7 means 7%. Give this or asset, not both.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already establish that this is a read-only, idempotent, closed-world calculation, so the description need not restate safety. It adds the useful behavioral constraint that single stocks cannot be projected and notes the output includes an interactive chart, but says nothing about the assumptions behind the built-in rates or about caveats/limits on the projections.

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?

Four short sentences that lead with what the tool computes and follow with examples and a constraint; no filler or repetition. The "interactive chart" phrase is the only mildly decorative element, and it does convey what the response looks like.

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

Completeness3/5

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

For a read-only calculator with full schema coverage this is close to adequate, and the mention of the chart partially compensates for the absent output schema. Gaps remain around the built-in asset choices and the assumptions/limits of the projection, which an agent would need in order to call it confidently.

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 in-schema, so the baseline is 3. The description adds framing that the rate option is a long-run average and that cadence examples map to day/month deposits, but it never expands the cryptic asset keys (sp, 6040, bills, lost), leaving the most opaque parameter unexplained in both places.

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

Purpose4/5

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

The description states a specific calculation (growth of regular deposits) plus the mechanisms it uses (long-run market average or a chosen yearly rate), which is far more than a restatement of the name. It does not, however, distinguish itself from near siblings like compound_interest or dca_vs_lump_sum, so an agent still has to infer which calculator applies.

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

Usage Guidelines4/5

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

Concrete usage examples ("what $10 a day or $500 a month could become in 20 or 30 years") tell the agent which question shapes this tool fits, and "Single stocks cannot be run forward" is an explicit exclusion that prevents a common misuse. What is missing is naming the alternative tool for the excluded case or for one-off/compound comparisons.

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

All Amaltash Investment & Retirement Calculators tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?