Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Record a 30 June valuation

record_valuation
Destructive

Records or replaces a holding's EOFY valuation in AUD for the return's balance sheet, using market value or unit price plus required evidence.

Instructions

Record (or replace) a holding's EOFY valuation for a financial year — the source of truth for its value on the return's balance sheet; recording one for every holding held at 30 June clears gap G3. Give EXACTLY ONE of market_value (the holding's total value in AUD, e.g. a property valuation, a fund statement's closing balance) or price_per_unit (AUD per unit, e.g. the 30 June market close); with a unit price the quantity is the units held at 30 June computed from the trade ledger, and market_value = price × units. evidence is required: where the figure comes from (statement name and date, valuer, "ASX close 30/6/2025"). Upserts — a second call for the same holding and year overwrites the first. Rejected if the holding wasn't held at 30 June or the financial year is closed/lodged. A price from update_price, even one dated 30 June, does NOT do this — call record_valuation explicitly. Returns the valuation and unvalued_remaining (holdings still unvalued for the year).

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>",
      "holding_id": "<holding_id>",
      "evidence": "<evidence>"
    },
    "name": "record_valuation"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoAny further note
sourceNo"statement" (issuer/registry/fund statement), "yahoo" (market close), "manual" (default)
fund_idYesFund ID (discover via whoami or list_funds)
evidenceYesWhere the figure comes from — kept for the auditor
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
holding_idYesHolding to value (from list_valuations or list_holdings)
price_dateNoDate the unit price is from (default the year end) as an ISO date, e.g. "2026-05-30"
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.
market_valueNoTotal value of the holding at 30 June, AUD
financial_yearYesFinancial year — the label "2023-24" or its numeric id (from list_financial_years)
price_per_unitNoPrice per unit at 30 June, AUD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations by disclosing upsert-overwrite semantics, the recomputation of units from the trade ledger, two distinct rejection paths, and the return payload (valuation plus unvalued_remaining). The destructive annotation is corroborated rather than merely restated.

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 purpose and the key routing warning, and nearly every clause carries information. It is a single very dense paragraph, so the constraint and rejection clauses are harder to scan than a short bulleted structure would be.

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 an 11-parameter write tool with no output schema, the description covers what an agent needs: input either/or rule, overwrite behavior, failure conditions, the sibling trap, and what comes back. 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds genuine meaning the schema cannot: the mutually exclusive choice between market_value and price_per_unit, the derivation market_value = price × units with units taken at 30 June, and why evidence must be concrete ('statement name and date, valuer, ASX close 30/6/2025').

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?

Opens with a specific verb+resource+scope ('Record (or replace) a holding's EOFY valuation for a financial year'), states what it feeds ('source of truth for the return's balance sheet') and ties to a concrete gap (G3). It also distinguishes itself from the nearest-sounding sibling, update_price, which an agent would otherwise confuse.

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?

Names the exact alternative that looks equivalent ('a price from update_price ... does NOT do this — call record_valuation explicitly') and gives explicit exclusion conditions (holding not held at 30 June, year closed/lodged). The either/or rule for market_value vs price_per_unit is stated as a hard constraint.

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