Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Record an auditor's document request

record_auditor_request

Logs an auditor's written request against a fund's financial year, setting a due date 14 days out. Use it to capture only what the auditor actually asked for, with wording and request date.

Instructions

Record a document the auditor asked for in writing. due_on is set 14 days after requested_on (default today). Record only what the auditor actually asked for.

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

Input Schema

NameRequiredDescriptionDefault
bodyNoThe request's wording or detail
titleYesWhat was asked for, e.g. "Trustee representation letter"
fund_idYesFund ID (discover via whoami or list_funds)
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.
requested_onNoISO date of the written request
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.8/5.0
Behavior4/5

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

Annotations already establish that this is a non-destructive write. The description adds genuinely new behavioral context beyond them: a due_on value is derived 14 days after requested_on, and requested_on defaults to today. It says nothing about permissions or output, but the derived-field disclosure is substantive.

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?

Three short sentences, front-loaded with the core action, followed by the derived-field rule and the scoping constraint. Nothing is wasted and nothing is buried.

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 seven-parameter write tool with no output schema, the description covers purpose, the computed due date, and the content scoping rule. The main omission is any hint about the idempotent-replay behavior or what the call returns, but the essential calling information is present.

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 100%, so all seven parameters are documented in the schema itself. The description adds the requested_on default and the derived due_on relationship, but leaves the high-value external_ref idempotency replay and reasoning fields entirely to the schema, so the baseline of 3 fits.

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 — recording a written document request from an auditor — which is precise enough to act on. It does not, however, distinguish itself from closely named siblings such as answer_auditor_request or request_audit_document, so an agent must infer the boundary from the name alone.

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?

"Record only what the auditor actually asked for" is a real scoping constraint that tells the agent not to embellish the request content. There is no explicit statement of when to choose this tool over the sibling auditor-request tools, so usage is only implied.

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