Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get the year's tax position

get_tax_position
Read-only

Retrieve a financial year's tax position details—including prior year capital losses, tax losses, PAYGI instalments, and TFN withholding—to feed the return's losses schedule and calculation statement.

Instructions

Read a financial year's tax position — the facts the ledger can't derive that feed the return's losses schedule and calculation statement: prior_year_capital_loss_bf, net_capital_loss_cf, tax_losses_bf, paygi_instalments_raised (item 13 K), supervisory_levy (L), tfn_withholding_credit (H), no_tfn_contributions_tax (J), ecpi_method and actuarial_percentage. recorded:false means none is saved yet (the review's tax_position_recorded check stays red). Amounts in 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>",
      "financial_year": "<financial_year>"
    },
    "name": "get_tax_position"
  }
}

Input Schema

NameRequiredDescriptionDefault
fund_idYesFund ID (discover via whoami or list_funds)
financial_yearYesFinancial year — the label "2023-24" or its numeric id (from list_financial_years)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.2/5.0
Behavior4/5

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

With readOnlyHint already covering safety, the description adds genuine behavioral context: the recorded:false empty state and its effect on the review check, plus the note that amounts are in AUD. It does not discuss behavior for foreign or closed/lodged years, so it is strong but not exhaustive.

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?

It is a single front-loaded sentence with no wasted framing, moving from verb to purpose to the returned field list to the empty-state caveat. The middle section is a dense run of domain abbreviations (paygi, ecpi_method, tfn_withholding_credit) that is justified only because there is no output schema.

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 two-param read tool with no output schema, the description compensates by naming every returned field and the currency and the no-record state. An agent has enough to call it and interpret the result without further exploration.

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 coverage is 100%, and both parameters already carry discovery hints (whoami/list_funds, list_financial_years) in the schema. The description adds no meaning about fund_id or financial_year itself, so it sits at the baseline where the schema does the work.

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?

The description opens with a specific verb and resource ("Read a financial year's tax position") and then enumerates the exact fields returned, so it is distinguishable from update_tax_position and get_ato_position without opening either schema. It also frames the scope as "the facts the ledger can't derive," which sharpens what data this resource owns.

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 clear context for when to reach for this tool — populating the return's losses schedule and calculation statement — and explains the recorded:false outcome in terms of the tax_position_recorded review check. It never explicitly names the alternative (update_tax_position) or states exclusions, so it stops short of full routing guidance.

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