Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Select a sample of transactions to vouch

select_audit_sample
Read-only

Selects a reproducible audit sample from a financial year's ledger rows for vouchering, using a seed, value or random basis, and bank-sourced inclusion so the same sample can be redrawn.

Instructions

A reproducible sample of the year's ledger rows to vouch to documents. By default the population is only rows a person or the trustee's AI assistant entered — rows read from the bank's feed or a statement already carry the bank's record (include_bank_sourced: true samples everything). basis "value" takes the largest half by amount and draws the rest at random; "random" draws them all. The same seed over the same ledger returns the same rows, so record the seed with your working paper. Each row says where it came from, who entered it, and the documents or invoice attached.

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

Input Schema

NameRequiredDescriptionDefault
seedNoAny text; the same seed reproduces the sample
sizeNoRows to select (default 15)
basisNo
fund_idYesFund ID (discover via whoami or list_funds)
financial_yearYesFinancial year — the label "2023-24" or its numeric id (from list_financial_years)
include_bank_sourcedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.0

TDQS

A4/5.0
Behavior4/5

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

Beyond readOnlyHint=true, the description discloses the important default that bank-sourced rows are excluded unless include_bank_sourced is true, and that identical seed plus ledger yields identical rows. It also describes the shape of each returned row (origin, who entered it, attached documents), which matters because no output schema exists. It omits any note on permissions or on what happens when the population is smaller than size.

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 lead sentence front-loads what is sampled, and each following sentence carries a distinct, load-bearing fact (population default, basis semantics, determinism, return shape). The em-dash parentheticals make some sentences dense, but nothing is redundant.

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 a six-parameter read-only sampling tool with no output schema, the description covers population scope, sampling mode, determinism, and return contents. Minor gaps remain around the size ceiling and edge cases (population smaller than requested size), both of which the agent would otherwise have to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage, the description supplies the missing meaning: include_bank_sourced is undocumented in the schema yet its default and effect are explained here, and the basis enum values are defined behaviorally (value = largest half by amount plus random remainder; random = all at random). It also reinforces the seed reproducibility contract that makes the sample auditable.

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 states a specific verb and resource: a reproducible sample of the year's ledger rows to vouch to documents. That is clearly distinguishable from sibling listing/search tools like search_transactions or list_cash_transactions. It stops short of naming an alternative tool, so it is differentiated mainly by implication.

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?

The audience and workflow are strongly implied (audit vouching, record the seed with your working paper), and the basis semantics tell the agent how to pick between value and random. However, there is no explicit statement of when to use this instead of the transaction-listing siblings, nor any when-not-to-use condition.

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