Skip to main content
Glama

Update transaction

well_update_transaction
Destructive

Hide a bank transaction from Well's lists, or show it again.

Well never deletes a bank line: the bank keeps it, and the next sync would bring it back. When the person asks to delete or remove a transaction ("supprime cette transaction", "remove this payment from my figures"), offer to hide it instead, in one line: it leaves Well's lists, stays in the bank and in Well, and can be shown again. Say that cash, burn, runway, sums and the books still count it, because the money moved. Once the person says yes, call this tool with hidden: true. Never hide without that yes.

REQUIRED: transaction_id (from a transaction read), hidden (true hides the line, false shows it again).

The line keeps its category, its ledger account and its accounting entries. To list hidden lines, read transactions with hidden_at not null.

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

Input Schema

NameRequiredDescriptionDefault
hiddenYestrue hides the bank line from Well's lists and keeps it; cash, burn, runway, sums and the books still count it. false shows it again.
workspace_idNoTarget 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_idYesThe transaction to hide or show again, from a transaction read.
conversation_idNoThe 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_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict 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.

Output Schema

NameRequiredDescriptionDefault
codeNo
errorNo
hiddenNo
successYes
reply_linesNo
transaction_idNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
near_candidatesNo
newly_connectedNoTools 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_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
near_candidates_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • 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"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: explains that the bank keeps the line and a sync would bring it back, that hiding is reversible via hidden: false, that cash, burn, runway, sums and the books still count it, and that category, ledger account and accounting entries are preserved. The destructiveHint=true annotation is reconciled rather than contradicted — the description makes clear no data is destroyed, only visibility changes.

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?

Front-loaded with the one-line purpose, then rationale, consent flow, required params and return shape in a sensible order. Slightly redundant — the "bank keeps it / stays in the bank and in Well" point is made twice — but every block still carries distinct operational value.

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?

Six parameters, an output schema, and non-trivial annotations are all accounted for: the description covers the consent prerequisite the annotations cannot express, the effect on downstream figures, reversibility, and the success/failure return shape. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already defines hidden, workspace_id, transaction_id, conversation_id, idempotency_key and workspace_scope in detail. The description restates the two required params with their provenance ("from a transaction read") but adds no new information for hidden or for the workspace/conversation parameters, so this sits at the baseline where the schema carries the load.

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 pair and resource — hide/show a bank transaction — and immediately narrows the scope to "Well's lists", which is precisely the distinction an agent needs. It also frames the operation as the substitute for deletion, so the agent can tell it apart from the many well_delete_* siblings without opening a schema.

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?

Explicit trigger (the person asks to delete or remove a transaction, with example phrasings), explicit action (offer to hide instead), explicit precondition ("Once the person says yes... Never hide without that yes"), and a pointer for the inverse lookup ("read transactions with hidden_at not null"). When-to-use, when-not-to-use, and the consent gate are all spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources