Well

Render a caller-computed cash-flow bridge

well_render_cash_flow_bridge

Read-only

Put a cash-flow bridge YOU computed onto the cash-flow waterfall card.

This tool measures nothing. It takes the four terms of a bridge and the gap between them as input, draws the waterfall, and returns them. Call it only after you have read the opening and closing positions and summed the window's flows yourself — never to "get" a bridge.

A bridge rests on one law: the opening, plus the inflows, minus the outflows, lands on the closing. The closing is measured on its own rather than summed from the flows, so the law is a check rather than a given. State the gap as unexplained and the tool verifies the five figures add up; state figures that do not and it refuses.

REQUIRED:

currency — every figure below is in it, each converted before you stated it
period_start, period_end — the inclusive calendar days the flows cover
opening — amount (SIGNED, a workspace can be overdrawn), as_of (the day before period_start), and derived (true only when you solved it from the law because the reading could not be taken)
inflows, outflows — gross magnitudes, both positive; the direction lives in which bar they are
unexplained — the SIGNED gap closing - (opening + inflows - outflows), computed from the figures as you rounded them; zero when they meet
closing — amount (SIGNED) and as_of, the moment the reading was taken
reconciles — true when the gap is inside the tolerance below, false when it is past it
partial — true when any term is incomplete: an anchor some accounts had no reading for, flows with rows no owned account could be placed against, rows that could not be read, or a currency with no rate. A cut-short read returns no rows and stops the run before this call

The tolerance is the product's own: 1% of the closing position's size, never less than 1 in the base currency. A bridge that does not reconcile draws an Unexplained bar between the outflows and the closing; one that does draws none.

REFUSED rather than rendered, each because your own figures disagree:

five figures that do not add up to within a cent
reconciles: true with a gap past the tolerance, or false with one inside it
a negative inflows or outflows; each is a magnitude, so a negative one was re-signed
an opening not dated the day before period_start
a window ending more than a day from the day the closing was read
a window that starts after it ends, or a date that names no real day
a derived opening with any gap, on a partial read, or over a window with no flows
a closing as_of in the future

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

Name	Required	Description
`closing`	Yes
`inflows`	Yes
`opening`	Yes
`partial`	Yes
`currency`	Yes
`outflows`	Yes
`period_end`	Yes
`reconciles`	Yes
`unexplained`	Yes
`period_start`	Yes
`workspace_id`	No	Target 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.
`conversation_id`	No	The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.

Output Schema

TableJSON Schema

Name	Required	Description
`steps`	Yes
`closing`	Yes
`inflows`	Yes
`opening`	Yes
`partial`	Yes
`success`	Yes
`currency`	Yes
`outflows`	Yes
`period_end`	Yes
`reconciles`	Yes
`computed_by`	Yes
`unexplained`	Yes
`period_start`	Yes
`conversation_id`	No	The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
`resolved_workspace`	No	The workspace that answered, when the caller named none and the token authorizes several.
`conversation_id_note`	No	Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.
`conversation_id_source`	No	Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 22, 2026

addedInput schema / properties / conversation_id

Added value: +{
+  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
+  "type": "string"
+}

addedOutput schema / properties / conversation_id

Added value: +{
+  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
+  "type": "string"
+}

addedOutput schema / properties / conversation_id_note

Added value: +{
+  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
+  "type": "string"
+}

addedOutput schema / properties / conversation_id_source

Added value: +{
+  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
+  "enum": [
+    "host_meta",
+    "argument",
+    "minted"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedSep 15, 2026

removedOutput schema / properties / caller

Removed value: -{
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "currency",
-  "period_start",
-  "period_end",
-  "opening",
-  "inflows",
-  "outflows",
-  "unexplained",
-  "closing",
-  "reconciles",
-  "partial",
-  "steps",
-  "computed_by",
-  "caller",
-  "success"
-]New value: +[
+  "currency",
+  "period_start",
+  "period_end",
+  "opening",
+  "inflows",
+  "outflows",
+  "unexplained",
+  "closing",
+  "reconciles",
+  "partial",
+  "steps",
+  "computed_by",
+  "success"
+]

AddedSep 11, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint, the description discloses arithmetic verification, the 1% tolerance floor, refusal conditions, partial-read behavior, and the Unexplained-bar rendering. This is rich behavioral context an agent needs to predict side effects and failures.

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 front-loaded: first sentence states purpose, second warns what the tool does not do, then organized REQUIRED/tolerance/REFUSED sections carry the details. Given the 12-parameter complexity, the density is justified with little redundancy.

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 description covers invocation timing, parameter constraints, validation rules, workspace authorization behavior, and refusal outcomes. Since an output schema exists, not detailing return values is acceptable; an agent has what it needs to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 17% schema coverage, the description compensates by explaining every required parameter: signed amounts, as_of conventions, gross positive inflows/outflows, the unexplained formula, derived-opening restrictions, and partial semantics. It adds meaning far beyond the schema's enum/type declarations.

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 names a specific verb ('Put ... onto the cash-flow waterfall card') and resource, and immediately clarifies the tool's non-measuring role. It is clearly distinguishable from siblings like well_render_cash_position and well_render_cash_forecast.

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?

It explicitly states when to call ('only after you have read the opening and closing positions and summed the window's flows yourself') and when not to ('never to "get" a bridge'). It also gives workspace-token conditions for calling directly and when workspace_id is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Well tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?