Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add a depreciation schedule

create_depreciation_schedule

Add a Div 43 capital works or Div 40 plant and equipment depreciation schedule to a property holding, then calculate the year's depreciation entry for the return.

Instructions

Add a depreciation schedule to a holding (usually a property). Div 43 capital works: cost_base is the construction cost, deducted at 2.5% a year (override with rate) pro-rated from start_date. Div 40 plant & equipment: cost_base is the asset's cost, with effective_life_years (ATO effective life) or an explicit annual rate; prime_cost or diminishing_value. For an asset already part-written-down when tracking starts, set start_date to the first day tracked and opening_adjustable_value to its written-down value then. Run calculate_depreciation afterwards to generate the year's entry for the return.

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>",
      "holding_id": "<holding_id>",
      "division": "<division>",
      "cost_base": "<cost_base>"
    },
    "name": "create_depreciation_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
rateNoAnnual rate actually applied as a fraction, e.g. 0.025 — overrides the life-based rate
methodNoDiv 43 always uses "capital_works" (the default). Div 40: "prime_cost" (cost × days/365 × 100%/life) or "diminishing_value" (opening adjustable value × days/365 × 200%/life). Defaults to prime_cost for div40.
fund_idYesFund ID (discover via whoami or list_funds)
divisionYes"div43" capital works (building/structural, item 12 D1) or "div40" plant & equipment (item 12 E1)
cost_baseYesConstruction cost (Div 43) or asset cost (Div 40), AUD
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
holding_idYesHolding ID (find via list_holdings)
start_dateNoDate construction completed / the asset was first used as an ISO date, e.g. "2026-05-30"
descriptionNoe.g. "Split-system air conditioner"
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.
effective_life_yearsNoEffective life in years (Div 40)
opening_adjustable_valueNoWritten-down value at start_date, AUD (omit for a new asset: defaults to cost_base)

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 declare this is a non-read-only, non-destructive write. The description adds useful behavioral context around division-specific tax treatment, pro-rating, rate overrides, and the next calculation step. It does not discuss permissions, error behavior, or idempotency, although external_ref in the schema covers replay semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded and every sentence contributes domain-specific guidance. It avoids repeating schema text unnecessarily and keeps the most important information, the resource and division split, at the start.

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?

For a 12-parameter tax depreciation tool with no output schema, the description covers the key domain rules needed to invoke it correctly. It is complete on setup and follow-up behavior, though it does not describe the response or mutation edge cases in detail.

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 already 100%, so the baseline is 3. The description still adds meaningful interpretation across parameters by tying cost_base, rate, start_date, effective_life_years, and opening_adjustable_value to Div 43 and Div 40 depreciation mechanics.

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 states a specific verb and resource: adding a depreciation schedule to a holding. It immediately distinguishes Div 43 capital works from Div 40 plant and equipment, so an agent can tell exactly what domain operation this performs.

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 conditions and setup rules for both divisions, including how to handle partly written-down assets and that calculate_depreciation should be run afterwards. It does not explicitly contrast with update_depreciation_schedule or list_depreciation_schedules, so sibling selection guidance is strong but not fully exhaustive.

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