SmartFin

Put a SmartFin calculator on a website

smartfin_get_embed_code

Read-onlyIdempotent

The HTML to put one of SmartFin's free calculators on a website the user runs: a blog post, a class or library page, a client resources page. One iframe line, free, no sign-up, no cookies or tracking; the widget fills the width it's given and follows the reader's light or dark mode. Calculators: compare_two_stocks (Compare Two Stocks), simulator (Stock Returns Over Time), investment (Investment growth calculator), compound_interest (Compound interest calculator), mortgage (Mortgage calculator), car_loan (Car loan calculator), student_loan (Student loan calculator), refinance (Refinance calculator), mortgage_payoff (Mortgage payoff calculator), down_payment (Down payment calculator), cagr (CAGR calculator), rule_of_72 (Rule of 72 calculator), inflation (Inflation calculator), fire (FIRE calculator), withdrawal (Withdrawal planner), savings_vs_investing (Savings vs investing calculator), rent_vs_buy (Rent vs buy calculator), simple_interest (Simple interest calculator), future_value (Future value calculator), present_value (Present value calculator), roi (ROI calculator), profit_margin (Profit margin calculator). Use when the user wants a calculator on their own site or asks how to add one. Do not use to calculate anything (use the other smartfin_ tools).

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": {
      "calculator": "<calculator>"
    },
    "name": "smartfin_get_embed_code"
  }
}

Input Schema

Name	Required	Description	Default
`currency`	No	Show this currency to every reader. Omit to let each reader choose
`calculator`	Yes	Which calculator to embed

Output 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.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / calculator / enum

Previous value: -[
-  "compare_two_stocks",
-  "investment",
-  "compound_interest",
-  "mortgage",
-  "car_loan",
-  "student_loan",
-  "refinance",
-  "mortgage_payoff",
-  "down_payment",
-  "cagr",
-  "rule_of_72",
-  "inflation",
-  "fire",
-  "withdrawal",
-  "savings_vs_investing",
-  "rent_vs_buy",
-  "simple_interest",
-  "future_value",
-  "present_value",
-  "roi",
-  "profit_margin"
-]New value: +[
+  "compare_two_stocks",
+  "simulator",
+  "investment",
+  "compound_interest",
+  "mortgage",
+  "car_loan",
+  "student_loan",
+  "refinance",
+  "mortgage_payoff",
+  "down_payment",
+  "cagr",
+  "rule_of_72",
+  "inflation",
+  "fire",
+  "withdrawal",
+  "savings_vs_investing",
+  "rent_vs_buy",
+  "simple_interest",
+  "future_value",
+  "present_value",
+  "roi",
+  "profit_margin"
+]

Changed1 schema field changedOct 18, 2026

changedInput schema / properties / calculator / enum

Previous value: -[
-  "investment",
-  "compound_interest",
-  "mortgage",
-  "car_loan",
-  "student_loan",
-  "refinance",
-  "cagr",
-  "rule_of_72",
-  "inflation",
-  "fire",
-  "withdrawal",
-  "savings_vs_investing",
-  "rent_vs_buy",
-  "simple_interest",
-  "future_value",
-  "present_value",
-  "roi",
-  "profit_margin"
-]New value: +[
+  "compare_two_stocks",
+  "investment",
+  "compound_interest",
+  "mortgage",
+  "car_loan",
+  "student_loan",
+  "refinance",
+  "mortgage_payoff",
+  "down_payment",
+  "cagr",
+  "rule_of_72",
+  "inflation",
+  "fire",
+  "withdrawal",
+  "savings_vs_investing",
+  "rent_vs_buy",
+  "simple_interest",
+  "future_value",
+  "present_value",
+  "roi",
+  "profit_margin"
+]

Changed1 schema field changedOct 13, 2026

changedInput schema / properties / calculator / enum

Previous value: -[
-  "investment",
-  "compound_interest",
-  "mortgage",
-  "car_loan",
-  "student_loan",
-  "refinance",
-  "cagr",
-  "rule_of_72",
-  "inflation",
-  "fire",
-  "withdrawal"
-]New value: +[
+  "investment",
+  "compound_interest",
+  "mortgage",
+  "car_loan",
+  "student_loan",
+  "refinance",
+  "cagr",
+  "rule_of_72",
+  "inflation",
+  "fire",
+  "withdrawal",
+  "savings_vs_investing",
+  "rent_vs_buy",
+  "simple_interest",
+  "future_value",
+  "present_value",
+  "roi",
+  "profit_margin"
+]

Changed1 schema field changedSep 29, 2026

addedOutput schema / properties / links / properties / page

Added value: +{
+  "description": "SmartFin's page for this stock, when it has one",
+  "type": "string"
+}

First observedSep 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered. The description adds genuinely non-obvious traits: free, no sign-up, no cookies or tracking, the widget fills its container width, and it follows the reader's light/dark mode. It stops short of describing pagination/response shape, but that is largely carried by the output schema.

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 deliverable and the usage boundary are front-loaded, and the long calculator enumeration earns its length by mapping terse enum keys to recognizable names. Still, the 22-item inline list is the bulk of the text and could have been compressed, costing it a perfect mark.

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?

An output schema exists, so return-value explanation is not required, and the description covers purpose, triggers, exclusions, and all calculator choices. The only gap is the optional `currency` behavior, which the schema documents but the description never mentions.

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 3 would be the baseline; the description earns above that by spelling out every enum value for `calculator` paired with a human-readable label (e.g. 'cagr (CAGR calculator)', 'fire (FIRE calculator)'), which aids selection. It says nothing about the `currency` parameter, leaving that entirely to 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 deliverable ('The HTML to put one of SmartFin's free calculators on a website') with the exact scope (one iframe line, embedding on the user's own site). It explicitly names the boundary against the calculate_* siblings, so an agent can distinguish it 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.

Usage Guidelines5/5

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

It gives an explicit positive trigger ('Use when the user wants a calculator on their own site or asks how to add one') and an explicit negative one ('Do not use to calculate anything (use the other smartfin_ tools)'), which is the exact sibling routing an agent needs.

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?