Skip to main content
Glama

Get cash flow bridge

well_get_cash_flow_bridge
Read-only

Get the workspace's cash-flow bridge — how the opening cash position became the closing one — the exact same steps the Well app's cash-flow waterfall chart shows. Use this instead of deriving flows from raw transaction reads.

Returns steps in render order, each { label, value, kind }. kind says how to read value:

  • "start" and "total" carry an ABSOLUTE cash position (the opening and closing anchors).

  • "increase" and "decrease" carry a gross flow MAGNITUDE, always positive. The direction lives in kind, not in the sign — never report a "decrease" as a negative number or add the magnitudes as though they were signed.

  • "unexplained" carries a SIGNED adjustment and is the one kind whose sign you must keep. It appears only when the four measured bars do not reconcile: it is the gap between them and the measured closing position, NOT cash that moved. Report it as an unexplained difference and say the bridge does not fully reconcile. Never fold it into the inflow or outflow figure, and never present it as spending, income, or a transfer.

Walk the steps to reach the total: opening, plus every "increase", minus every "decrease", plus any "unexplained". When an "unexplained" step is present that sum equals the "total" exactly. When none is present the bridge reconciled to within a small tolerance — say it reconciles, not that it is exact to the cent. A bridge can also omit the step because an anchor could not be measured at all; the hints say so when that happens, so read them before claiming either.

This is a SELF-CONTAINED reconciliation: the "start" and "total" steps ARE the opening and closing balances for the period, so do not also call well_get_cash_position to fetch them. That tool answers a different question — the balance right now — and pairing it with this one reports today's figure beside last period's bridge as though they were the same reading.

An EMPTY steps array means neither anchor could be measured (nothing connected, or the reads timed out). That is missing data, NOT a month with no movement — say the bridge is unavailable rather than reporting flat cash.

period_start and period_end are the inclusive YYYY-MM-DD bounds these bars cover — a trailing multi-month window, not a single month. Read the period from those fields and state it whenever you present the numbers. Never derive it from today's date, and never assume one month. If both fields are absent, say the period is unknown rather than naming one.

Pass year + month to bridge a past period instead of the live window. Read the window you actually got from period_start/period_end either way.

This is not a decomposition of well_get_cost_structure: this reconciles opening to closing cash across inflow and outflow, while cost structure splits a single month's outflow by category. They will not tie out, and presenting one as the breakdown of the other is wrong.

If hints are present (excluded accounts, an FX gap, or an unexplained residual between the anchors and the flows), disclose them rather than presenting the bridge as balanced.

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
errorNo
hintsNo
stepsYes
successYes
currencyNo
period_endNoInclusive YYYY-MM-DD end of that window.
unavailableNo
period_startNoInclusive YYYY-MM-DD start of the window the flow bars cover (a trailing multi-month span).
connectors_urlNo
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, yet the description adds substantial behavioral context beyond them: sign conventions for 'increase'/'decrease' kinds (never report a decrease as negative), the special status of 'unexplained' as a non-cash gap, tolerance-based reconciliation wording, empty-steps meaning missing data rather than flat cash, the trailing multi-month period semantics, and the requirement to disclose hints. It also states the tool is a self-contained reconciliation and will not guess a workspace when several are authorized. No contradiction with annotations — 'this read' wording is consistent with readOnlyHint=true.

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 sentence earns its place by preempting a distinct agent error: misreporting sign, folding 'unexplained' into flows, claiming flat cash on empty data, deriving the period from today's date, pairing with cash position, or tying out to cost structure. It is front-loaded with the core purpose, then proceeds logically through return semantics, reconciliation math, edge cases, parameter usage, sibling distinctions, and auth. Density is justified by the tool's semantic complexity.

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?

Despite an output schema existing, the description explains the steps array semantics, period fields, hints, empty-array behavior, reconciliation edge cases, multi-workspace auth, and sibling tool contrasts. It covers every call-relevant scenario an agent could encounter: absent period fields, missing anchors, timing-out reads, and authorization scope. Nothing needed to invoke the tool correctly is missing.

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 coverage is 100% and the schema descriptions already document year/month pairing and workspace_id conditions. The description adds genuine value on top: year+month select a past period rather than the live window, the returned period_start/period_end must be read from the response rather than assumed to match the request, and workspace_id is a disambiguation for multi-workspace tokens rather than a general selector. That is real semantic enrichment beyond the schema, though the schema does the heavy lifting.

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 opening sentence states a specific verb (get), resource (cash-flow bridge), and the core transformation (how opening cash became closing). It names the exact same steps as the Well app's waterfall chart, anchoring what the tool returns. Sibling differentiation is built in: the description explicitly contrasts this with well_get_cash_position and well_get_cost_structure, so an agent can select it without opening any schema.

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?

Usage guidance is explicit and exhaustive: 'Use this instead of deriving flows from raw transaction reads'; 'do not also call well_get_cash_position' because it answers a different question; 'this is not a decomposition of well_get_cost_structure' and they will not tie out. It also gives precise conditions for passing year/month (bridge a past period vs. live window) and for workspace_id (omit when token authorizes one workspace, pass when several). Nothing is left to inference.

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