Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Record the year-end trustee meeting

update_trustee_minutes

Sets year-end trustee minutes, including meeting details, attendance, absentees with reasons, and standard or custom resolutions; only supplied fields change and locked or finalised years are refused.

Instructions

Set the year-end trustee minutes: meeting date, place, chair, who was present and who was absent (with a reason), optional standard resolutions and custom resolutions. Only what you pass changes. Only directors present sign the minutes, and they are the default signatories of the trustees' declaration and representation letter. The contributions resolution is written from the year's actual contributions (none → "no contributions were received"). Standard resolutions: directors_overseas (names the absent directors), cmc_australia (central management and control in Australia, by those present), no_non_resident_contributions, events_after_year_end (uses the notes' subsequent events), late_lodgments (with late_lodgments_detail). Refused for a locked year or finalised minutes.

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": "update_trustee_minutes"
  }
}

Input Schema

NameRequiredDescriptionDefault
chairNoChair's name (defaults to the first director present)
absentNoDirectors/trustees absent, with the reason (e.g. "resident overseas since 2023")
fund_idYesFund ID (discover via whoami or list_funds)
presentNoNames of directors/trustees present
locationNoWhere the meeting was held
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.
meeting_dateNoISO date, e.g. 2026-11-10
financial_yearYesFinancial year — the label "2023-24" or its numeric id (from list_financial_years)
custom_resolutionsNoExtra resolutions, each starting "That …" (replaces the current list)
standard_resolutionsNoStandard resolutions to include (replaces the current selection)
late_lodgments_detailNoWhat was lodged late, for the late_lodgments resolution

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say it is a non-destructive write; the description goes much further, disclosing partial-update semantics, that custom and standard resolution lists are replaced wholesale, and the two hard refusal conditions (locked year, finalised minutes). It also explains derived behaviour — the contributions resolution is generated from actual contributions, falling back to 'no contributions were received' when there are none.

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 scope and the field list, then ordered into mutation semantics, signatory rule, then the resolution catalogue. It is dense and some sentences pack several clauses, but no sentence is filler and the alternative would be losing genuinely useful detail.

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 mutation with no output schema and only minimal annotations, this covers most of what an agent needs: what changes, what is replaced, what is derived, and when the call is rejected. The remaining gap is the response shape — whether the saved minutes are echoed back — which is left unstated.

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, but the description adds real meaning beyond it: chair defaults to the first director present, absentees require a reason, and each standard resolution enum value is annotated with its effect (directors_overseas names absent directors, cmc_australia is by those present, events_after_year_end pulls the notes' subsequent events). It does not elaborate on reasoning, external_ref, or fund_id, which the schema already handles.

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 — 'Set the year-end trustee minutes' — and immediately enumerates the fields it governs (meeting date, place, chair, present/absent, resolutions). No sibling tool covers trustee minutes, and an agent can tell exactly what this writes without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful operating conditions — 'Only what you pass changes' and 'Refused for a locked year or finalised minutes' — which effectively tell the agent when NOT to use it. However, it never states when this tool is required versus other year-end steps (close_financial_year, update_pack_signatories), so the workflow placement is left implicit.

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