Skip to main content
Glama

Get cash position forecast

well_get_cash_forecast
Read-only

Get the workspace's cash-position forecast — trailing actual month-end balances plus a worst-case projection forward — the exact same series the Well app's "Cash Position Forecast" chart draws. Use this instead of projecting cash forward yourself from a cash figure and a burn rate.

Returns entries, one per month, oldest first, each { month, actuals, projection } where month is YYYY-MM:

  • actuals is the settled cash position at that month's end, and is null for future months.

  • projection is the worst-case value at that month's end, and is null for past months.

So the series has exactly one turn: actuals up to the present, projection after it. Do not fill the nulls in or treat a null as a zero.

anchor names what the projection counts forward from: { month, amount, basis }, where the first projection point is amount minus one month of trailing burn. Name the anchor whenever you present that point — without it a reader cannot tell a projection falling from a base that is weeks old from cash that is actually dropping, and the two produce the same number. anchor is absent when nothing is projected.

Read basis before describing the anchor, because the two values are different readings and only one is a month-end:

  • closed_month_endamount is the settled balance at the end of month. When month is not the month just gone, say so: the projection for a month already under way was computed without anything that happened in it.

  • current_positionamount is today's consolidated cash, which DOES include the month under way. Here month is only where the projection starts on the chart's grid, not the date the amount was read, so do not present it as a closing balance.

The projection is explicitly WORST CASE — it assumes NO revenue and declines at the trailing average burn until it reaches zero, where it stays clamped. Say so whenever you present it. It is a floor, not a forecast of what will happen, and a workspace that expects income will not follow it.

Takes no period. A worst-case projection has no coherent meaning for a month whose real outcome is already known, so this always returns the live forecast — unlike well_get_cash_position and well_get_cost_structure, which do accept year/month.

If hints are present (a short actuals window, excluded accounts, or a burn-coverage gap), disclose them rather than presenting the series as unconditionally complete.

This tool renders its own chart card in the host. Do not re-plot the series with a charting or visualisation tool — that draws a second, unbranded copy of a chart the reader is already looking at, from the same numbers. Read the series to answer in words; leave the drawing to the card.

For the single months-of-cash-left figure call well_get_runway; for the burn rate driving the decline call well_get_burn.

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
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
errorNo
hintsNo
anchorNo
entriesYes
successYes
currencyNo
connectors_urlNo
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint and destructiveHint, so the description carries the behavioral burden and excels. It discloses null-handling rules ('Do not fill the nulls in or treat a null as a zero'), the exact actuals/projection turn, the worst-case assumption with clamping, the anchor/basis interpretation pitfalls, the self-rendering chart card, and the 'do not re-plot' rule. These are meaningful behaviors beyond any annotation.

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 long, but every section earns its place given the nuanced output semantics. It is front-loaded with the core purpose and the most important behavioral constraint, then uses bullet lists and bolded cues to keep the dense details scannable. There is no fluff or tautology.

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 read tool with a rich output contract, the description covers return shape, null semantics, anchor/basis meanings, worst-case assumptions, hints handling, chart-card behavior, sibling routing, and workspace ambiguity — all without needing to reproduce the output schema. It is complete enough for an agent to select and invoke the tool correctly.

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?

The input schema already fully documents workspace_id, including when to omit it and when it is required, so schema coverage is 100%. The description repeats this guidance but does not add new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate because the schema carries the parameter documentation burden completely.

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 opens with a specific verb and resource: 'Get the workspace's cash-position forecast' and immediately scopes it as 'trailing actual month-end balances plus a worst-case projection forward.' It also names the exact chart series it mirrors, which distinguishes it from other cash-related tools, and later contrasts itself with well_get_cash_position and well_get_cost_structure on the period parameter.

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 an explicit alternative to manual projection ('Use this instead of projecting cash forward yourself'), clarifies when not to use it ('Takes no period'), and routes to siblings for related but different needs: 'For the single months-of-cash-left figure call well_get_runway; for the burn rate driving the decline call well_get_burn.' It also gives concrete caller guidance for workspace authorization, including when to pass workspace_id.

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