Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Reply on an audit query

reply_audit_query

Adds a message to an audit query thread for a fund and financial year, letting auditors or trustees respond. An auditor reply to an answered query returns it to the trustee.

Instructions

Add a message to an audit query's thread, from either side. A reply from the auditor on an answered query puts it back with the trustee.

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": "reply_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

A3.7/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive write, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond the annotations: an auditor's reply on an answered query returns the query to the trustee, i.e. it mutates query status. It does not discuss permissions or what the reply returns.

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?

Two short sentences, zero filler, with the core action stated first and the state-transition caveat second. Nothing could be cut without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with annotations and a reasonably documented schema but no output schema, the description covers the main effect but omits what a successful reply returns and how it relates to answer_audit_query and close_audit_query. An agent would still need to guess at sibling routing.

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 coverage is 67%, with fund_id, financial_year, reasoning and external_ref already documented inline (including idempotent replay via external_ref). The description adds no meaning for query_id or body and does not explain how body differs from reasoning, so it leaves the two undocumented parameters to inference.

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?

The description gives a specific verb and resource — add a message to an audit query's thread — and clarifies that either party (auditor or trustee) can post to it. It is clear what the tool does, though it never names distinction from the closest sibling, answer_audit_query, which an agent could easily confuse with replying.

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?

Usage is implied rather than stated: you use it to post a message into an existing query thread, and the note about an auditor reply re-opening an answered query hints at a real workflow. There is no explicit 'use this instead of answer_audit_query/close_audit_query' routing or statement of prerequisites beyond the required parameters.

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