Well

Update journal entry

well_update_journal_entry

Move lines of ONE journal entry to another ledger account ("Move AC-0390 to 6262, telephone", "Passe l'écriture en 6262").

REQUIRED: journal_entry_id, and lines: one item per change, each with ledger_account_id (the account to move to, from well_list_ledger_accounts) and EITHER from_ledger_account_id (the account the lines sit on now: every line of the entry on it moves) OR journal_entry_line_id (one line). Name the account the person wants changed with from_ledger_account_id; never move the counterpart line (bank, supplier, VAT) unless the person names it.

A draft entry changes in place. A posted entry (validated or locked) is never rewritten: Well keeps it, writes a reversal dated today and a new entry dated today with the corrected lines. applied_as says which: "in_place", "correction", or "unchanged" when every line was already on that account. Name what changed in the reply: the entry, the new account and the old one ("AC-0390 is now in 6262 telephone, was 6068"), and for a correction the two new entry numbers.

Only an owner or an admin of the workspace changes an entry. Refused, with nothing written: an entry a connected accounting tool synced in (change it in that tool), an entry Well posted from a document (JOURNAL_ENTRY_SOURCE_DERIVED: the next posting of the document would undo the change; for a bank transaction, set its account with well_set_transaction_ledger_account, which posts the entry again), an entry that reverses another, an entry already reversed (change the entry that corrects it), and a write whose period is locked.

Returns { success: true, journal_entry } on success, or { success: false, error } on failure.

Input Schema

Name	Required	Description
`lines`	Yes
`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.
`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.
`workspace_scope`	No	Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
`journal_entry_id`	Yes	The entry to change.

Output Schema

Name	Required	Description
`code`	No
`error`	No
`success`	Yes
`reply_lines`	No
`journal_entry`	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.
`near_candidates`	No
`newly_connected`	No	Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
`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.
`near_candidates_truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 28, 2026

addedOutput schema / properties / code
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / near_candidates

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "company_id": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "company_id",
+      "name"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / near_candidates_truncated
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / reply_lines

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

AddedOct 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes far beyond the annotations: it discloses that drafts mutate in place while posted entries are preserved via a dated reversal plus a new entry, and it exposes the applied_as outcome values ('in_place', 'correction', 'unchanged'). It also states the permission model (owner/admin only) and lists refusal conditions with error codes such as JOURNAL_ENTRY_SOURCE_DERIVED. Nothing here contradicts readOnlyHint=false or destructiveHint=false – the reversal design is consistent with the non-destructive claim.

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?

Purpose and required parameters are front-loaded, then behavior, then refusals, then returns – a sensible order with no filler sentences. It is dense and long, and a couple of the refusal clauses (particularly the bank-transaction redirect) run on more than needed, keeping it a notch below maximum.

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 mutating accounting write this covers everything an agent needs: which parameters to combine, what happens to posted entries, who may call it, what gets refused and where to go instead, and what the result contains. It even explains return values despite an output schema existing, which is a bonus rather than a gap.

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?

Schema coverage is already 83%, but the description adds decision-level semantics the schema cannot: the mutual exclusivity of from_ledger_account_id ('every line of the entry on it moves') versus journal_entry_line_id ('one line'), and the sourcing rule for ledger_account_id from well_list_ledger_accounts. That is meaning beyond the field descriptions, so it exceeds the baseline 3.

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?

States a specific verb and resource with scope: 'Move lines of ONE journal entry to another ledger account', illustrated with two real phrasings a user might use. It is clearly distinguishable from siblings like well_create_journal_entry_reversal, well_update_transaction and well_set_transaction_ledger_account, the last of which is explicitly named as the alternative for bank 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?

Gives explicit when-to-use rules (choose from_ledger_account_id when the person names the account to change, journal_entry_line_id when they name a single line) and an explicit never-do ('never move the counterpart line unless the person names it'). It also enumerates when the call is refused and points to the right alternative for each case (connected tool, derived entry, reversed entry).

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?