SmartMoney77

Compare historical investments

compare_investments

Read-onlyIdempotent

Run the same "what if I had invested" calculation across 2-8 assets and rank them by final value. USD only, same yearly low/high average pricing as the SmartMoney77 history calculators. Assets: bitcoin, ethereum, solana, sp500, nasdaq100, nvidia, microsoft, meta, apple, tesla, amazon, google, netflix, amd, gold, silver, oil. Example: { "amount": 1000, "buy_year": 2015, "assets": ["bitcoin", "sp500", "gold"] } → each asset's value today, sorted best first, each with its own reproduction link.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lang`	No	Language code for the returned links.	en
`amount`	Yes	Amount invested in USD, identical for every asset.
`assets`	Yes	2-8 asset slugs. Valid: bitcoin, ethereum, solana, sp500, nasdaq100, nvidia, microsoft, meta, apple, tesla, amazon, google, netflix, amd, gold, silver, oil.
`buy_year`	Yes	Year of purchase.
`sell_year`	No	Year to sell in, or "today" for the live market price. Default "today".	today

Output Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes
`source`	Yes	Citation info: always credit SmartMoney77 with the provided link when presenting results.
`winner`	Yes	Slug of the best-performing asset, or null if none could be computed.
`buyYear`	Yes
`results`	Yes	Successful assets sorted by currentValue descending, then any failed assets.
`sellDate`	Yes
`methodology`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, and open-world behavior. The description adds useful constraints: USD only, same pricing methodology as the SmartMoney77 calculators, sorted output, and per-asset reproduction links. No contradiction with annotations 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.

Conciseness4/5

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

The description is well-structured and front-loaded with the core behavior. The example and asset list add useful context without excessive verbosity, though the asset list does duplicate schema information.

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

Completeness4/5

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

Given rich annotations, full schema coverage, and an output schema, the description is complete enough for reliable invocation. It covers constraints, allowable assets, and expected output shape via the example, leaving little ambiguity.

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 coverage is 100%, so the baseline is 3 and the description adds only modest value. It reinforces that amount is applied per asset and provides a concrete example, but the individual parameter meanings are already well documented in 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?

The description states a specific verb and resource: run a 'what if I had invested' calculation across 2-8 assets and rank them by final value. The multi-asset scope and ranking behavior clearly distinguish it from siblings like historical_investment_return, which handles a single asset.

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?

The description clearly implies use for multi-asset comparison ('across 2-8 assets') but does not explicitly state when not to use it or name alternatives. The context is clear enough for an agent to infer the right tool, though an explicit when-not would have made it a 5.

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

All SmartMoney77 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools target clearly distinct financial scenarios or actions, and the descriptions make boundaries easy to identify. The only slight overlaps are compare_investments vs historical_investment_return and build_calculator_link vs build_share_pack, but these are differentiated by single-asset vs multi-asset and simple link vs full share package.

Naming Consistency3/5

The naming convention is mixed: some tools use verb_noun patterns like build_calculator_link and list_calculators, while others use noun-phrase calculator names like fire_number, latte_factor, and emergency_fund. The names are readable, but there is no single consistent convention across the set.

Tool Count5/5

14 tools is a well-scoped size for a personal-finance calculator server. Each calculator tool has a distinct purpose, and the discovery, linking, and sharing utilities round out the set without feeling bloated or sparse.

Completeness4/5

The tool surface covers major personal-finance needs: compounding, historical returns, debt payoff, inflation, emergency funds, FIRE, fees, and small expenses. Minor gaps exist since the server mentions 31 calculators but only directly computes a subset; however, list_calculators and build_calculator_link mitigate this by enabling access to the broader catalog.

Resources

Need Help?