Skip to main content
Glama

Senaro Personal Finance

Cash Runway Calculator

calculate_runway
Read-onlyIdempotent

Calculation, not advice. Verify with a professional before acting. Deterministic cash-runway calculator. Given your liquid savings, monthly essential expenses, optional ongoing inflows (partner income, side income, severance paid as a monthly stream, unemployment benefits), and an optional expense-inflation rate, computes how many months the fund lasts before it hits zero, plus a month-by-month drawdown schedule. Single scenario per call: to compare 'status quo' vs 'cutbacks' vs 'cutbacks + unemployment', call once per scenario with the matching expenses and inflows. When inflows meet or exceed expenses (and expenses are not inflating), the fund does not draw down and a self-describing does-not-deplete outcome is returned instead of a month. Yield on the fund is treated as 0% in v1 (conservative). All assumptions cite their source. HEAVY tool: use output='summary' (default) for the headline or output='inline' for the full schedule. output='capture' writes the full payload to a file on this server's local disk for the chart-render pipeline; available on the local stdio transport only, and rejected with a structured error on the hosted HTTP transport.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolArgumentsYesJSON object with parameters: REQUIRED: current_savings: decimal >= 0. Liquid fund available to draw down. 0 is valid (already-empty fund). monthly_essential_expenses: decimal > 0. Monthly outflow at the chosen expense basis. OPTIONAL: monthly_inflows: decimal >= 0 (default 0). Ongoing monthly income that continues during the drawdown (partner income, side income, unemployment benefit, severance paid monthly). Modeled as a flat monthly stream; a one-time severance lump and time-limited benefits are not modeled in v1. annual_inflation_rate_pct: decimal [0, 100) (default 0). When > 0, expenses grow each month by the monthly-equivalent of this annual rate. When 0, expenses are constant. use_essential_expenses: bool (default true). true = essential-only basis (survival runway); false = total-spend basis (current-pace runway). Labels the reported expense_basis. chart_title: string (optional). Reserved for the chart pipeline. Must not contain em-dashes or en-dashes. Max 120 characters. ENVELOPE: output: 'summary' (default) | 'inline' | 'capture' summary: headline scalars (depletion month / does-not-deplete) + citations; the schedule is stripped. inline: full payload including the month-by-month schedule[] (for chart rendering). capture: full payload written to ~/.senaro/captures/; capture_ref URI returned. Available on the local stdio transport only; the hosted HTTP transport rejects 'capture' with a structured error naming 'summary' and 'inline' as the valid alternatives.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on substantial extra behavior: 0% yield assumption in v1, the does-not-deplete outcome when inflows cover expenses, the HEAVY classification with output sizing options, and the stdio-only 'capture' restriction with a structured error on HTTP. This is well beyond what annotations convey.

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?

Front-loads the disclaimer and the core purpose, and every sentence carries information (scenario modeling, yield assumption, output modes, transport gating). It is dense rather than bloated, though the transport and capture details make it longer than strictly necessary for the headline call.

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?

No output schema exists, so the description carries the return-value burden and does so adequately (depletion month or self-describing does-not-deplete outcome, month-by-month schedule with inline, capture_ref URI with capture). Combined with the rich schema it covers everything an agent needs to invoke correctly.

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 description coverage is 100%, so the parameter baseline is 3, but the description adds real meaning beyond the schema: the single-scenario-per-call constraint, the semantics of comparing status-quo vs cutbacks, the yield convention, and the transport-dependent behavior of output='capture'.

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?

States a specific verb+resource ('Deterministic cash-runway calculator') and precisely scopes the inputs (liquid savings, essential expenses, inflows, inflation) and output (months until fund hits zero plus a drawdown schedule). This clearly distinguishes it from sibling tools like calculate_emergency_fund or calculate_cc_payoff.

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 tells the agent how to run comparisons ('call once per scenario with the matching expenses and inflows') and when to pick each output mode. It does not name sibling alternatives, so it stops short of full when/when-not/alternatives routing.

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