Well

List transactions still to post

well_list_unposted_transactions

Read-only

List the transactions of a fiscal period that carry a category or a role and have STILL not reached the ledger, so a close can say exactly what is holding it.

This is the posting gap, not the categorization gap. A row here already has a category; what it lacks is the ledger account its journal entry would post to. For rows carrying no category at all, use well_list_uncategorized_window.

Each row carries transaction_id, label, amount, period_date, the current_ledger already attached where one is, and ledger_suggestions — the classifier's proposals, each with the account's code (its number, e.g. "6156") beside its name.

The ledger_catalog.accounts list carries every account this workspace can post to, with the id well_set_transaction_ledger_account takes. A row whose ledger_suggestions is empty is assigned from that list: the classifier proposed nothing, which is not the same as the row having nowhere to go.

The rows arrive snake_cased (period_date, ledger_suggestions, current_ledger), unlike well_list_uncategorized_window, whose close cousin emits camelCase. A caller reading one shape against the other silently sees empty fields rather than an error.

The period is named in FISCAL terms, and a workspace's fiscal calendar need not follow the calendar year: "June 2026" is not reliably fiscal period 6. Take fiscal_year and fiscal_period from a well_list_periods entry, or from the months the user already selected in this conversation; never derive them from a calendar month yourself.

Most categories already determine their ledger account: the chart maps each category key to a canonical code, and only a handful abstain because the category alone cannot pick a safe account without the transaction direction. So a long list here usually means the categories are missing, not the accounts.

success: false means the period is UNKNOWN, not clear. The read failed, so no count exists, and an empty records on a failed read is not "everything posted".

truncated: true means the period holds MORE unposted rows than this page carries, so returned is a floor rather than the period's total. Narrow the period, or state the count as "at least".

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: "unposted_transactions", fiscal_year, fiscal_period }) 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
`limit`	No	Max rows to return.
`fiscal_year`	Yes	The fiscal year of the period to read.
`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.
`fiscal_period`	Yes	The fiscal period, 1-12 for a month; 13 is the adjustment period and resolves to no rows.
`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
`records`	Yes
`success`	Yes
`returned`	No
`truncated`	No
`ledger_catalog`	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 9, 2026

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 and destructiveHint=false, and the description adds substantial behavioral context beyond that: snake_case vs. camelCase field casing, fiscal-period semantics, success:false meaning unknown rather than clear, truncated:true meaning the returned count is a floor, and the fact that the tool draws its card on every call.

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 tightly packed: every paragraph introduces a distinct, decision-relevant caveat. It front-loads the core purpose, then organizes critical operational behaviors with clear framing, so the length is justified rather than padded.

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 tool with this many edge cases — failed reads, truncation, sibling-tool routing, workspace authorization, fiscal-period ambiguity, and output casing — the description covers every behavior an agent needs to call it correctly. The presence of an output schema and full parameter descriptions further completes the picture.

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 and the schema already documents each parameter. The description adds real value on top by explaining where fiscal_year and fiscal_period should come from (well_list_periods or conversation context, never calendar math), when workspace_id is required, and which parameter feeds well_set_transaction_ledger_account.

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 and resource: list transactions of a fiscal period that carry a category or role and have not reached the ledger. It also explicitly differentiates itself from well_list_uncategorized_window, so an agent can tell the posting gap apart from the categorization gap.

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 gives explicit when-to-use guidance: call directly when the user asks to see, list, or fix these rows; call well_get_worklist_status first when only checking whether anything is left. It also spells out workspace_id handling for single vs. multi-workspace token authorization and states not to derive fiscal periods from calendar months.

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?