Skip to main content
Glama

get_fire

Calculates the years to financial independence (4% rule) from expenses, savings, return and age.

Input Schema

NameRequiredDescriptionDefault
inflationNoAnnual inflation in % (default 3)
currentAgeNoCurrent age (default 30)
annualReturnNoExpected annual return in % (default 7)
monthlyExpensesYesMonthly expenses
currentPortfolioNoCurrent net worth (default 0)
monthlyInvestmentYesMonthly savings/investment

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/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 full burden. It does disclose meaningful methodology ('4% rule') and that the calculation is driven by expenses, savings, return and age, implying a pure read-only computation, but it never states that it has no side effects, that it is stateless, or how assumptions like inflation interact with the 4% rule.

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?

A single front-loaded sentence with no filler; the outcome ('years to financial independence') and the method ('4% rule') come first. It is slightly loose in implying a fixed 4% withdrawal rule while exposing an adjustable annualReturn parameter, but it wastes no 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?

For a six-parameter calculator with full schema coverage but no output schema, the description should say what is returned (a year count? a projection series?) and clarify how inflation and current portfolio feed the result. It covers the inputs adequately but leaves the output shape unspecified.

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%, with defaults, ranges and units (percent, monthly) already documented per parameter. The description restates the input categories but adds no format, unit, or interaction detail beyond the schema, so the baseline of 3 applies.

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?

States a precise verb ('Calculates') and a precise resource ('years to financial independence'), and names the methodology (4% rule) plus the input basis. It is clearly distinguishable from the market/portfolio siblings such as get_portfolio or get_metrics, though it does not explicitly contrast itself with a sibling.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. A user with a portfolio could plausibly reach for get_portfolio_score or get_metrics instead, but the description gives no criteria, prerequisites, or exclusions to disambiguate.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources