Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Ask the trustees for a document

request_audit_document

Lets an auditor formally request a document from SMSF trustees in writing, setting a 14-day due date under SIS Act s 35C(2) and tracking what remains outstanding.

Instructions

AUDITOR only: ask the trustees in writing for a document (a title search, the representation letter, a statement covering 30 June). They must give it within 14 days (SIS Act s 35C(2)); the due date is set from today. See what is outstanding with list_auditor_requests.

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>",
      "title": "<title>"
    },
    "name": "request_audit_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoDetail: which asset, which period
titleYesWhat you need
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)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds genuinely new behavior: the request is made in writing, trustees are bound by a 14-day statutory deadline under SIS Act s 35C(2), the due date is computed from today, and the tool is restricted to the AUDITOR role. It stops short of saying what is returned or whether the trustees are notified, which is the remaining gap.

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?

Three tight sentences: role restriction and action first, then the statutory deadline, then the sibling pointer. Every clause carries information and nothing is repeated from the schema.

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 six-parameter mutation with no output schema and thin annotations, the description covers role gating, the legal obligation, deadline computation, and the follow-up tool. It would be complete with a note on what the call returns (e.g. request id and computed due date) and whether trustees are notified, but no critical invocation detail is missing.

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%, so every parameter is already documented, including fund_id discovery hints and external_ref replay semantics. The description only adds illustrative document types that map loosely to title/body, and its 'due date is set from today' note corresponds to no parameter at all, so the baseline 3 is appropriate.

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 and resource ('ask the trustees in writing for a document'), names the requesting role (AUDITOR only), and gives concrete examples (title search, representation letter, 30 June statement). It is clearly distinct from list_auditor_requests, which the description explicitly identifies as the read-side counterpart.

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 clear context: use this when an auditor needs a document from the trustees, and points to list_auditor_requests to check what is already outstanding. It does not explicitly distinguish this from record_auditor_request or answer_auditor_request, so the boundary between sibling write tools is left to inference.

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