Beeswax Shares MCP Server

Update a ledger transaction

update_transaction

Destructive

Instructions

Edit an existing security-ledger transaction (trade or income) in place — e.g. add a distribution's annual tax statement components, set rent's GST treatment, set an entitlement date to accrue income to an earlier year, link a receipt to the prior-year receivable it settles, or enter a sell's capital gain. A receipt linked (or re-linked) to a receivable for more than is still outstanding on it is split: the outstanding part settles it and the excess is recorded as income on a new transaction (excess_income_transaction in the result). Only the fields you pass change; this overwrites them. Find the row via search_transactions (it gives the id and holding_id). Blocked if the transaction's financial year is closed or lodged. AUD.

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>",
      "holding_id": "<holding_id>",
      "transaction_id": "<transaction_id>"
    },
    "name": "update_transaction"
  }
}

Input Schema

Name	Required	Description
`notes`	No
`fund_id`	Yes	Fund ID (discover via whoami or list_funds)
`quantity`	No	Units
`cost_base`	No	Sell: cost base of the units sold (AUD)
`reasoning`	No	Why you are making this change — recorded on the audit log entry for this write
`broker_fee`	No
`gst_amount`	No	Exact GST included in total_amount, when known (overrides the 1/11th estimate) (AUD)
`holding_id`	Yes	Holding the transaction belongs to
`tenant_name`	No	Rent: tenant name
`external_ref`	No	Your 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.
`payment_date`	No	Payment date as an ISO date, e.g. "2026-05-30"
`total_amount`	No	New total amount (AUD unless currency set)
`gst_treatment`	No	GST treatment (rent especially). gst_inclusive: total_amount includes GST and is reported GST-exclusive; the others report total_amount as is. Setting any value clears gap G11 for rent
`price_per_unit`	No
`transaction_id`	Yes	Transaction ID (from search_transactions)
`entitlement_date`	No	Date the fund became entitled to the income (e.g. 30 June for a distribution declared for the year but paid in July). Decides the financial year the income is taxed in; defaults to transaction_date as an ISO date, e.g. "2026-05-30"
`ex_dividend_date`	No	Ex-dividend date as an ISO date, e.g. "2026-05-30"
`foreign_tax_paid`	No	Foreign income tax paid / withheld — 13 C1 offset (AUD)
`franking_credits`	No	Franking credits attached to a dividend (AUD)
`rental_period_to`	No	Rent: period end as an ISO date, e.g. "2026-05-30"
`transaction_date`	No	New transaction date as an ISO date, e.g. "2026-05-30"
`capital_gain_loss`	No	Sell: capital gain (+) or loss (−) from the tax statement — taken as given on the CGT schedule
`capital_gain_other`	No	Trust distribution: other-method capital gains — 1 G, not discountable (AUD)
`rental_period_from`	No	Rent: period start as an ISO date, e.g. "2026-05-30"
`cgt_discount_amount`	No	Sell: CGT discount amount, for reference (AUD)
`franking_percentage`	No	Percentage of a dividend that is franked (0–100)
`tax_deferred_amount`	No	Trust distribution: tax-deferred amount / AMIT cost-base net decrease — reduces the holding's cost base (AUD)
`capital_gain_indexed`	No	Trust distribution: indexation-method capital gains — 1 G, not discountable (AUD)
`cgt_concession_amount`	No	Trust distribution: CGT concession amount (the trust's discount; non-assessable, recorded for reference) (AUD)
`cgt_discount_eligible`	No	Sell: whether the gain is discountable (held 12+ months)
`foreign_income_amount`	No	Assessable foreign income (gross, before foreign tax) — item 11 D (AUD)
`trust_franking_credit`	No	Trust distribution: franking credits passed through — 13 E1 offset (AUD)
`amit_cost_base_increase`	No	Trust distribution: AMIT cost-base net increase — increases the holding's cost base (AUD)
`franked_distribution_amount`	No	Trust distribution: franked distributions (grossed up), from the annual tax statement — item 11 M (AUD)
`settles_fund_balance_item_id`	No	Balance item ID (list_balance_items) of the PRIOR-YEAR receivable this receipt collects. The receipt is then excluded from this year's income, because it was income of the earlier year
`capital_gain_discounted_gross`	No	Trust distribution: discount-method capital gains GROSSED UP (the discounted gain plus the CGT concession amount) — CGT schedule 1 G, discountable (AUD)
`non_primary_production_amount`	No	Trust distribution: non-primary-production income (unfranked / interest / other Australian income) — item 11 M (AUD)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.8.1Nov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description adds far more: partial-update semantics ('Only the fields you pass change; this overwrites them'), the side effect of splitting an over-settled receipt into a new transaction reported as excess_income_transaction, the closed/lodged financial year block, and the AUD currency assumption. These are exactly the consequences an agent must know before invoking 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?

Front-loaded with the core action, then examples, then the split rule, then the precondition — a sensible order. The opening sentence is long and example-heavy, but with 37 parameters the density is defensible; little here is pure filler.

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 37-parameter destructive mutation with no output schema, the description covers what the annotations cannot: partial overwrite behavior, the blocking condition, currency, and a return-value detail (excess_income_transaction) that would otherwise be invisible. Nothing essential to calling it correctly appears to be 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 92%, so the baseline is 3 and the description only needs to add meaning at the margins — which it does for the receipt/receivable case: linking or re-linking to a receivable for more than is outstanding triggers the split, and the excess lands on a new transaction surfaced in the result. That is real semantic content not derivable from the schema alone, though most individual fields still rely on the schema's own descriptions.

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?

The first clause gives a specific verb, resource and scope: 'Edit an existing security-ledger transaction (trade or income) in place.' The examples (tax statement components, GST treatment, entitlement date, receipt linking, capital gain) make clear what class of edits belong here, and the wording distinguishes it from the create-side siblings record_trade and record_income as well as from update_cash_transaction.

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?

It names the discovery path explicitly — 'Find the row via search_transactions (it gives the id and holding_id)' — and states a hard precondition, 'Blocked if the transaction's financial year is closed or lodged.' What it does not do is route the agent away from siblings (e.g. use record_trade to create a new trade, update_cash_transaction for cash rows), so the when-not side is inferred rather than stated.

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

Deploy Server