Well

Render a caller-computed runway

well_render_runway

Read-only

Put a runway YOU computed onto the runway card.

This tool measures nothing. It takes the figure and the two numbers behind it as input and returns them for rendering. Call it only after you have computed the cash and the burn yourself — never to "get" a runway.

A runway is one division, so this tool checks the one thing that can be checked: that the headline follows from the two figures you state with it. State them and it renders; state a headline they do not produce and it refuses.

Under the number the card draws nothing. It carries the months, the moment, the burn's own window when you send one (a bare month count when you do not) and a health badge. The cash amount, the burn amount and partial are REQUIRED and reach no pixel. All of it comes back in this tool's text result, which is what you write the prose from, the division included. The card is the measure; the explanation is yours.

REQUIRED:

months — months of cash left, capped at 36
status — "ok", "capped", "infinite" or "insufficient_data"
cash — the dividend, amount and currency. SIGNED: an overdrawn workspace is negative. null ONLY under "insufficient_data", so a half you could not measure is reported rather than invented.
avg_burn — the divisor as a POSITIVE magnitude, its currency, and the trailing_months it averaged
as_of — the moment the reading is valid for
partial — whether the cash may be a floor (the skills' is_floor), because an account with no readable balance or no rate was left out of it. It never means a cut-short read: a cut-short balances read or sum stops the run before this call.

OPTIONAL, and send it whenever you are sending a burn:

window — the months the burn averaged, inclusive start and EXCLUSIVE end, each on a month start. The card names those months instead of a bare count, so a reader can see which months the figure stands on. Without it the card can only pair the cash moment with the number of months, which reads as a window ending at that moment whatever months you actually averaged. Send NONE when avg_burn is null.

The statuses carry two distinctions worth stating, because both are easy to collapse:

Zero months is DATA when the cash is gone. A workspace already underwater has a real runway of zero, status "ok" — not "insufficient_data", which means the inputs could not be measured at all.
Unbounded is not the same as long. "infinite" means the workspace is not burning; "capped" means it burns slowly enough that the figure passes the 36-month window the product reports in.

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

months that is not cash ÷ avg_burn — the division is the figure's whole claim
a cash currency that differs from the burn's; one division needs one currency
a negative avg_burn; it is a magnitude, so a negative one means a subtotal was re-signed
"infinite" with a non-zero burn, or a zero burn reported as anything else
"capped" whose division lands inside the window, or which reports a number other than 36
a division past the window reported as "ok" instead of "capped"
non-positive cash reported as anything but a real zero
"insufficient_data" carrying a months figure, or a null figure under any other status
an unbounded runway reporting anything but the 36-month sentinel
an as_of in the future
a window whose bounds are not each the first of a month, or that spans no month
a window that spans a different number of months than avg_burn.trailing_months — the two state one fact, and a reader cannot tell which is the lie
a window sent with no burn to average — an unmeasured burn averaged no months
a window reaching into a month that has not ended yet
a window bound naming no calendar month, or an unknown key on the object

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
`cash`	Yes
`as_of`	Yes
`months`	Yes
`status`	Yes
`window`	No	Inclusive start and EXCLUSIVE end of the months the burn averaged, YYYY-MM-DD.
`partial`	Yes
`avg_burn`	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
`cash`	Yes
`as_of`	Yes
`months`	Yes
`status`	Yes
`window`	No
`partial`	Yes
`success`	Yes
`avg_burn`	Yes
`computed_by`	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 17, 2026

addedInput schema / properties / window

Added value: +{
+  "additionalProperties": false,
+  "description": "Inclusive start and EXCLUSIVE end of the months the burn averaged, YYYY-MM-DD.",
+  "properties": {
+    "from": {
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    "to": {
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "from",
+    "to"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / window

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "from": {
+      "type": "string"
+    },
+    "to": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "from",
+    "to"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedSep 15, 2026

removedOutput schema / properties / caller

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

changedOutput schema / required

Previous value: -[
-  "months",
-  "status",
-  "cash",
-  "avg_burn",
-  "as_of",
-  "partial",
-  "computed_by",
-  "caller",
-  "success"
-]New value: +[
+  "months",
+  "status",
+  "cash",
+  "avg_burn",
+  "as_of",
+  "partial",
+  "computed_by",
+  "success"
+]

AddedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description is exceptionally transparent, detailing that the tool measures nothing, checks the division, refuses invalid inputs, and returns a text result for prose. It explains the status distinctions and the refusal conditions comprehensively, adding far beyond the annotations (readOnlyHint, destructiveHint) which already indicate safety. 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long (over 600 words) and includes extensive detail, some of which is repeated (e.g., the division check). It is well-structured with bold headers and sections, but it is not concise. The verbosity may be justified by the complexity, but it could be trimmed.

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?

Given the complexity (9 params, nested objects, output schema), the description is remarkably complete. It covers all required parameters, optional window, status distinctions, refusal conditions, and the return text. It omits conversation_id, but that appears to be a standard cross-tool parameter with schema description, and its absence doesn't hinder use. The output schema exists, so return values are defined.

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 schema coverage at 33%, the description compensates richly. It explains each required parameter's semantics: cash is signed, avg_burn is a positive magnitude, months capped at 36, status meanings, partial meaning, and window semantics. It also explains conversation_id implicitly? Not mentioned, but that's a cross-tool standard. The description adds substantial meaning beyond the schema.

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 states clearly that the tool renders a runway the caller computed, and explicitly says it measures nothing. It distinguishes itself from measurement tools by emphasizing it only renders provided figures. The verb 'render' and resource 'runway card' are specific, and the distinction from siblings like well_render_burn is implicit but strong.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use: 'Call it only after you have computed the cash and the burn yourself — never to "get" a runway.' It also provides guidance on workspace authorization. However, it does not name specific alternative render tools, relying on the title and context to differentiate, so it's clear but not exhaustive.

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?