Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get the year's audit program

get_audit_program
Read-only

Retrieve the SMSF audit program for a fund’s financial year to guide audit stages, review each line’s status and evidence gaps, and open lines for detail.

Instructions

The audit program for a fund's financial year — START HERE when auditing. Stages in the order an SMSF audit runs: engage (auditor, how the ledger was built), fund (permanent records, the year's signed documents, last year's audit), plan (figures frozen, a materiality guide, year-on-year movements, large transactions, checks a person accepted), part_a (statements tie out, each bank account, each investment, other balances, the operating statement and its tests), part_b (each SIS section and regulation the audit report covers) and conclude. Each line has a key, state (ready = supported, attention, blocking, na, info = a fact to read, manual = no test in Alpha: the auditor's own procedure, described in procedure), figure, proven_by, evidence_gap (a source document an auditor expects that isn't on file) and its signoff. Also returns ledger_sources (how many of the year's rows came from the bank feed, a statement, the trustee's AI assistant, or were typed), the open queries, and role (your role on the fund). Open a line with get_audit_line.

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

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.17.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds substantial behavior beyond that: the ordered stage model, the meaning of each line state (ready/attention/blocking/na/info/manual), what evidence_gap represents, and the presence of ledger_sources, open queries and role in the payload. It does not discuss pagination, payload size, or what happens for a year with no audit program, which keeps it short of a 5 for this complexity.

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?

Purpose and the 'start here' directive come first, followed by stage and field detail, so it is well front-loaded with zero filler sentences. The stage and field enumerations are dense comma-run lists that are harder to scan than a short bulleted structure would be, which costs it a point.

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 describing the returned structure is the description's job, and it does so thoroughly: line keys and their states, figure/proven_by/evidence_gap/signoff, plus the ledger_sources, open queries and role companions. Combined with the explicit hand-off to get_audit_line, an agent has everything needed to call this and interpret the response.

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 description coverage is 100% and both parameters (fund_id, financial_year) are documented there, including the discovery path via whoami/list_funds and the '2023-24' vs numeric id formats. The description only echoes 'a fund's financial year' and adds no syntax or edge-case meaning, so the schema does the heavy lifting — baseline 3.

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 resource and scope — 'The audit program for a fund's financial year' — and immediately differentiates itself from siblings with 'START HERE when auditing' followed by 'Open a line with get_audit_line.' An agent can tell this is the entry point and that get_audit_line is the drill-down, without inspecting 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 Guidelines5/5

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

Explicit use guidance is front-loaded ('START HERE when auditing') and the alternative is named with the condition that selects it ('Open a line with get_audit_line'). It also implies ordering through the enumerated stages, so the agent knows this is the first call in an audit workflow rather than a detail call.

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