Skip to main content
Glama

Get runway

well_get_runway
Read-only

Get the workspace's current cash runway — cash on hand, trailing-3-month average burn, and months of cash left — the exact same computation and numbers the Well app's canvas KPI cards show. Use this instead of computing runway yourself from raw account/transaction reads.

Returns cash (amount + currency), avg_burn (amount + currency + trailing_months), months, and a status discriminator:

  • "ok" — a finite months figure.

  • "capped" — runway exceeds 36 months; report as ">36 months", not the raw number.

  • "infinite" — cash is positive and the workspace isn't burning (net inflow); there is no meaningful "months" figure.

  • "insufficient_data" — not enough connected cash/transaction data to compute; tell the user to connect a bank/accounting connector (well_list_connectors) instead of guessing.

change is a percentage against baseline. A baseline runway divides a month-end cash reading by a trailing burn window, so it takes two dates to describe: baseline.period is the cash month-end it was anchored at, and baseline.burn_window is the span of the burn it divided by, which normally ends an earlier month. Never present the baseline as the runway measured on one day. trend is whether the change is GOOD, not which way the number moved; trend_polarity is higher_is_better for runway, so "up" means the runway grew. Read the sign of change for direction.

partial: true means some accounts or transactions were excluded from the computation (e.g. missing FX rate) — mention the exclusion counts and any hints if present rather than presenting the number as unconditionally complete.

Pass year + month to read a past reporting period instead of the live figure. There is no burn-window option here on purpose: the runway figure composes the endpoint's own trailing burn, so a custom window would pair months from one window with avg_burn from another and the cash ÷ burn division could not reproduce the headline. Call well_get_burn for a different window.

For the month-by-month cash series, call well_get_cash_forecast. Its forward half is a WORST CASE: it assumes the trailing burn continues and no revenue arrives at all. Never describe it as expected, forecast or likely cash, and never quote a month from it as what the balance will be — say what it is, the floor if nothing changes. A month in the settled half is a measured balance and may be stated plainly.

When the token authorizes one workspace, call this directly — no other tool call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoCalendar year of the reporting period, e.g. 2026. Must be given together with `month`.
monthNoCalendar month of the reporting period, 1 = January … 12 = December. Must be given together with `year`. Omit both to read the live/current figure.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cashNo
as_ofNo
errorNo
hintsNo
trendNoWhether the change is GOOD for this KPI, not the direction the number moved. Runway is higher-is-better, so "up" means the runway grew. Read the sign of `change` for direction.
changeNoSigned percentage change of `months` against `baseline.value`.
monthsYes
statusYes
partialNo
successYes
avg_burnNo
baselineNoWhat `change` was measured against. It arrives with `change`, `trend` and `trend_polarity` as one group; when the baseline has no named period all four are withheld rather than sending a percentage with no referent.
excludedNo
connectors_urlNo
trend_polarityNoWhich direction counts as good. Runway is higher-is-better, so a longer runway reads as `trend: "up"`.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.

TDQS

A4.6/5.0
Behavior5/5

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

The annotations only provide readOnlyHint and destructiveHint, so the description carries the full behavioral burden and exceeds it: it defines each status discriminator, explains partial-computation semantics, clarifies baseline/trend polarity, and warns that the forecast sibling's forward half is worst-case. It also discloses the design decision not to offer a burn-window option and why, which goes well beyond the annotations.

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 long but front-loaded with purpose, return semantics, and statuses before moving to edge cases and sibling routing. It repeats a couple of schema-level workspace/year-month rules and could be tightened, but the density is largely justified by the number of statuses and interpretation hazards.

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?

The output schema and annotations cover types and safety, while the description fills in all the interpretation and workflow context: status meanings, capped/infinite/insufficient-data handling, partial exclusion hints, baseline/treend semantics, auth behavior, and sibling routing. For a tool with this many edge cases, nothing an agent needs to call it correctly is missing.

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%, and the schema already documents the year/month pairing, the omit-both-for-live rule, and the workspace_id authorization behavior. The description largely restates those rules rather than adding new per-parameter meaning, so the high-coverage baseline of 3 applies; the extra rationale about the absent burn-window option is not parameter semantics.

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 first sentence names a specific read operation (get workspace cash runway), enumerates the exact metrics returned (cash on hand, trailing-3-month burn, months of cash left), and anchors it to the Well app's KPI cards. It also explicitly contrasts this with computing from raw account/transaction reads and later names the sibling tools it should not be confused with.

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?

The description gives explicit when-to-use guidance: use this instead of computing runway yourself, and call it directly when the token authorizes one workspace. It names alternatives with conditions — well_get_burn for a different burn window and well_get_cash_forecast for the monthly series — and explains why a burn-window parameter is intentionally absent here.

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.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: CRUD for companies, people, and invoices; financial analytics (cash, cost, runway, holdings); connector management and invocation; schema discovery; querying; reconciliation; and contact channel management. No two tools could be confused for the same action.

Naming Consistency5/5

All tools follow the `well_verb_noun` pattern with consistent verb choices (create, get, list, update, delete, add, remove, run, resolve, query, invoke). The naming is predictable and makes the tool's purpose immediately clear.

Tool Count4/5

With 26 tools, the set is slightly above the ideal 3-15 range, but every tool earns its place given the breadth of the domain (CRM, invoicing, financial analytics, reconciliation, connector management). The count is well-scoped and not excessive.

Completeness4/5

The tool surface covers core CRUD, financial KPIs, reconciliation, and connector management. Minor gaps exist (e.g., no direct tool to update contact channels or manage accounts), but the query and schema tools allow agents to work around them, and the primary workflows are fully supported.

Resources