Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

List ATO transactions

list_ato_transactions
Read-only

Retrieve an ATO account's statement lines newest first, showing running balances and optional per-period breakdowns, filtered by category, match status, or processed date range.

Instructions

List an ATO account's statement lines, newest first, each with the ATO's running balance and Alpha's beside it. By default only the lines that carry the balance (parents and single lines); pass include_children to add the per-period breakdown (GST, PAYG instalment, GIC lines). Amounts: positive = DR (owed to the ATO), negative = CR. Filter by category (activity_statement_raised, income_tax_assessed, payment, refund, general_interest_charge, penalty, remission, interest_on_overpayment, transfer_between_ato_accounts, other), match_status or processed-date range.

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": "list_ato_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLatest processed date (inclusive) as an ISO date, e.g. "2026-05-30"
fromNoEarliest processed date (inclusive) as an ISO date, e.g. "2026-05-30"
pageNoPage number (default 1)
fund_idYesFund ID (discover via whoami or list_funds)
categoryNoFilter by category
per_pageNoResults per page (default 25, max 100)
match_statusNoBank match status (payments and refunds)
ato_account_idYesATO account ID (find via list_ato_accounts)
include_childrenNoAlso list the breakdown lines under each parent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover readOnlyHint=true, so the safety profile is handled. The description adds real behavioral context beyond that: ordering (newest first), the balance-comparison semantics, and the DR/CR sign convention (positive = owed to ATO). No pagination or error behavior is described, keeping it just short of a 5.

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 and dense with zero filler, but the sentences are long and run-on, packing amount sign conventions and filter lists into single clauses. Efficient and useful, slightly heavy to parse.

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 9-parameter read-only list tool with no output schema, the description supplies ordering, default filtering, breakdown behavior, sign conventions, and filter options. An agent has everything needed to call it and interpret the result correctly.

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 further by enumerating the category values that the schema leaves as a bare string, and by clarifying what include_children actually adds. This meaningfully extends the structured field text.

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 ('List an ATO account's statement lines') and pins down scope: newest-first, running balance alongside Alpha's. It is clearly distinct from sibling read tools like list_ato_accounts and get_ato_position without needing to name them.

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?

Explains the default behavior (only balance-carrying parents and single lines) and the exact condition for the alternative (pass include_children to add GST/PAYG/GIC breakdowns). It also lists the available filters. It does not route against sibling tools explicitly, but for this list tool the when-to-use framing is clear.

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