Skip to main content
Glama
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau

Answer an audit query

answer_audit_query

Answer open audit queries for trustees or accountants by stating the figure, its source, and the supporting document so auditors can close or follow up; upload missing documents first.

Instructions

TRUSTEE or accountant only: answer an open audit query. Say what the figure is, where it comes from, and name the document that shows it (upload it with upload_document first if it isn't on file). The auditor then closes the query or follows up.

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>",
      "query_id": "<query_id>",
      "body": "<body>"
    },
    "name": "answer_audit_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYes
fund_idYesFund ID (discover via whoami or list_funds)
query_idYes
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 declare readOnly=false and destructive=false; the description adds real context beyond that — the permission gate, the expected composition of the answer, and the downstream consequence (the auditor closes or follows up). It does not say what state the query is left in or what a successful response looks like, which is the main 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 with the access restriction front-loaded, then the required content, then the outcome. The parenthetical about upload_document earns its place by preventing a failed call. No filler.

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?

For a 6-parameter write tool with no output schema, the description covers audience, precondition, answer content, prerequisite upload, and post-call consequence. An agent has everything needed to invoke it correctly without guessing.

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?

With 67% schema coverage, the description compensates by defining what belongs in the undocumented body field: the figure, its source, and the identifying document. It also ties documentation to upload_document. It adds nothing for reasoning or external_ref, but those are already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource: 'answer an open audit query', with an explicit audience restriction (TRUSTEE or accountant only). An agent can tell what the tool does at a glance, though it never states how it differs from a similarly-named sibling such as reply_audit_query or answer_auditor_request.

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?

Clear preconditions: the query must be open and the caller must be a trustee or accountant. It also routes the agent to upload_document when the supporting document isn't on file, and notes that the auditor closes the query afterwards, implicitly steering away from a close-type tool. No explicit 'do not use when' clause, but coverage is strong.

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