How do I use wealth-engine?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wealth-engine How much will $10k grow in 30 years at 7% with $500/month?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

wealth-engine

by Jaume9

Overview Schema Related Servers Score Discussions

TypeScript

Local

💰 Wealth Engine MCP

An MCP server that helps you make more money and keep more of it — a complete personal-finance and business-economics toolkit your AI assistant can use to give you real, math-backed answers.

No API keys. No accounts. No network calls. Every answer is computed locally from battle-tested financial formulas, so it works the moment you install it and produces the same numbers every time.

The honest truth: software can't literally print money. But the decisions these tools inform — charging the right freelance rate, pricing a product at the profit-maximizing point, killing the avalanche of interest on your debt, picking the investment with the best risk-adjusted return — are worth a lot of money over a lifetime. That's where the leverage is.

Why this exists

Most "money" advice is vibes. This is arithmetic. Each tool implements the actual formula a financial analyst would use, returns a transparent breakdown (not just a single number), and is covered by tests that check it against known-correct values.

✅ 11 financial tools, each a real engine
✅ Zero setup — no keys, no DB, runs over stdio
✅ 58 passing tests validating the math against closed-form results
✅ Strict TypeScript, structured JSON output for both humans and agents
✅ Works in Cursor, Claude Desktop, and any MCP client

Related MCP server: finance-calc-mcp

The tools

Tool	What it answers
`compound_growth`	"If I invest $X and add $Y/month at Z%, what will it become?" (with inflation-adjusted real value)
`loan_amortization`	"What's my mortgage payment, and how much do extra payments save me?"
`debt_payoff`	"What's the fastest, cheapest way out of my debts — avalanche or snowball?"
`fire_calculator`	"How big a portfolio do I need to retire, and how many years until I'm financially independent?"
`freelance_rate`	"What hourly rate must I actually charge to hit my income goal?"
`price_optimizer`	"What price maximizes my profit, given how demand responds?"
`roi_compare`	"Which opportunity creates the most value?" (ROI, payback, NPV, IRR)
`tax_estimate`	"What's my income tax, effective rate, and marginal rate?"
`budget_analyzer`	"Where is my money leaking vs the 50/30/20 rule?"
`subscription_audit`	"How much can I recover by cutting low-value subscriptions?"
`side_hustle_ranker`	"Which side hustle is worth my time, risk-adjusted?"

Install

1. Build it

npm install
npm run build

This produces dist/index.js, the runnable MCP server.

2. Register it with your MCP client

Cursor

Create or edit .cursor/mcp.json in your project (or ~/.cursor/mcp.json for global use):

{
  "mcpServers": {
    "wealth-engine": {
      "command": "node",
      "args": ["C:/Users/jejej/OneDrive/Escritorio/github_projects/mcp/dist/index.js"]
    }
  }
}

Then open Cursor → Settings → MCP and confirm wealth-engine shows 11 tools. Ask the agent something like "Use the freelance rate tool to tell me what to charge for a $150k target."

Claude Desktop

Edit claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "wealth-engine": {
      "command": "node",
      "args": ["C:/Users/jejej/OneDrive/Escritorio/github_projects/mcp/dist/index.js"]
    }
  }
}

Restart Claude Desktop. The tools appear under the 🔌 menu.

Tip: During development you can skip the build step and run the TypeScript directly with "command": "npx", "args": ["tsx", "/abs/path/src/index.ts"].

Tool reference & examples

Every tool accepts a JSON object and returns both a human-readable text block and machine-readable structuredContent. Below are representative inputs and the headline outputs.

`compound_growth`

{
  "principal": 10000,
  "contribution": 500,
  "annualRatePct": 7,
  "years": 30,
  "periodsPerYear": 12,
  "annualInflationPct": 2.5
}

Returns futureValue, totalContributed, totalInterest, realFutureValue (today's purchasing power), growthMultiple, and a year-by-year schedule.

`loan_amortization`

{ "amount": 400000, "annualRatePct": 6.5, "years": 30, "extraPayment": 300 }

Returns the periodicPayment, totalInterest, payoffYears, interestSavedVsNoExtra, and a full amortization schedule.

`debt_payoff`

{
  "debts": [
    { "name": "Visa", "balance": 6000, "annualRatePct": 24.99, "minPayment": 150 },
    { "name": "Car",  "balance": 12000, "annualRatePct": 6.5,  "minPayment": 280 }
  ],
  "monthlyBudget": 900,
  "strategy": "compare"
}

compare (default) runs avalanche and snowball, reports monthsToDebtFree and totalInterestPaid for each, and tells you which is cheaper and by how much.

`fire_calculator`

{ "annualIncome": 120000, "annualExpenses": 48000, "currentInvestments": 80000, "realReturnPct": 5 }

Returns your fireNumber, savingsRate, yearsToFire, plus leanFireNumber and fatFireNumber.

`freelance_rate`

{
  "targetAnnualIncome": 150000,
  "annualBusinessExpenses": 12000,
  "taxRatePct": 30,
  "workingWeeksPerYear": 46,
  "billableUtilization": 0.6
}

Returns the hourlyRate and dayRate you must charge, the billableHoursPerYear, and how that compares to the naive salary / 2080 mistake (vsNaiveSalaryRate).

`price_optimizer`

{
  "demandPoints": [
    { "price": 29, "quantity": 420 },
    { "price": 39, "quantity": 300 },
    { "price": 49, "quantity": 190 }
  ],
  "unitCost": 8,
  "fixedCost": 2000
}

Fits a linear demand curve, then returns the optimalPrice (profit-max), revenueMaximizingPrice, the fitted demandModel with R², and a transparent price sweep.

`roi_compare`

{
  "investments": [
    { "name": "Rental",   "cashFlows": [-50000, 6000, 6000, 6000, 6000, 76000] },
    { "name": "Business", "cashFlows": [-50000, 0, 20000, 30000, 40000] }
  ],
  "discountRatePct": 8
}

Returns per-investment roi, paybackPeriod, npv, irrPct, and the winners bestByNpv / bestByRoi / bestByIrr.

`tax_estimate`

{ "income": 95000, "deduction": 14600 }

Defaults to US 2024 single-filer federal brackets (override with your own brackets for any country/year). Returns totalTax, afterTaxIncome, effectiveRatePct, marginalRatePct, and the per-bracket breakdown.

`budget_analyzer`

{
  "monthlyIncome": 6000,
  "categories": [
    { "name": "Rent", "amount": 2200, "type": "needs" },
    { "name": "Dining", "amount": 800, "type": "wants" },
    { "name": "Index funds", "amount": 1200, "type": "savings" }
  ]
}

Compares your split to 50/30/20, finds unallocated money and overspending gaps, and returns concrete recommendations.

`subscription_audit`

{
  "subscriptions": [
    { "name": "Streaming A", "amount": 15.99, "cycle": "monthly", "usesPerMonth": 12, "valueRating": 4 },
    { "name": "Gym",         "amount": 60,    "cycle": "monthly", "usesPerMonth": 1,  "valueRating": 2 }
  ]
}

Annualizes every line, computes costPerUse, flags each as keep / review / cut, and totals potentialAnnualSavings.

`side_hustle_ranker`

{
  "hustles": [
    { "name": "Consulting", "monthlyRevenue": 4000, "hoursPerMonth": 30, "successProbability": 0.9 },
    { "name": "Print shop", "monthlyRevenue": 2500, "monthlyCost": 600, "hoursPerMonth": 60, "startupCost": 5000, "rampMonths": 4, "successProbability": 0.6 }
  ]
}

Ranks by risk-adjusted effective hourly value, with breakEvenMonths and expectedYearOneProfit for each.

Development

npm run dev        # run the server from TypeScript (tsx)
npm run typecheck  # strict type checking, no emit
npm test           # run the full vitest suite
npm run test:watch # watch mode
npm run build      # compile to dist/

Project layout

src/
  index.ts            # stdio entry point (the MCP process)
  server.ts           # registers all 11 tools with Zod schemas
  finance/            # pure, dependency-free financial engines
    compound.ts  loan.ts  debt.ts  fire.ts  freelance.ts
    pricing.ts   roi.ts   tax.ts   budget.ts  subscriptions.ts
    sideHustle.ts  money.ts
test/                 # one spec per engine + an end-to-end server test

The design rule: all math lives in src/finance/ as pure functions with no MCP or I/O dependencies. The server is a thin adapter. That keeps the logic trivially testable and reusable.

How the numbers are validated

The tests don't just check "it runs" — they assert against independently-derived values:

Compound growth is checked against the closed-form annuity future-value formula.
Loan amortization is checked against the standard mortgage payment (a $100k/6%/30yr loan → ~$599.55/mo, ~$115,838 total interest).
Tax is checked bracket-by-bracket against hand-computed US 2024 figures.
IRR is checked against known multi-period rates and the trivial [-100, 110] → 10% case.
Price optimization is checked against the analytic optimum of a known linear demand curve.
An end-to-end test spins up the server over an in-memory transport, lists the tools, and calls them through the real MCP protocol.

Run npm test to see all 58 pass.

Disclaimer

This is an educational/decision-support tool, not financial, tax, investment, or legal advice. Tax brackets and assumptions are illustrative defaults — verify against current rules for your jurisdiction, and consult a qualified professional before making consequential decisions.

License

MIT — see LICENSE.

Available Tools

11 tools

budget_analyzer50/30/20 Budget AnalyzerA

Analyze a monthly budget against the 50/30/20 rule (needs/wants/savings). Surfaces overspending, unallocated money, your actual split vs the target, and concrete recommendations to raise your savings rate.

ParametersJSON Schema

Name	Required	Description	Default
`categories`	Yes	Your budget categories.
`monthlyIncome`	Yes	Monthly take-home income.

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It transparently describes the tool as an analyzer that surfaces overspending and recommendations, implying read-only, non-destructive behavior. However, it does not explicitly state that no modifications occur or mention any side effects.

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

Conciseness5/5

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

Two sentences with no redundancy. The first sentence identifies the purpose and rule, the second lists actionable outputs. Perfectly front-loaded and efficient.

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?

Given two parameters and no output schema, the description fully covers input requirements and expected results (overspending, unallocated money, split comparison, recommendations). No gaps remain.

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 baseline is 3. The description adds overall context (50/30/20 rule) but does not enhance understanding of individual parameters beyond the schema, which already describes them clearly.

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 clearly states it analyzes a monthly budget against the 50/30/20 rule, listing specific outputs like overspending and recommendations. This distinguishes it from sibling financial calculators such as debt_payoff or fire_calculator.

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

Usage Guidelines3/5

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

The description implicitly indicates use for budget analysis but provides no explicit guidance on when to use this tool vs alternatives like side_hustle_ranker or subscription_audit. No when-not-to-use or context hints are given.

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

compound_growthInvestment Growth ProjectionA

Project how an investment grows over time with optional recurring contributions and compounding. Returns the future value, total contributed, interest earned, an inflation-adjusted 'real' value, and a year-by-year schedule. Use this to answer 'how much will my investing turn into?'.

ParametersJSON Schema

Name	Required	Description
`years`	Yes	Number of years to project.
`principal`	Yes	Starting balance / lump sum invested today.
`contribution`	No	Recurring contribution added each period. Default 0.
`annualRatePct`	Yes	Expected nominal annual return, in percent (e.g. 7 for 7%).
`periodsPerYear`	No	Contribution & compounding periods per year (12 = monthly). Default 12.
`annualInflationPct`	No	Annual inflation rate (percent) used for the real-value column. Default 0.
`contributionTiming`	No	Whether contributions land at the end or beginning of each period. Default 'end'.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations, but description discloses outputs and optional features. For a stateless calculator, this is sufficient; no contradictions or missing critical behavioral traits.

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

Conciseness5/5

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

Two sentences: first defines action and output, second provides usage context. No fluff, front-loaded, every sentence earns its place.

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?

Lists return values and mentions inflation adjustment and schedule, but no output schema. For a financial calculator, this is fairly complete; a bit more detail on the schedule format could improve, but not required for clarity.

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 baseline is 3. Description adds minimal per-parameter detail beyond schema, tying parameters to overall calculation but not enriching individual parameter meanings.

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?

Explicitly states it projects investment growth with compounding and contributions, lists return values (future value, total contributed, interest earned, real value, schedule), and provides a clear use-case question.

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?

Clear context: 'how much will my investing turn into?'. Does not explicitly mention when not to use or suggest alternatives among sibling tools, but the usage context is well-defined.

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

debt_payoffDebt Payoff Planner (Avalanche vs Snowball)A

Plan how to get out of debt fastest. Simulates month-by-month payoff of multiple debts using the avalanche (highest interest first) and/or snowball (smallest balance first) methods, rolling freed-up payments onto the next target. Reports months to debt-free, total interest, and which strategy wins.

ParametersJSON Schema

Name	Required	Description
`debts`	Yes	The list of debts to pay off.
`strategy`	No	Which strategy to run. 'compare' (default) runs both and recommends the cheaper one.
`monthlyBudget`	Yes	Total dollars available for debt each month (must be >= sum of minimum payments).

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explains the simulation behavior, including rolling freed-up payments and reporting months to debt-free and total interest. However, it does not disclose any underlying assumptions or limitations, such as interest rate constancy.

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

Conciseness5/5

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

The description is two sentences, concise and well-structured. It front-loads the core action and includes key details without unnecessary words.

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 no output schema, the description mentions expected results (months to debt-free, total interest, winning strategy). It covers the main behavior and output, though it could mention edge cases or prerequisites (e.g., ensuring monthlyBudget >= sum of minimum payments).

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% with descriptions for all parameters. The tool description adds context about avalanche vs. snowball methods and rolling payments, enhancing understanding beyond the schema. It does not add new parameter details but reinforces their use.

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 clearly states the tool's purpose: planning debt payoff using avalanche and/or snowball methods, simulating month-by-month, and reporting results. The title and content distinguish it from sibling tools like budget_analyzer and loan_amortization.

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus siblings. It only describes what it does, leaving the agent to infer usage context from the tool's name and category.

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

fire_calculatorFinancial Independence (FIRE) CalculatorA

Compute your FIRE number (the portfolio needed to live off withdrawals), your savings rate, and how many years until you reach financial independence given your income, expenses, current investments, and expected real return. Also reports lean-FIRE and fat-FIRE targets.

ParametersJSON Schema

Name	Required	Description
`annualIncome`	Yes	After-tax annual income.
`realReturnPct`	No	Expected inflation-adjusted annual return, in percent. Default 5.
`annualExpenses`	Yes	Annual spending (also used as retirement spending).
`withdrawalRatePct`	No	Safe withdrawal rate, in percent. Default 4 (the '4% rule').
`currentInvestments`	No	Current invested net worth. Default 0.

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description sets expectations by mentioning it computes estimates based on inputs and assumed return/withdrawal rates. It discloses after-tax income and inflation-adjusted return, adding behavioral context beyond the 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 description is concise with two sentences, front-loaded with the main purpose. It efficiently conveys required inputs and outputs, though it could be slightly more telegraphic.

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 the tool has 5 parameters, no output schema, and no annotations, the description adequately explains what it does and key outputs. It misses some delimitations (constant spending, no inflation variable), but is complete enough for a calculator.

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 baseline is 3. The description does not add new parameter details beyond what the schema provides, but listing outputs (FIRE number, savings rate, years) aids understanding of parameter roles. No significant added value.

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 clearly specifies the tool computes FIRE number, savings rate, and years to FI using income, expenses, investments, and return. It uses specific verbs and distinguishes from sibling tools like compound_growth and budget_analyzer.

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

Usage Guidelines3/5

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

The description implicitly indicates use for retirement planning, but lacks explicit when-to-use, when-not-to-use, or alternative tools. Given sibling names, the context is somewhat clear but could be more directive.

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

freelance_rateFreelance / Consulting Rate CalculatorA

Calculate the hourly rate a freelancer or consultant must charge to actually hit a target take-home income, correctly accounting for non-billable time, vacation, taxes, and business expenses. Stops you from under-charging by using your old salary divided by 2080.

ParametersJSON Schema

Name	Required	Description
`taxRatePct`	No	Effective tax + self-employment rate, percent. Default 25.
`hoursPerWeek`	No	Total work hours per week. Default 40.
`targetAnnualIncome`	Yes	Take-home income you want, after business expenses.
`billableUtilization`	No	Fraction of work hours that are billable (0..1). Default 0.6.
`workingWeeksPerYear`	No	Weeks worked per year. Default 48.
`annualBusinessExpenses`	No	Yearly business costs. Default 0.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It mentions accounting for non-billable time, vacation, taxes, and expenses, but does not disclose default values or output format. Adequate but not fully transparent.

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

Conciseness5/5

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

The description is two sentences long, front-loaded with the core purpose, and appends a useful warning. No wasted words.

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?

No output schema is provided, and the description does not specify the return value (presumably hourly rate) or any additional info like defaults. Given 6 parameters and no output description, completeness is adequate but missing key details.

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% with good descriptions in the schema itself. The description adds marginal value by referencing concepts like target income and non-billable time, but does not significantly enhance parameter understanding 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?

The description clearly states the tool calculates hourly rate for freelancers to achieve target income, accounting for non-billable time, vacation, taxes, and expenses. It distinguishes itself from siblings which cover budgeting, growth, debt, etc.

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 gives clear context: for freelancers/consultants transitioning from salary, and warns against using salary/2080. It does not explicitly state when not to use or name alternatives, but context is sufficient.

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

loan_amortizationLoan / Mortgage AmortizationA

Build a full amortization schedule for a loan or mortgage. Supports recurring extra principal payments and reports the interest those extra payments save plus the new payoff date. Use this for mortgages, auto loans, or any fixed-rate installment loan.

ParametersJSON Schema

Name	Required	Description
`years`	Yes	Loan term in years.
`amount`	Yes	Loan principal.
`extraPayment`	No	Extra principal paid each period to accelerate payoff. Default 0.
`annualRatePct`	Yes	Annual interest rate, in percent.
`periodsPerYear`	No	Payments per year. Default 12 (monthly).

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, but the description transparently explains the tool's function (build schedule, accept extra payments, report interest savings and payoff date). Missing details on side effects or read-only nature, but these are implicitly understood for a calculation tool.

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

Conciseness5/5

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

Two sentences, no filler, front-loaded with main purpose. Every sentence adds value.

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?

For a complex tool with 5 parameters and no output schema, the description adequately explains purpose and key outputs. However, it could mention the return format to complete the picture.

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. The description adds value beyond schema by mentioning 'recurring extra principal payments' and 'reports the interest those extra payments save plus the new payoff date', which contextualizes the extraPayment parameter and output behavior.

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 clearly states the tool builds a full amortization schedule for loans, specifies support for extra principal payments and reporting of savings, and distinguishes from siblings by mentioning fixed-rate installment loans.

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?

Explicitly states use cases (mortgages, auto loans, fixed-rate loans), but lacks explicit when-not-to-use or alternative suggestions, which would further clarify against sibling tools like debt_payoff.

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

price_optimizerProfit-Maximizing Price OptimizerA

Find the price that maximizes profit for a product or service. Fits a linear demand curve to your observed price/quantity points, derives the optimal price from unit economics, and returns a transparent price sweep. Also reports the revenue-maximizing price for growth strategies.

ParametersJSON Schema

Name	Required	Description
`unitCost`	Yes	Variable cost to produce/deliver one unit.
`fixedCost`	No	Fixed costs for the period. Default 0.
`demandPoints`	Yes	At least two price/quantity observations (must slope downward).

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It mentions fitting a linear demand curve, deriving optimal price from unit economics, and returning a transparent price sweep. However, it does not disclose computational assumptions, limitations (e.g., linearity), or potential side effects. Adequate but not comprehensive.

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

Conciseness5/5

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

The description is three sentences long, front-loaded with the main purpose, and contains no extraneous information. Every sentence adds value, making it concise and well-structured.

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 no output schema, the description mentions 'returns a transparent price sweep' and reports both profit- and revenue-maximizing prices. However, it lacks explicit details on the output format or structure, which would improve completeness. Mostly sufficient but with a minor gap.

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% as all parameter descriptions are provided in the schema. The description adds context like 'observed price/quantity points' and 'unit economics', but does not significantly extend beyond the schema's own descriptions. Baseline score of 3 is appropriate.

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 clearly states the tool finds the price that maximizes profit, fitting a linear demand curve. It specifies the resource (product/service) and verb (find/optimize). However, it could be more specific about the return format to fully distinguish from similar tools.

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

Usage Guidelines3/5

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

The description implies usage for profit maximization and revenue maximization, but does not explicitly state when NOT to use the tool or provide comparisons to sibling tools like 'freelance_rate' or 'roi_compare'. Guidelines are implied but not explicit.

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

roi_compareInvestment / Opportunity Comparison (ROI, NPV, IRR)A

Compare multiple investments or business opportunities on the metrics that matter: ROI, payback period, NPV, and IRR. Each opportunity is a series of cash flows (period 0 is usually the negative initial outlay). Tells you which option creates the most value.

ParametersJSON Schema

Name	Required	Description	Default
`investments`	Yes	The opportunities to compare.
`discountRatePct`	No	Annual discount rate / hurdle rate, in percent. Default 10.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It explains that each opportunity is a cash flow series and that period 0 is typically negative. However, it does not disclose edge cases, error handling, or the exact output format (only says 'tells you which option creates the most value').

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

Conciseness5/5

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

The description is two sentences with no fluff. It front-loads the core purpose and immediately follows with essential context about cash flows.

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?

Given the tool has no output schema and no annotations, the description is somewhat incomplete. It does not specify the return format (e.g., a sorted list or comparison table), which would help an agent understand how to use the result.

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%, so the schema already documents both parameters adequately. The description adds context about ROI, NPV, etc., but that relates more to purpose than parameter details. Baseline 3 is appropriate.

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 title and description clearly state the tool compares multiple investments on ROI, NPV, IRR, and payback period. The verb 'compare' and resource 'investments' are specific, and the tool is distinct from siblings that focus on single analyses (e.g., compound_growth).

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

Usage Guidelines3/5

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

The description implies the tool is for comparing multiple cash flow streams to find the best value, but it does not explicitly state when not to use it or provide alternatives among siblings.

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

side_hustle_rankerSide-Hustle / Income-Stream RankerA

Rank side-hustle ideas by risk-adjusted effective hourly value, accounting for startup cost, ramp time, ongoing costs, hours, and probability of success. Turns 'which side hustle should I start?' into a numbers-driven decision.

ParametersJSON Schema

Name	Required	Description	Default
`hustles`	Yes	The income-stream ideas to compare.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It lists key factors accounted for (startup cost, ramp time, etc.), which sets expectations. However, it omits output details (e.g., whether it returns a ranked list or scores) and does not mention any limitations or safety considerations, leaving some transparency gaps.

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

Conciseness5/5

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

Two sentences, front-loaded with purpose, no wasted words. The structure clearly states what the tool does and the value it provides.

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?

The description explains input factors well but lacks information about the output format (ranked list vs. scores) and any constraints (e.g., maximum number of hustles). Given no output schema, this omission reduces completeness.

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 description adds little new per-parameter information beyond what is already in the schema. It provides context on how parameters are combined into the risk-adjusted value, but does not elaborate on parameter usage beyond the schema descriptions.

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 clearly states it ranks side-hustle ideas by risk-adjusted effective hourly value, considering specific factors like startup cost, ramp time, etc. It distinguishes itself from sibling financial tools by focusing on side-hustle comparison, using a concrete verb and resource.

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 explicitly frames the tool as a numbers-driven decision maker for 'which side hustle should I start?', clearly indicating its use case. However, it does not provide exclusions or mention when to use alternatives like budget_analyzer or freelance_rate, leaving some ambiguity.

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

subscription_auditSubscription Audit & Savings FinderA

Audit recurring subscriptions: annualize every line, compute cost-per-use, and flag low-value or rarely used services as candidates to cut — quantifying exactly how much money you can recover per year.

ParametersJSON Schema

Name	Required	Description	Default
`subscriptions`	Yes	Your subscriptions.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided; the description carries full burden. It explains the analysis performed but does not disclose side effects, auth needs, or that the tool is read-only. Adequate but not thorough.

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

Conciseness5/5

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

Single sentence front-loads the purpose and lists key actions without waste. Every phrase earns its place.

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 no output schema, the description adequately conveys the return value (quantified savings) and the overall process. Could benefit from mentioning output format or prerequisites, but sufficient for an analysis tool.

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%, baseline 3. The description adds value by explaining how parameters are used in computations (annualization, cost-per-use, low-value flags), providing meaningful context beyond field names.

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 uses a specific verb 'Audit' and resource 'recurring subscriptions', detailing actions: annualize, compute cost-per-use, flag low-value, quantify savings. It clearly distinguishes from sibling tools like budget_analyzer or debt_payoff.

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

Usage Guidelines3/5

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

The description implies usage for auditing subscriptions to find savings, but does not explicitly state when to use this over alternatives or give exclusions. Lacks comparative guidance,

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

tax_estimateProgressive Income Tax EstimatorA

Estimate income tax under a progressive bracket schedule. Defaults to US 2024 single-filer federal brackets but accepts any custom brackets (any country/year). Reports total tax, after-tax income, the per-bracket breakdown, and your effective vs marginal rate.

ParametersJSON Schema

Name	Required	Description
`income`	Yes	Gross annual income.
`brackets`	No	Custom progressive brackets (low to high). Omit to use US 2024 single-filer defaults.
`deduction`	No	Amount subtracted before brackets apply. Default 0.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description bears full burden. It discloses default behavior (US 2024 single-filer) and customizability, plus outputs (total tax, after-tax income, breakdown, rates). It does not mention side effects or requirements, but as a calculator, this is adequate.

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

Conciseness5/5

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

Three well-structured sentences with no redundancy. Purpose is front-loaded, and every sentence adds essential information. Highly concise.

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?

For a simple calculator with 3 parameters and no output schema, the description explains inputs (including defaults and custom brackets) and outputs (total tax, breakdown, rates). It is complete and self-contained.

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. The description adds value by explaining default bracket usage and customizability, and it notes the deduction parameter (though not by name). It provides context 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?

The description clearly states it estimates income tax under a progressive bracket schedule, specifying default US brackets and customizability. It is distinct from sibling financial tools like budget_analyzer or loan_amortization.

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

Usage Guidelines3/5

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

The description implies use for tax estimation but does not explicitly state when to use versus alternatives or provide exclusions. It lacks explicit guidance on when to choose this tool over others.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv1.0.0Jul 8, 2026
- First observedbudget_analyzer
- First observedcompound_growth
- First observeddebt_payoff
- First observedfire_calculator
- First observedfreelance_rate
- First observedloan_amortization
- First observedprice_optimizer
- First observedroi_compare
- First observedside_hustle_ranker
- First observedsubscription_audit
- First observedtax_estimate

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct personal finance task: budgeting, growth projection, debt payoff, FIRE, freelancing, loans, pricing, investment comparison, side hustles, subscriptions, and taxes. Descriptions clearly differentiate them, and no two tools have overlapping purposes.

Naming Consistency4/5

All tool names follow snake_case and a predominantly noun_verb pattern (e.g., compound_growth, debt_payoff). The minor exception is budget_analyzer (noun_verb) instead of budget_analyze, but the pattern is still clear and consistent overall.

Tool Count5/5

With 11 tools, the count feels perfectly scoped for a personal finance assistant. Each tool covers a distinct aspect without overwhelming the user or agent, making the set manageable and focused.

Completeness4/5

The toolset covers budgeting, investing, debt, loans, taxes, and FIRE comprehensively. Minor gaps exist, such as no general retirement planning beyond FIRE or expense tracking, but the core workflows are well-covered.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SmartMoney77 A
com.smartmoney77
SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp
Finance
141
Math MCP Learning A
io.github.clouatre-labs
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Education & Learning Tools Research & Data Developer Tools
1725
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
Pinchwork MCP Server
io.github.pinchwork
MCP server for Pinchwork - an agent-to-agent task marketplace with credits-based economy
Agent Orchestration Autonomous Agents Finance
23

Related MCP Servers

Personal Finance AI MCP
Finance AI & Machine Learning
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Personal Finance AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 2 months ago (2026-06-26 05:40 UTC)
15
MIT
finance-calc-mcp
Finance
FellowTraveler
A
license
A
quality
D
maintenance
An MCP server and CLI providing business, financial, and tax calculations including math expressions, income tax estimates, loan amortization, depreciation, and more.
Updated 6 months ago (2026-03-16 17:45 UTC)
10
2
MIT
fintools-mcp
Finance
VaruTudor
F
license
Not graded
quality
B
maintenance
Personal finance calculators exposed as an MCP server with a Gradio UI, deployable to Hugging Face Spaces.
Updated 2 months ago (2026-07-06 17:18 UTC)
-
finance-mcp-server
Finance Databases
Marcusdt-UX
A
license
A
quality
B
maintenance
A personal finance tracker MCP server that imports Rocket Money data or connects banks via SimpleFIN to a local SQLite database, enabling Claude to analyze spending, subscriptions, cash flow, and debt payoff with complete privacy.
Updated a month ago (2026-07-29 17:38 UTC)
15
47
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jaume9/wealth-engine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server