Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Raise an audit query

raise_audit_query

Raise an audit query for the trustee to answer, tied to a specific audit program line or to the whole financial year, stating what does not agree and what evidence would settle it.

Instructions

AUDITOR only: raise a query for the trustee to answer. Pass line_key to put it on a line of the audit program (it shows on that line), or leave it out for a query about the year as a whole. Say what doesn't agree and what would settle it. For a document you need, use request_audit_document instead: that starts the 14-day clock.

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

Input Schema

NameRequiredDescriptionDefault
bodyNoWhat you found and what would settle it
titleYesThe question in one line
fund_idYesFund ID (discover via whoami or list_funds)
line_keyNoA program line's key from get_audit_program, e.g. "bank.4", "holding.12", "partb.s62", "tie.net_assets"
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.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the meaningful extra that this is an AUDITOR-role-gated write aimed at the trustee and that line placement changes where the query appears. It stops short of saying who is notified, how the query surfaces in list_audit_queries, or whether it can be withdrawn — though idempotency and audit-log recording are already covered by the schema.

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?

Four short sentences, front-loaded with the role restriction, then placement semantics, then the sibling alternative. Every sentence carries a distinct instruction and nothing is repeated.

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?

With seven parameters, a 100%-covered schema, and minimal annotations, the description supplies the role gate, placement semantics, and the key alternative route. What is missing is lifecycle context — what happens to the query after it is raised and how the trustee sees it — but that is a modest gap given the schema carries the mechanics.

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 still adds meaning by explaining the omitted-line_key case (a query about the year as a whole), which the schema leaves unstated. The body guidance ("say what doesn't agree and what would settle it") largely restates the schema's own body description.

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 ("raise a query") plus the actor and audience ("AUDITOR only ... for the trustee to answer"). It also names the sibling it is not (request_audit_document), so the agent can distinguish it from adjacent tools without inspecting schemas.

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?

Gives an explicit branch: pass line_key to attach the query to a program line, or omit it for a year-wide query, with the consequence of each choice ("it shows on that line"). It also routes the document case to request_audit_document with a concrete reason (the 14-day clock).

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