Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Correct a bank account and its opening balance

update_bank_account
Destructive

Correct a bank account's details or set its opening balance and date to align the ledger with an audited balance.

Instructions

Correct a bank account's name, institution, BSB, account number, account holder, status, notes, or its opening balance. opening_balance (AUD) is the balance at the START of opening_balance_date: cash transactions dated before that day are excluded from the ledger (the result reports how many, as pre_opening_transaction_count/_total, so they can be reviewed), and the account contributes 0 to any balance as at an earlier date. Use it to anchor the ledger to an audited closing balance — e.g. a 30/6/24 audited balance of $163.93 is opening_balance 163.93 with opening_balance_date 2024-07-01. Refused if the change would move the closing balance of a closed or lodged financial year (reopen that year first). Only the fields you pass change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fund_id": "<fund_id>",
      "bank_account_id": "<bank_account_id>"
    },
    "name": "update_bank_account"
  }
}

Input Schema

NameRequiredDescriptionDefault
bsbNoBSB, e.g. "082-001"
nameNo
notesNo
statusNo
fund_idYesFund ID (discover via whoami or list_funds)
closed_onNoLast day the account was open. Closes it (status becomes closed); the ledger can't hold movements after it. Later years drop the account; the year it closed in proves a nil 30 June balance. Reopen by setting status active. as an ISO date, e.g. "2026-05-30"
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
account_roleNo
external_refNoYour stable ID for this write (e.g. a statement line or document reference). Repeating a call with the same external_ref replays the first result instead of writing twice.
account_numberNoAccount number (stored encrypted)
bank_account_idYesBank account ID (find via list_bank_accounts)
opening_balanceNoBalance in AUD at the start of opening_balance_date
institution_nameNo
account_holder_nameNo
opening_balance_dateNoDate the opening balance applies from as an ISO date, e.g. "2026-05-30"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / closed_on
      Added value: +{
      +  "description": "Last day the account was open. Closes it (status becomes closed); the ledger can't hold movements after it. Later years drop the account; the year it closed in proves a nil 30 June balance. Reopen by setting status active. as an ISO date, e.g. \"2026-05-30\"",
      +  "type": "string"
      +}
  2. Addedv1.8.1

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: it declares partial-update semantics ('Only the fields you pass change'), the year-lock refusal, how pre-opening-date cash transactions are excluded and surfaced via pre_opening_transaction_count/_total, and that the account contributes 0 to earlier-date balances. This is exactly the consequence-level context an agent needs for a destructive write.

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?

Single dense paragraph but front-loaded with the editable-field list, then the opening-balance mechanics, then the refusal rule. The worked dollar example is slightly verbose but earns its place by removing ambiguity about the date convention.

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 15-parameter destructive mutation with no output schema, it covers purpose, partial-update behavior, preconditions, and even names the result fields returned. It could say more about status/closed_on interaction and idempotent replay, but nothing critical for a correct call is missing.

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 60%, and the description compensates by fully defining opening_balance relative to opening_balance_date, including the audited 30/6/24 → 163.93 with 2024-07-01 example. It leaves idempotency (external_ref), audit reasoning, and closed_on handling to the schema, which already documents them.

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 ('Correct') plus the resource (bank account) and enumerates exactly which fields are editable, which cleanly separates it from create_bank_account and list_bank_accounts. The opening-balance semantics are spelled out rather than left implicit.

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?

Explains the intended use case for opening_balance ('anchor the ledger to an audited closing balance') with a concrete worked example, and states a hard precondition: refused if it would move the closing balance of a closed or lodged year, reopen that year first. That routes the agent to reopen_financial_year, though no sibling is named explicitly.

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

Deploy Server

Other Tools