Skip to main content
Glama

Get cash position

well_get_cash_position
Read-only

Get the workspace's current cash position: total cash on hand right now, converted to the workspace base currency, plus a per-account breakdown — the exact same computation and numbers the Well app's canvas KPI card shows. Use this instead of summing account balances yourself.

Returns amount/currency (the converted total), accounts (per-account contributions: native amount/currency, converted amount, the FX rate applied), as_of (the FX-rate anchor date this snapshot is valid for), and balance_history when the workspace has one.

balance_history is the trailing closed month-ends plus today, oldest first. Month-end is the only historical granularity that exists, so describe movement between months, never within one, and never as a daily series. A null amount is a month no connected account covered — not a zero balance. The field is absent when there is no reconstructed history, so make a trend claim only when it is present.

unavailable: true means amount is a placeholder, not a real measurement (e.g. no accounts connected yet) — say so plainly rather than presenting it as a real €0 balance. partial: true means one or more accounts were excluded from an otherwise real total (e.g. missing FX rate) — mention the exclusion count and any hints rather than presenting the number as unconditionally complete.

Everything here is backward-looking — no burn rate or runway is implied. Call well_get_runway instead for a forward-looking figure.

Pass year + month to read the balance as of the end of a past month instead of today. Note that balance_history (the trailing sparkline series) is returned ONLY for the live reading: a historical month has no live final point to anchor a trailing series on, so asking for a period returns the point-in-time balance without the series.

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
as_ofNo
errorNo
hintsNo
amountYes
partialNo
successYes
accountsYes
currencyNo
excludedNo
unavailableYes
connectors_urlNo
balance_historyNo
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 mark the call read-only, and the description adds substantial behavioral context: unavailable/partial placeholder semantics, null balance_history meaning, backward-looking scope, live-only balance_history, and month-end historical granularity. No contradiction with annotations.

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?

Though long, the description is front-loaded with purpose and every paragraph earns its place: output interpretation, historical semantics, edge-case flags, and workspace/auth behavior. There is no filler or redundant marketing language.

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-only tool with zero required parameters, a full schema, and an output schema, the description is comprehensive. It covers return fields, edge-case flags, live vs historical behavior, workspace selection, and routes to well_get_runway when appropriate, leaving no material gap for an agent to guess.

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?

The input schema documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics on top: year+month means end-of-past-month as-of, balance_history is omitted for historical reads, and workspace_id selection rules for multi-workspace tokens.

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 ('Get the workspace's current cash position') and details exactly what it returns: the converted total, per-account breakdown, and the same computation as the Well app's KPI card. It also distinguishes itself from manual summing and nearby cash-related tools.

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?

Explicitly tells the agent when to use this tool and when not: use it instead of summing account balances yourself, and call well_get_runway instead when a forward-looking figure is needed. It also gives concrete invocation rules for single-workspace vs multi-workspace tokens.

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