Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Update holding

update_holding
Destructive

Edit an existing holding to correct a property or lump-sum asset cost base via purchase_price, or fix metadata such as ticker, name, acquisition date and status; supply only the fields to change.

Instructions

Edit an existing holding's fields — most usefully to correct a property (or other lump-sum asset's) cost base via purchase_price, or to fix metadata such as a ticker, name, exchange, acquisition date, sector or status. Find the holding via list_holdings; only supply the fields you want to change. IMPORTANT: for equities that have a buy/sell trade history, cost base and quantity are derived from the trade ledger, so purchase_price / purchase_price_per_unit / quantity set here are IGNORED for them — adjust the underlying trades with record_trade instead. For property and other quantity-less lump-sum assets, cost base = purchase_price plus any stamp_duty / legal_fees / broker_fee_buy / other_purchase_costs. The edit is audited. Amounts in AUD unless currency says otherwise.

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>"
    },
    "name": "update_holding"
  }
}

Input Schema

NameRequiredDescriptionDefault
hinNoHolder Identification Number
nameNoSecurity/asset name
notesNo
sectorNoSector classification
statusNoHolding status, e.g. "active" or "sold"
fund_idYesFund ID (discover via whoami or list_funds)
currencyNoCurrency code (default "AUD")
exchangeNoExchange, e.g. "ASX"
quantityNoUnits held (ignored for equities with a trade history)
broker_idNoBroker ID (see list_brokers)
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
asset_typeNoAsset type by name or category, e.g. "ETF" or "equity" (see list_asset_types)
face_valueNoFace value in AUD (cost base driver for fixed-income holdings)
holding_idYesHolding to edit (find via list_holdings)
legal_feesNoLegal fees on acquisition in AUD (adds to cost base)
stamp_dutyNoStamp duty on acquisition in AUD (adds to cost base)
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.
ticker_symbolNoTicker, e.g. "VAS"
broker_fee_buyNoAcquisition brokerage in AUD (adds to cost base)
purchase_priceNoTotal purchase price in AUD — drives cost base for property and other lump-sum (quantity-less) assets
share_registryNoShare registry: "computershare", "mufg" (MUFG Corporate Markets, formerly Link Market Services), "automic", "boardroom", "advanced", "xcend" or "other". Left out, it is looked up from the ticker when one is on file.
acquisition_dateNoAcquisition date as an ISO date, e.g. "2026-05-30"
current_price_dateNoDate of the current price as an ISO date, e.g. "2026-05-30"
other_purchase_costsNoOther acquisition costs in AUD (adds to cost base)
current_price_per_unitNoCurrent price per unit in AUD
purchase_price_per_unitNoPurchase price per unit in AUD (ignored for equities with a trade history)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.5/5.0
Behavior4/5

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

The annotations only declare readOnlyHint=false and destructiveHint=true, so the description carries most of the weight and mostly delivers: it discloses that purchase_price/quantity/purchase_price_per_unit are silently IGNORED for trade-history equities, that the edit is audited, and the cost-base formula for lump-sum assets. It stops short of saying whether an overwritten field can be reverted or why destructiveHint is set, which would matter for a mutation with no output schema.

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 purpose, then the IMPORTANT override caveat, then the cost-base formula, then audit/currency notes — a sensible risk-ordered structure. It is dense for its length but every clause carries information; only the repeated restatement of the 'ignored for equities' rule (also in two schema fields) is mild redundancy.

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 26-parameter mutation with no output schema, this covers the hard parts: which fields are no-ops, how cost base composes, audit implications, and currency default. The remaining gap is return/confirmation behaviour and whether omitted fields are preserved or cleared, which the phrase 'only supply the fields you want to change' only implies rather than states.

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 96%, so the baseline is 3, but the description genuinely adds meaning the schema does not: the composite rule that cost base = purchase_price + stamp_duty + legal_fees + broker_fee_buy + other_purchase_costs, and the precedence rule that trade-ledger fields override purchase_price on equities. Those interactions are not inferable from the per-field descriptions alone.

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 ("Edit an existing holding's fields") and immediately narrows scope to the two highest-value uses: correcting cost base and fixing metadata. The final clause naming record_trade for equities with trade history separates it cleanly from both record_trade and create_holding.

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?

Gives explicit routing: find the holding via list_holdings, and do NOT use this for equities with a trade history — use record_trade instead. It also specifies partial-update behaviour ("only supply the fields you want to change"), which tells the agent how to invoke it, not just when.

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