Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Import ATO statement

import_ato_statement

Imports an ATO Online statement CSV or JSON into the correct ATO account, matches already imported lines, and reconciles balances against ATO records.

Instructions

Import an ATO account statement from the ATO Online services portal's Transactions page: the CSV its Download button saves, or the JSON the page returns (TransactionStatements: response.transactionDetail[]). Pass file_path to the saved .csv or .json file, or the text itself as statement_json. Prefer the JSON when the user has it: it links GIC remissions to their charges, so the 30 June position is exact (a position built from the CSV says when it isn't). Idempotent — lines already imported are matched, and a JSON import upgrades lines first imported from the CSV, so re-importing an overlapping range adds nothing. Afterwards Alpha checks its running balance against the ATO's on every line (reconciled: false names the first line that differs) and proposes bank rows for ATO payments and refunds (confirm them with match_ato_payment). A statement for a different ATO account is refused, by its header or, when the CSV has no title lines, by what its lines say (activity statement lines can't go into the income tax account, or income tax lines into the activity statement account); the error names the account it looks like. Imported into the wrong account? Use undo_ato_import.

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

Input Schema

NameRequiredDescriptionDefault
fund_idYesFund ID (discover via whoami or list_funds)
file_pathNoAbsolute path to the saved Download .csv or TransactionStatements .json file
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.
ato_account_idYesATO account ID (find via list_ato_accounts)
statement_jsonNoThe statement's text — the JSON or the Download CSV (instead of file_path)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: it discloses idempotency and line-matching, that a JSON import upgrades CSV-imported lines, that re-importing an overlapping range adds nothing, that the running balance is checked line-by-line with reconciled: false naming the first differing line, and that a statement for a different ATO account is refused with an error naming the detected account. These are exactly the mutation/refusal behaviors an agent needs before writing.

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?

Purpose is front-loaded in the first clause and every sentence carries information — source format, idempotency, reconciliation, refusal, remediation. The downside is a single dense paragraph with chained parentheticals ('a position built from the CSV says when it isn't'), which makes it harder to scan than a few short labeled sentences would.

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 six-parameter write tool with no output schema, the description covers the full lifecycle: accepted input forms, idempotency, post-import reconciliation signaling, downstream proposed bank rows, wrong-account refusal, and the undo path. Nothing material is left to inference.

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; the description adds real value by explaining the file_path/statement_json alternates and the JSON-over-CSV preference with its downstream consequence. It does not explain external_ref replay or reasoning, but those are already fully documented in 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 ('Import an ATO account statement') and pins the exact source ('the CSV its Download button saves, or the JSON the page returns (TransactionStatements: response.transactionDetail[])'). This is clearly distinguishable from siblings like undo_ato_import, match_ato_payment, and list_ato_imports.

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 selection guidance: pass file_path for a saved file or statement_json for text, and 'Prefer the JSON when the user has it' with the concrete reason (GIC remission linkage, exact 30 June position). It also names the follow-up tools (match_ato_payment for proposed bank rows, undo_ato_import for a wrong-account import), so the agent knows both when to use this and what to do next.

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