Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Open one line of the audit program

get_audit_line
Read-only

Retrieve all facts, workings, checks, source documents, and queries for one audit program line so you can verify reported figures against supporting evidence.

Instructions

Everything behind one line of the audit program: the facts (for a bank account: opening, ledger and the bank's own balance, what proves it, lines ticked, statement gaps; for an investment: units, cost, market value, the price used and where it came from), the working as tables (the bank's balances against the ledger, rows not read from the bank, movements in the year, the operating statement's rows), the checks that test it with any note a person accepted them with, the source documents on file (documents — read one with download_document; covers_year_end marks the statement covering 30 June) and the queries raised on it. Compare the document with the figure yourself: Alpha's figure is the claim, the document is the evidence.

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

Input Schema

NameRequiredDescriptionDefault
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"
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?

The readOnlyHint annotation already establishes that this is a non-destructive read, so the description's lower bar is met. It does add real behavioral context not present in the annotations: documents are listed but must be downloaded separately with download_document, checks carry acceptance notes from a person, and the reader must do the claim-versus-evidence comparison themselves. It says nothing about pagination or size limits, which could matter for a line with many documents, checks, and queries.

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?

The description is front-loaded: it opens with the resource and scope before enumerating contents, so an agent gets the point on the first clause. The rest is a single dense sentence with nested parentheticals, which is readable but hard to scan and could have been split by content category for clarity without adding length.

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?

There is no output schema, so the description correctly assumes responsibility for describing return values, and it does so thoroughly across facts, tables, checks, documents, and queries. It does not cover failure modes, such as a line_key that does not exist for the given fund or year, and it does not address response size for lines with many documents or queries. For a single-record read tool this is adequate but not fully 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 100%, so all three parameters are already documented in the schema itself, including the line_key example format ("bank.4") and discovery via whoami, list_funds, and list_financial_years. The description adds context on what the returned content looks like, but adds nothing about parameter syntax or edge cases beyond what the schema states. With the schema doing the heavy lifting, baseline 3 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 lead clause, "Everything behind one line of the audit program," names a specific resource and scope, and it enumerates the categories of content returned: facts, working tables, checks, documents, and queries. The word "one" implicitly distinguishes it from get_audit_program, which returns the whole program, though that sibling is never named outright. This is clear enough for an agent to distinguish this tool from list-style siblings, but it falls short of an explicit contrast with get_audit_program's whole-program behavior.

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?

The description states the intended workflow well: read a source document with download_document, and independently compare the figure (the claim) with the document (the evidence). It also explains covers_year_end as a marker for the statement covering 30 June, which helps the agent interpret results correctly. It does not explicitly say when to use this tool instead of get_audit_program, or that sign_off, raise_audit_query, or answer_audit_query are alternatives once a line has been opened.

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