Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Sign off a line of the audit program

sign_off_audit_line

Record an auditor's sign-off on a single audit program line, marking it reviewed or exception with supporting notes. Confirms the conclusion only after the user explicitly approves.

Instructions

Record the AUDITOR's sign-off on one line: status "reviewed" (the evidence supports it) or "exception" (it doesn't — a note is required). Only a token belonging to the fund's auditor can. The sign-off is the auditor's conclusion, not yours: show them the line, its figure, what you tested against which document, and the note, and call this only after an explicit yes, with confirmed_by_user: true. Put what was tested in note (it becomes the working paper for the line). Recorded as signed via their assistant.

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>",
      "line_key": "<line_key>",
      "status": "<status>",
      "confirmed_by_user": "<confirmed_by_user>"
    },
    "name": "sign_off_audit_line"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoWhat was tested and found; required for an exception
statusYes
fund_idYesFund ID (discover via whoami or list_funds)
line_keyYesA 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)
confirmed_by_userYestrue only after the auditor has said yes to this line

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.0

TDQS

A4.3/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 genuinely new behavioral facts — the call requires a token belonging to the fund's auditor, the note becomes the working paper for the line, and the action is attributed as signed via their assistant. It does not say whether an existing sign-off can be overwritten or what the response contains, which keeps it off a 5.

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?

Front-loaded with the action and the two allowed statuses, then the permission constraint, then the consent gate. Dense but every sentence carries operational weight; the "not yours" framing and the show-them-the-line instruction are useful rather than padding.

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 an 8-parameter write tool with no output schema, the description covers authorization, consent gating, status semantics and note content, which is most of what an agent needs. The main omission is what the call returns or how to confirm the sign-off landed.

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 88%, so the baseline is 3, but the description adds meaning the schema does not: "reviewed" means the evidence supports the line, "exception" means it does not and requires a note, and note is characterized as the working paper. It also reinforces confirmed_by_user as an explicit-consent gate rather than a mere boolean.

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 — record the auditor's sign-off on one audit program line — and enumerates the only two outcomes, "reviewed" and "exception". An agent can distinguish this write tool from read siblings like get_audit_line or get_audit_program without opening a schema.

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 a strong, explicit precondition: call this only after the auditor has said yes, with confirmed_by_user: true, and after showing them the line, figure, test basis and note. It does not name a sibling alternative (e.g. raising a query via raise_audit_query instead of signing off with an exception), so it stops short of full when/when-not routing.

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