Beeswax Shares MCP Server

Update ATO transaction

update_ato_transaction

Correct how an ATO statement line is treated by changing its category, adding a note, or setting the reversed line. Amounts, dates and descriptions stay fixed.

Instructions

Correct how an ATO statement line is treated: its category (a person's category survives re-import), a note, or reverses_id — the line a remission or amendment reverses (same account). The amount, dates and description are the ATO's and can't be changed; re-import the statement instead.

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>",
      "ato_account_id": "<ato_account_id>",
      "ato_transaction_id": "<ato_transaction_id>"
    },
    "name": "update_ato_transaction"
  }
}

Input Schema

Name	Required	Description
`note`	No
`fund_id`	Yes	Fund ID (discover via whoami or list_funds)
`category`	No
`reasoning`	No	Why you are making this change — recorded on the audit log entry for this write
`reverses_id`	No	Alpha's id of the line this one reverses
`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.
`ato_account_id`	Yes	ATO account ID (find via list_ato_accounts)
`ato_transaction_id`	Yes	Alpha's id for the line (from list_ato_transactions)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.8.1Nov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare write/non-destructive; the description adds real behavior: category persists across re-import, other fields are immutable, and reverses_id must reference a line on the same account. It does not discuss partial-versus-full update semantics or what the response contains, so it is strong but not exhaustive for a mutation.

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?

Two sentences with no filler, and the mutable-field list is front-loaded before the immutability caveat. The first sentence is dense with parentheticals around category and reverses_id, which slightly slows parsing but carries necessary constraint information.

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 an 8-parameter mutation with no output schema, the description covers the meaningful semantics of the corrective fields and the constraints on reverses_id, while the schema already documents fund_id, ato_account_id, ato_transaction_id and idempotency. Missing are update/partial semantics and confirmation of the returned result, which keeps it below a 5.

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?

With 75% schema coverage the baseline is 3; the description does add meaning by explaining the persistence of category and the same-account constraint on reverses_id that the schema does not state. However it says nothing about note or reasoning semantics, and external_ref idempotency is left entirely 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 (correct how an ATO statement line is treated) and enumerates the exact mutable fields: category, note, reverses_id. The negative scope (amount, dates, description are the ATO's) further pins down what the tool is for, which an agent can distinguish from list_ato_transactions or import_ato_statement.

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?

Explicitly routes the agent away from this tool when the goal is to change amount/date/description, naming the alternative action ('re-import the statement instead'). It also constrains reverses_id to the same account. It stops short of naming sibling tools or stating prerequisites such as the line needing to exist or belong to the given account.

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

Deploy Server