Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Allocate the year's earnings to members

allocate_earnings
Destructive

Allocates a fund's yearly net earnings across member statements using opening or average daily balance weighting, writing each member's share and rolling closing balances forward.

Instructions

Apportion the fund's net earnings for the year across the members' statements (allocated earnings, label O), overwriting each statement's current figure; computed closing balances roll forward. method "opening_balance" weights by opening balance; "average_daily_balance" (what trustee minutes usually specify) weights the opening balance for the full year plus each dated contribution, rollover or benefit payment for the days remaining after it. Dated flows come from cash transactions attributed to the member; a member whose statement shows flows with none dated falls back to the opening balance and the response says so (per member: method_used, weight, share, note). Shares sum exactly to the total (the rounding cent goes to the largest member). Omit total_earnings to use the net-assets roll-forward: net assets at 30 June less each member's opening balance and non-earnings movements (contributions, rollovers, benefits, contributions tax), so closing balances equal net assets; it includes unrealised movements and tax. The response's earnings_figures gives that figure, the operating statement's (benefits accrued after tax − contributions + contributions tax) and the difference between them. Use dry_run to preview. Members with no statement get no share — create their statements first. 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": "allocate_earnings"
  }
}

Input Schema

NameRequiredDescriptionDefault
methodNoWeighting (default "opening_balance")
dry_runNoPreview the split without writing
fund_idYesFund ID (discover via whoami or list_funds)
reasoningNoWhy you are making this change — recorded on the audit log entry for this write
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.
financial_yearYesFinancial year — the label "2023-24" or its numeric id (from list_financial_years)
total_earningsNoNet earnings to allocate, AUD (negative for a loss). Omit to derive from the financial statements

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 destructiveHint=true, and the description justifies it precisely: existing allocated-earnings figures are overwritten and closing balances roll forward. It also discloses the fallback for undated flows, the rounding rule (cent to the largest member), and what the response reports per member. It does not cover permissions or whether the overwrite is reversible, so not quite a 5.

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 effect, then method semantics, then the derivation alternative and caveats. Dense and jargon-heavy with no visual structure, but for a tool with this much computational nuance nearly every clause carries decision-relevant information.

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?

There is no output schema, so the description carries the return-value burden itself, and it does: per-member method_used, weight, share and note, plus the earnings_figures comparison of the derived figure, the operating statement figure, and their difference. Combined with the overwrite warning and precondition about missing statements, an agent has what it needs to invoke this safely.

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 100%, so the baseline is 3; the description earns above baseline by explaining what 'method' actually computes (full-year opening balance plus day-weighted dated flows), when a fallback to opening balance kicks in, and what omitting total_earnings derives instead. It adds no meaning for reasoning and external_ref, but those are already self-documenting in the schema.

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 (apportion/allocate) and the exact resource affected: member statements' allocated earnings figure (label O). The opening clause 'overwriting each statement's current figure' immediately distinguishes this bulk-computation write from the sibling update_member_statement, so an agent can route correctly without opening either schema.

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 concrete operating guidance: use dry_run to preview, omit total_earnings to derive from the net-assets roll-forward, and create member statements first because members with no statement get no share. It also flags that trustee minutes usually specify average_daily_balance. It stops short of an explicit 'do not use this when…' exclusion against siblings, but the preconditions are clear enough to act on.

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