stub

Update bank account

update_bank_account

Update an existing bank account by id — its name, bank, account number or opening balance. Changing the opening balance regenerates the account's synthetic opening-balance entry. An opening date later than the account's own earliest transaction is refused, unwritten, with code confirm-required until the same call is repeated with confirm true. To add a brand-new account use create_bank_account. PROD-2612: an :accountid naming another ledger account moves the bank account and its bare feed transactions onto it; pick one from /bankaccount/candidates and send :openingbalance 0, because a feed's stored opening balance would otherwise refuse the move, and clearing it lets the next sync write it again.

Input Schema

Name	Required	Description
`id`	No	ID of the bank account, required for updates
`bank`	No	Name of the bank
`sync`	No	Whether automatic bank sync is enabled
`hidden`	No	Whether the account is hidden/soft-deleted (removes its card; also stops sync)
`confirm`	No	PROD-1536: required only to save an opening date that is LATER than the account's own earliest transaction. Without it that one case is refused, unwritten, with code confirm-required plus earliesttransactiondate and transactionsbefore, so the caller can show what the date would exclude and let the user override it.
`private`	No	Whether this is a private account
`syncing`	No	Whether sync is currently in progress
`archived`	No	Whether the account is archived
`accountid`	No	The ledger account this bank account settles into. PROD-2612: set it to one of the business's own asset accounts to use that account instead of minting a new one; it must not be a control or built-in account or another bank's, and the request must leave out the opening balance and any other currency. Refused with a link-* reason.
`swiftcode`	No	SWIFT/BIC code for international transfers
`branchcode`	No	Bank branch code or routing number
`accountname`	No	Name of the bank account
`accounttype`	No	Type of account (e.g., checking, savings)
`openingdate`	No	Date of the opening balance
`openingrate`	No	PROD-2452: for an account in a currency other than the business's, the opening exchange rate as account-currency units per one base unit (21.7821 ZAR per GBP); must be above 0. Omitted, the rate feed's rate on the opening date is used. Ignored for a base-currency account.
`syncenabled`	No	Whether this account is enabled for bank sync
`accountnumber`	No	Bank account number
`creditaccount`	No	Default credit account ID
`creditjournal`	No	Default credit journal ID
`openingbalance`	No	Opening balance for the account
`clearopeningbalance`	No	PROD-1200: when true, fully REMOVE the opening balance — retracts openingbalance, openingdate and the FX opening rate and base value (clears the Insights banner). Distinct from setting the balance to 0, which stays 'set'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / accountid / description

Previous value: -"Linked accounting account ID"New value: +"The ledger account this bank account settles into. PROD-2612: set it to one of the business's own asset accounts to use that account instead of minting a new one; it must not be a control or built-in account or another bank's, and the request must leave out the opening balance and any other currency. Refused with a link-* reason."

Changed2 schema fields changedOct 12, 2026

changedInput schema / properties / clearopeningbalance / description

Previous value: -"PROD-1200: when true, fully REMOVE the opening balance — retracts both openingbalance and openingdate (clears the Insights banner). Distinct from setting the balance to 0, which stays 'set'."New value: +"PROD-1200: when true, fully REMOVE the opening balance — retracts openingbalance, openingdate and the FX opening rate and base value (clears the Insights banner). Distinct from setting the balance to 0, which stays 'set'."

addedInput schema / properties / openingrate

Added value: +{
+  "description": "PROD-2452: for an account in a currency other than the business's, the opening exchange rate as account-currency units per one base unit (21.7821 ZAR per GBP); must be above 0. Omitted, the rate feed's rate on the opening date is used. Ignored for a base-currency account.",
+  "type": "number"
+}

Changed1 schema field changedSep 16, 2026

addedInput schema / properties / confirm

Added value: +{
+  "description": "PROD-1536: required only to save an opening date that is LATER than the account's own earliest transaction. Without it that one case is refused, unwritten, with code confirm-required plus earliesttransactiondate and transactionsbefore, so the caller can show what the date would exclude and let the user override it.",
+  "type": "boolean"
+}

First observedSep 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description does the heavy lifting: it discloses that changing the opening balance regenerates the synthetic opening-balance entry, that a too-late opening date is refused unwritten with code confirm-required until repeated with confirm true, and that a ledger-account move is refused with a link-* reason. These are exactly the side effects and failure modes an agent must anticipate.

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

Conciseness3/5

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

Purpose and the sibling hand-off are front-loaded, but the closing PROD-2612 sentence is a dense run-on mixing internal ticket IDs, path syntax and colon-prefixed parameter names (":openingbalance 0"), which slows an agent parsing it. The ticket references are arguably noise, though each sentence does carry operational content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 21-parameter mutation with no output schema and minimal annotations, the description covers the genuinely risky paths well. It omits two things an agent would want: that the call is a partial update (zero required parameters), and any hint about how a successful response looks or whether the regenerated opening-balance entry is revertible.

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 baseline is 3; the description earns an extra point for cross-parameter meaning the schema cannot express — that :accountid must be paired with :openingbalance 0 because a feed's stored opening balance would otherwise refuse the move. It does not explain the many unmentioned flags (hidden, sync, syncing, swiftcode), leaving those to the schema.

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 ("Update an existing bank account by id") and enumerates the mutable facets (name, bank, account number, opening balance). It explicitly routes the create case to create_bank_account, so the agent can distinguish it from at least one sibling without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear 'use this to update, use create_bank_account for new' routing, plus a concrete procedure for the PROD-2612 move case (pick from /bankaccount/candidates, send openingbalance 0) and the confirm-retry loop. It never mentions update_bank_account_currency or update_account, which are the nearest siblings an agent could confuse with this one, so the alternative-mapping is incomplete.

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

All stub 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?