Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Split a cash row into categorised parts

split_cash_transaction

Splits a cash transaction into multiple categorized parts that sum exactly to the original amount, keeping the original row as part 1 and creating new linked rows for the remaining parts.

Instructions

Split one cash row into two or more parts that add up to it exactly, each with its own category — e.g. an ATO credit of $336 that is a $308.73 refund (tax_refund) plus $27.27 interest on overpayment (income_bank_interest, assessable). The original row becomes part 1 (same id, statement links and reconciliation tick); the other parts are new rows on the same date with the same tick, external_ref ":split:". Audit-logged with your reasoning. Refused for a locked year, a row linked to an income transaction, cost or counter-transfer (detach first), a row with a GST amount, or parts that don't sum to the original. Signed amounts like the original (+ in / − out), 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>",
      "bank_account_id": "<bank_account_id>",
      "cash_transaction_id": "<cash_transaction_id>",
      "parts": "<parts>"
    },
    "name": "split_cash_transaction"
  }
}

Input Schema

NameRequiredDescriptionDefault
partsYesThe parts; amounts must sum to the original row's amount
fund_idYesFund ID (discover via whoami or list_funds)
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
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.
bank_account_idYesBank account the cash row is on
cash_transaction_idYesThe cash row to split

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining exactly what happens to the original row (keeps id, statement links, reconciliation tick) and what the new rows look like (same date, same tick, external_ref '<original ref>:split:<n>'), plus audit logging with reasoning. The refusal conditions and sign/currency conventions are disclosed up front, and nothing contradicts readOnlyHint=false / destructiveHint=false.

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?

Front-loads the verb and resource, then the mechanics, then the refusal list — three dense sentences with no filler. The example is long but concrete and materially disambiguates the operation.

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 mutation with no output schema, it covers side effects, refusals and id/ref conventions thoroughly. It does not say what the call returns (e.g. the new part ids needed for follow-up writes), which is the one remaining gap for an agent chaining calls.

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 100%, so the baseline is 3, but the description adds meaning beyond it: amounts inherit the original row's signing convention (+ in / − out) and are in AUD, and the external_ref naming pattern is spelled out. The per-part fields (tax_component, contribution_type, fund_member_id) are not elaborated, which keeps it below a 5.

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 precise verb and resource ('Split one cash row into two or more parts') plus the invariant that parts sum to the original, and the worked ATO example makes the intent unmistakable. It is clearly distinct from siblings like update_cash_transaction, attribute_cash_transaction and detach_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 gives explicit when-not conditions (locked year, row linked to income transaction, cost or counter-transfer, row with GST amount, parts not summing) and points to the required prerequisite ('detach first'). It does not name the detach_cash_transaction sibling outright or contrast itself with attribute_cash_transaction, so routing against all alternatives is not fully closed.

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