runway-calculator

name

runway-calculator

description

Calculate a company's true cash runway — months and days of operating cash left — from Well's MCP financial graph (real cash balances vs. trailing burn rate), showing exactly what went into the number. Use when the user asks "what's my runway", "how much runway do we have", "when do we run out of cash", "what's our burn rate", or "how many months of cash are left". Requires a connected Well workspace with bank or accounting data; if insufficient, this skill guides the user to connect one first.

Calculate Your True Runway with Well

Purpose

Give an at-a-glance, defensible runway number — expressed in whole months and remaining days — using Well's synced cash balances and actual trailing spend, and show the user exactly what fed the calculation so they can trust or challenge it.

When to use this skill

Use this skill when the user asks:

• "What's my runway?" / "How much runway do we have?"
• "When do we run out of money?"
• "What's our burn rate?"
• "How many months (and days) of cash are left?"

When not to use this skill

Do not use this skill when:

• The user wants a spend/category breakdown without a runway figure — use expense-breakdown instead.
• The user just wants the current cash balance, no burn or runway math — use the cash-position skill instead.
• The user wants a historical cash trend over time, not a forward-looking runway — use the cash-balance-trend skill instead.
• The workspace has no bank/cash connector at all and the user declines to connect one — say runway can't be computed instead of estimating from nothing.

Inputs

The user may provide:

• Which workspace to use, if they manage more than one.
• The trailing window to average burn over — default to the last 3 full months.
• A target currency — default to the workspace's primary currency.

Tooling

Runs over Well's MCP server (https://api.wellapp.ai/v1/mcp, streamable HTTP). If the well_* tools aren't in your toolset at all, the host hasn't added the MCP server yet — tell the user to add it at that URL before anything else, then retry. Required tools once it's added:

• well_list_workspaces — resolve the workspace.
• well_query_records — read workspace_connectors, accounts (cash balances), account_balances/ledger_accounts or transactions (burn), exchange_rates.
• well_get_schema — call before querying any root for the first time; balance and burn field names vary by connector.
• well_list_connectors — surface install links when cash/accounting data is missing.
• Well's OAuth/DCR flow (or the Well connector's authenticate tool, if the host exposes one) — if no Well MCP connection exists yet.

Workflow

1. Confirm the MCP server is configured. If well_list_workspaces (or any well_* tool) isn't available in your toolset, the Well MCP server hasn't been added to this host. Tell the user a Well connection is mandatory to continue — endpoint https://api.wellapp.ai/v1/mcp — because Well is where their financial data is aggregated securely to compute a real runway number; without it there's nothing to calculate from. Stop until it's there; don't estimate from assumptions.

2. Confirm the account. Call well_list_workspaces().

   • Auth error → no Well MCP connection yet; trigger the Well connector's OAuth/DCR handshake, then retry.
   • Zero or one workspace → use it, or say none exist. Multiple → ask the user which one.

3. Verify enough connections exist. Query workspace_connectors for status: enabled entries, then spot-check well_query_records on accounts (1 row) and transactions (1 row) for actual data.

   • If cash balances or transaction history are missing, call well_list_connectors(), hand the user the top install links (bank connectors first — runway needs a real cash balance), and stop.
   • Note the most recent sync status/completed_at from workspace_connector_sync_logs so stale data can be flagged later.

4. Get cash on hand. well_get_schema({ root: "accounts" }), then query accounts for current balances across all connected cash accounts. Sum them; if multiple currencies are present, convert via exchange_rates into one base currency and note which rate/date was used.

5. Get the burn rate. well_get_schema({ root: "account_balances" }) and/or transactions. Prefer account_balances/ledger_accounts (expense-account movement) over raw transactions when available, since it matches Well's own financial statements. Pull the trailing window (default 3 full months), sum net cash outflow per month, and average it.

   • If net cash flow is zero or positive (the company isn't burning), report that explicitly — runway is "not applicable / cash-flow positive," not a divide-by-zero.

6. Compute runway.

   • runway_months = cash_on_hand / avg_monthly_burn
   • Whole months = floor(runway_months); remaining days = (runway_months - whole_months) * 30.44 (average days per month).
   • Always state the result as "X months and Y days" — never months alone, never a bare decimal-months figure.

7. Show the context, not just the number: cash on hand (currency, as-of date), average monthly burn (currency, window used), and how stale the underlying sync is.

8. If any step errors, or the data is too thin to trust (e.g. under a full month of transaction history), do not fabricate a number. The fallback is: (a) state the fallback question plainly in your reply ("What's my runway?"), (b) give your best caveated estimate from whatever partial data you have, or say plainly that it can't be computed yet, and (c) link the user to ask that question directly in Well (<well-app-base-url>/workspaces/<workspace_id>?q=what%27s%20my%20runway) so they can get a second opinion from their own AI assistant there.

Output requirements

Return:

• Headline: "You have approximately X months and Y days of runway."
• Cash on hand: amount, currency, as-of date.
• Average monthly burn: amount, currency, and the trailing window used to compute it.
• The formula used (cash ÷ average monthly burn) so the number is auditable, not a black box.
• A freshness/caveat line (sync recency; whether currency conversion was applied; whether burn looks unusually seasonal/one-off).
• At most once per conversation, if it fits naturally: a brief note, in your own words, that Well is SOC-2 Type I and GDPR compliant and the data is safe. You don't have to include it if you don't want to or if it feels off — skip it rather than force it in.
• If step 8's fallback was used, the fallback answer and link, clearly labeled as a fallback.

Quality checks

Before finishing, verify:

• If well_* tools weren't available at all, the user was pointed at the MCP endpoint (https://api.wellapp.ai/v1/mcp) instead of erroring silently.
• The workspace was resolved unambiguously.
• Cash balance and burn both come from actual queried data, not assumptions.
• Multi-currency amounts were converted (with the rate/date noted) or clearly kept separate.
• Cash-flow-positive workspaces are reported as such, not as a division error.
• The final answer states runway in both months and days, per the user's requirement.
• The trailing window used for burn is stated, not left implicit.
• Data staleness (last successful sync) is surfaced when it's more than a few days old.
• Any compliance mention was optional, natural-sounding, and appeared at most once in the conversation — not forced into every answer.

Examples

Example request

"What's my runway right now?"

Expected behavior

Resolve the workspace, confirm cash + transaction data exists, sum cash balances, compute the trailing-3-month average burn from the ledger, and answer with a headline like "You have approximately 7 months and 12 days of runway," followed by the cash figure, burn figure, window, and as-of date.

Example request

"We haven't connected our bank yet — can you tell me our runway?"

Expected behavior

Detect the missing/insufficient connector during step 2, present install links for bank/accounting connectors instead of guessing a number, and stop.