stub

Create bank account

create_bank_account

Create a new bank account for the business (a real account money moves through — used for reconciliation and cashflow). Not a chart-of-accounts ledger account.

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
`currency`	No	ISO 4217 code (e.g. "USD") stamped on the new ledger account. Omit for the business's base currency; an unknown code is refused with reason unknown-currency.
`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 changedOct 8, 2026

addedInput schema / properties / currency

Added value: +{
+  "description": "ISO 4217 code (e.g. \"USD\") stamped on the new ledger account. Omit for the business's base currency; an unknown code is refused with reason unknown-currency.",
+  "type": "string"
+}

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

A3.9/5.0

Behavior3/5

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

Annotations already establish write semantics (readOnlyHint=false, destructiveHint=false), so the description only needs to add context. It does add the useful framing that this is a real bank account used for reconciliation and cashflow, but says nothing about what side effects creation triggers (ledger account minting, opening balance handling) or how the upsert-by-`id` behavior works.

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?

A single front-loaded sentence with a disambiguating parenthetical; nothing is wasted and the most important distinction arrives before any detail.

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

Completeness3/5

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

For a 22-parameter creation tool with intricate opening-balance, currency and ledger-linking behavior, the description itself is thin and leaves all of that to the schema. Because the schema is exhaustive and there is no output schema to explain, this is adequate but does nothing to help an agent anticipate the tool's real complexity.

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%, so the schema fully documents all 22 parameters including the complex confirm, accountid, openingrate and clearopeningbalance semantics. The description adds no parameter-level meaning beyond what the schema already provides, which is the baseline 3 case.

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 ("Create a new bank account for the business") and immediately disambiguates it from the nearest confusing sibling by clarifying it is a real money-movement account, not a chart-of-accounts ledger account. An agent can distinguish it from create_account 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?

The exclusion ("Not a chart-of-accounts ledger account") gives a clear negative-use signal that implicitly routes chart-of-accounts work to create_account. However, no alternative is named explicitly, and nothing says when to use this versus update_bank_account or update_bank_account_currency, despite the schema's `id` param mentioning updates.

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?