Well

Set a transaction's ledger account

well_set_transaction_ledger_account

Attach ONE transaction to the ledger account its journal entry should post to — the write that clears a posting gap.

REQUIRED: transaction_id, from well_list_unposted_transactions. ledger_account_id — an account id from that read's ledgerCatalog, or from the row's own ledger_suggestions. Pass null to DETACH the account rather than to leave it unchanged; omitting the field is not how you clear one, because the field is required here.

Attaching the account does not, on its own, clear the gate. The worklist selects on posting attempts, not on whether an account is present, so a row you attach and leave will come back on the next read. Posting is what clears it.

Set no_invoice_expected: true to post the entry in the same call. Send it ONLY for a row whose expects_supplier_invoice is false on well_list_unposted_transactions, which is the read that carries that field: it asserts that no supplier invoice is coming, which is what makes the transaction bookable on its own. A row still waiting for its invoice must be attached WITHOUT it — the invoice is its blocker, and posting early books an entry the invoice would then contradict.

Omit the field and nothing posts: the account is recorded and the row stays on the worklist.

Most categories already imply their account — the chart maps each category key to a canonical code — so reach for this for the rows the category alone cannot settle, and for a deliberate override.

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
`workspace_id`	No	Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
`transaction_id`	Yes	The transaction to attach, from well_list_unposted_transactions.
`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.
`idempotency_key`	No	Optional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
`ledger_account_id`	Yes	The ledger account to attach. `null` DETACHES the account currently on the row.
`no_invoice_expected`	No	Assert no supplier invoice is coming, and post the entry to the attached account in the same call. Only for a row whose `expects_supplier_invoice` is false.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`posted`	No
`success`	Yes
`transaction_id`	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.
`posting_outcome`	No
`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

A5/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, so the description carries the burden of explaining side effects. It does so thoroughly: attaching alone does not clear the worklist gate, null detaches the account, omitting no_invoice_expected means nothing posts, and posting early for an invoice-pending row would create a contradiction. 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?

The description is long, but the complexity justifies it. Each section earns its place: core action, required parameters, non-obvious gate behavior, the conditional posting flag, the relationship to category-based defaults, and workspace handling. The most important information is front-loaded.

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 write tool with non-obvious semantics, the description covers prerequisites, source reads, conditional behavior, workspace ambiguity, and the difference between attaching and posting. With an output schema present, return-value details are not required. Nothing essential is missing for correct selection and invocation.

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?

Although schema coverage is 100%, the description adds meaning well beyond the schema: transaction_id must come from well_list_unposted_transactions, ledger_account_id can come from ledgerCatalog or ledger_suggestions, null has detach semantics rather than leave-unchanged, and no_invoice_expected is only valid when expects_supplier_invoice is false. This materially improves correct invocation.

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 opens with a specific verb and resource: 'Attach ONE transaction to the ledger account its journal entry should post to — the write that clears a posting gap.' It clearly distinguishes itself from sibling operations like well_set_transaction_category by explaining that this tool is for rows the category alone cannot settle or for deliberate overrides.

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 gives explicit when-to-use guidance: use it for rows the category cannot settle, or for deliberate overrides. It also gives precise conditions for no_invoice_expected, states that attaching alone does not clear the gate, and explains when workspace_id must be passed. These are actionable selection and invocation rules.

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?