Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Close an audit query

close_audit_query

Close an audit query once the auditor confirms the answer is satisfactory, recording what the answer says and what it was checked against.

Instructions

AUDITOR only: close a query once its answer satisfies the auditor. Their call: tell them what the answer says and what you checked it against, and close it when they agree.

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

Input Schema

NameRequiredDescriptionDefault
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.6/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write nature is already known; the description usefully adds that the action is approval-gated by a human auditor and requires the agent to present evidence first. It does not say whether closing is reversible, whether the query can be reopened, or what state the query enters afterward, so meaningful behavioral gaps remain for a state-changing call.

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?

Two sentences, front-loaded with the hard role restriction and then the workflow condition, with no padding. The clause "Their call:" is slightly informal and makes the second sentence read awkwardly, but nothing is redundant.

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 5-parameter mutation with no output schema, the definition covers who may call it and the precondition for calling it, which is the essential core. It leaves out what closing does downstream (locking the query, effects on the audit trail, error cases such as closing an unanswered query), so it is adequate rather than complete.

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 80%, and the schema already documents fund_id discovery, reasoning logging, external_ref idempotency, and the financial_year label format. The description adds no parameter-level meaning at all, so the baseline of 3 for high-coverage schemas applies.

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 names a specific verb and resource ("close a query") and scopes the actor with "AUDITOR only", which distinguishes it from the answer/reply/raise siblings in the audit-query family. It stops short of explicitly contrasting itself with those siblings, but the role gate plus the state transition is clear enough for an agent to pick it out.

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?

It gives a concrete triggering condition: close only once the answer satisfies the auditor and the auditor agrees. It also describes a preparatory step ("tell them what the answer says and what you checked it against"), which is real when-to-use guidance. No explicit when-not-to-use or named alternative is provided, keeping it out of the top band.

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