Beeswax Shares MCP Server

Expenses' GST vs BAS credits, and a bulk GST fix

set_expense_gst_treatment

Sets the GST treatment on a year's expense rows after comparing GST paid against the net GST on activity statements. Previews each row change by default; apply only after user approval.

Instructions

Compare a year's GST with the activity statements — per period, GST collected on rent − GST paid in the expense rows (magnitudes) against the net GST raised on the imported 001 account — and set the GST treatment on the year's expense rows in one go. dry_run (default true) changes nothing: it lists each row it would change (gst_treatment, GST and expense_amount before → after), the ledger GST after the change against credits_claimed, and the expense change. Without cash_transaction_ids it takes every gst_free expense row with no gst_amount in a category that carries GST (not bank fees, ASIC fees, interest or insurance) — or the categories given; rows matched to a security/income transaction are never changed (their GST is on that transaction). Show the preview to the user and apply (dry_run: false) only when they say so. The expenses_gst_treatment check reports the same comparison.

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

Input Schema

Name	Required	Description
`dry_run`	No	Default true: preview only
`fund_id`	Yes	Fund ID (discover via whoami or list_funds)
`reasoning`	No	Why you are making this change — recorded on the audit log entry for this write
`categories`	No	Only gst_free rows in these expense categories, e.g. ["expense_accounting", "expense_audit"]
`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.
`gst_treatment`	No	Treatment to set (default gst_inclusive)
`financial_year`	Yes	Financial year — the label "2023-24" or its numeric id (from list_financial_years)
`cash_transaction_ids`	No	Only these expense rows

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.14.0Nov 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only tell the agent this is a non-read-only, non-destructive write; the description adds far more — default dry-run changes nothing, the preview itemizes before→after per row plus ledger GST against credits_claimed, and excluded rows (bank fees, ASIC fees, interest, insurance, security/income-matched rows) are enumerated. This is exactly the behavioural context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

No filler sentences, but the text is a dense run-on with nested parentheticals and an embedded subtraction formula, which slows parsing of the most important points. The confirmation instruction arrives late rather than being front-loaded.

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, 2-required bulk mutation with no output schema, the description covers defaults, selection scope, exclusions, preview contents and the apply gate. It does not state what the tool returns on an actual write, nor any permission or reversibility constraints, leaving a small gap.

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 goes beyond field definitions by explaining what happens when cash_transaction_ids and categories are absent — the default population of gst_free rows without a gst_amount, minus excluded categories. It adds selection semantics rather than merely restating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: set the GST treatment on the year's expense rows in bulk, and compare ledger GST against activity statements. It distinguishes itself from siblings like update_cash_transaction by noting that rows matched to a security/income transaction are never touched. The title's dual framing (comparison + fix) makes it slightly less crisp than a pure single-purpose statement.

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?

Explicit when-to-use and when-not-to-use: dry_run defaults to true, the preview must be shown to the user, and the write happens only on explicit user confirmation. It also names an alternative (the expenses_gst_treatment check reports the same comparison) and defines the default selection scope when cash_transaction_ids and categories are omitted.

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

Deploy Server