Well

List uncategorized transactions in a window

well_list_uncategorized_window

Read-only

List the transactions in a date window that carry no category, so a figure that depends on categorization can say exactly what is missing before it is computed.

from is inclusive and to is EXCLUSIVE — for whole months, pass the first day of the month after the last one you want.

These rows are measured on when the movement happened (executed_at), not on its accounting date. That is deliberate and it matters: the two disagree about which MONTH a transaction belongs to for a large share of real data, and many rows carry no accounting date at all. A caller listing rows on one basis while summing a figure on the other ends up with rows it counts but cannot offer to fix. Pair this with a sum measured on the same basis.

Returns each row's identity, amount, counterparty and the classifier's pending suggestion where one exists. It lists rows with NO category; a categorized row that has not yet posted to the ledger is a booking question and is not returned here.

meta.truncated: true means the page filled and more rows exist, so report the count as a floor rather than as the total. meta.returned is what came back.

success: false means the window is UNKNOWN, not empty. The read failed, so no count exists and returned and truncated are absent rather than zero. An empty records on a failed read is not "nothing is uncategorized" — treating it that way reports a clean list this read never produced. Say the list could not be read.

Do not propose categories from this list. Where the classifier has a proposal it rides on the row, and the assignment surface is where a category is chosen.

When the user asks to see, list or fix these rows, call this tool directly: its card is the answer. ⚠️ This tool draws its card on EVERY call, the empty one included. So when nobody asked for the list and you only need to CHECK whether anything is left (the first pass of a gate, or a re-check after a repair), call well_get_worklist_status({ worklist: "uncategorized_window", from, to }) first, with the same scope you would pass here. It draws nothing. Call this tool after it only when it answers open: true.

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
`to`	Yes	EXCLUSIVE end of the window, YYYY-MM-DD.
`from`	Yes	Inclusive start of the window, YYYY-MM-DD.
`limit`	No	Max rows to return (default 500).
`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
`error`	No
`window`	Yes
`records`	Yes
`success`	Yes
`returned`	No
`truncated`	No
`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"
+}

AddedSep 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses behavior far beyond the readOnlyHint/destructiveHint annotations: it explains the card-drawing on every call, the executed_at vs accounting date basis, the semantics of meta.truncated and success:false, and the workspace_id guessing behavior. This is rich, non-obvious behavioral context that annotations alone cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is longer than average but well-structured with bolded key semantics and paragraph breaks. It front-loads the core purpose and then adds necessary caveats. Every sentence carries substantive content; nothing is fluff. The length is justified by the tool's subtle behaviors, though it could be trimmed slightly without losing meaning.

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 output schema existence, the description doesn't need to detail return fields, but it goes further to explain meta.truncated and success:false behaviors, which are critical for correct interpretation. It covers failure modes, workspace handling, and the card side-effect. Nothing an agent needs to call this correctly and interpret results 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%, so the baseline is 3. The description adds meaningful nuance to parameters: it clarifies that 'from' is inclusive and 'to' is exclusive with a month-boundary example, explains when to omit or pass workspace_id based on token scope, and details the conversation_id requirement for continuity. This goes beyond the schema descriptions.

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 a clear verb+resource: 'List the transactions in a date window that carry no category'. It further distinguishes this from related operations by noting it returns only rows with NO category and excludes categorized-but-unposted rows, which is a different booking question. This differentiates it from siblings like well_list_unposted_transactions.

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 explicitly gives when-to-use and when-not-to-use guidance. It directs callers to well_get_worklist_status when only checking status (to avoid drawing a card), and tells when to call this tool directly. It also warns against proposing categories from this list and clarifies measurement basis pairing with a sum. Alternatives are named and conditions are explicit.

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?