Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List 30 June valuations

list_valuations
Read-only

Retrieves every holding a fund held at 30 June with its EOFY valuation for SMSF return item 15, excluding later purchases and including later sales; flags unvalued rows needing record_valuation.

Instructions

List every holding the fund held at a financial year's end date (30 June) with its EOFY valuation — the figure SMSF return item 15 and the statement of financial position use. Holdings bought after 30 June are excluded; ones sold after it are included. Each row has valued:true and the valuation (market_value, quantity, price_per_unit, source, evidence), or valued:false with the estimate the return falls back to and its basis (price_history = last update_price on/before 30 June × units then held; revaluation = last revaluation transaction; current_value = today's value). Every valued:false row keeps return gap G3 open — record one with record_valuation. Also returns unvalued_count and totals (holdings, valued, bank_cash as at 30 June). 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": "list_valuations"
  }
}

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.4/5.0
Behavior5/5

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

Well beyond the readOnlyHint annotation, it discloses the per-row outcome shape (valued:true with market_value, quantity, price_per_unit, source, evidence vs. valued:false with a fallback estimate), the three estimation bases and how each is derived, and the compliance consequence that every unvalued row keeps gap G3 open. It also states the aggregation fields returned (unvalued_count, totals, bank_cash) and the AUD currency.

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 with the core verb and scope, then layers inclusion rules, return shape, and the G3 consequence in a logical order. The parenthetical derivation rules make some sentences dense, but no clause is filler.

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?

With no output schema, the description carries the full burden of explaining return values and does so thoroughly — row-level valued/unvalued structures, estimate bases, counts, totals, and currency. For a two-parameter read tool this leaves nothing an agent needs to call or interpret it.

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 are already documented in the schema, so the baseline is 3. The description does add that financial_year pins to a 30 June year-end and that amounts are AUD, but it adds no format or discovery detail beyond what the schema already says.

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 every holding the fund held at a financial year's end date') with the exact scope (EOFY valuation as at 30 June) and ties it to the downstream consumer (SMSF return item 15, statement of financial position). This clearly separates it from the plain list_holdings sibling.

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?

Gives explicit inclusion/exclusion rules ('Holdings bought after 30 June are excluded; ones sold after it are included') and a clear next step when gaps exist ('record one with record_valuation'). It stops short of naming list_holdings or snapshot_eofy_valuations as the alternative for current or snapshot-scoped data, so the sibling routing is implied rather than stated.

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