Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get ATO position

get_ato_position
Read-only

Retrieve an ATO account's position as of a date (default last 30 June), with owed and accrued amounts from processed activity statements, including GIC, penalties, and income-year breakdowns.

Instructions

Where an ATO account stood on a date (default the last 30 June), using every line the ATO has processed to today: owed for periods ended (for the activity statement, the Integrated Client Account balance), broken down into general interest charge, penalties and each income year's periods; and accrued — activity statement amounts for periods ended by the date but not yet due (GST / PAYG instalment payable for the June quarter). GIC remitted after the date nets to nil. Positive = owed to the ATO. These are the figures for the year's balance items.

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

Input Schema

NameRequiredDescriptionDefault
as_atNoPosition date (default the last 30 June) as an ISO date, e.g. "2026-05-30"
fund_idYesFund ID (discover via whoami or list_funds)
ato_account_idYesATO account ID (find via list_ato_accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=true, and the description adds genuinely useful behavioural context: it uses every ATO-processed line up to today, GIC remitted after the as-at date nets to nil, and positive values mean owed to the ATO. That is real added value beyond the annotation. It still says nothing about volume, performance, or failure modes for an account with many transactions.

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?

The intent is front-loaded in the opening clause, which is good. However, the remainder is a single very long sentence dense with parentheticals, semicolons, and dashes, making it hard to parse in one pass; some of the nested asides could be split or trimmed.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does so by defining `owed`, `accrued`, their breakdowns, and the sign convention. Combined with the read-only annotation, that is enough for an agent to interpret results correctly; only pagination or result-size expectations are absent.

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?

Schema description coverage is 100%, so all three parameters are already documented including the as_at default, and the baseline of 3 applies. The description reinforces the default date and explains which periods accrue as at that date, but it adds no parameter-level syntax or format detail beyond 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: it returns where an ATO account stood on a given date, and enumerates the two result components (`owed` and `accrued`). That is clearly distinguishable from a generic tax-position read. It does not, however, say how it differs from nearby siblings such as get_tax_position or list_ato_transactions, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The only usage-like information is the default date behaviour (last 30 June), which implies annual balance-date usage but is not framed as guidance. An agent must derive selection criteria from the sibling names alone.

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