Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Link an expense payment to a prior-year creditor

settle_prior_year_creditor

Mark an expense payment as settling a prior-year creditor liability so the current operating statement and return deductions exclude it, without an H1/J1 override.

Instructions

Say that an expense payment settles a creditor carried on an earlier year's balance sheet (a liability balance item, e.g. FY24 "Sundry creditors" for accounting and audit fees paid in FY25). That part was the earlier year's expense, so the operating statement and the return's deductions leave it out — no H1/J1 override needed. amount defaults to what is still owed on the creditor, capped at the payment; several payments can settle one creditor. fund_balance_item_id null unlinks. The result gives the row's expense_amount before → after and what is still owed. Blocked if the payment's year is closed or lodged.

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>",
      "bank_account_id": "<bank_account_id>",
      "cash_transaction_id": "<cash_transaction_id>",
      "fund_balance_item_id": "<fund_balance_item_id>"
    },
    "name": "settle_prior_year_creditor"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountNoPart of the payment that settles it (default: what is still owed)
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.
bank_account_idYesBank account ID (find via list_bank_accounts)
cash_transaction_idYesThe expense payment (from list_cash_transactions)
fund_balance_item_idYesThe prior-year liability it settles (list_balance_items), or null to unlink

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.14.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, non-destructive write. The description adds substantial behavior: amount defaults to the outstanding balance and is capped at the payment, multiple payments can settle one creditor, passing null for fund_balance_item_id unlinks, the response reports expense_amount before → after and the remaining owed, and the call is blocked when the payment's year is closed or lodged. That is exactly the extra context the annotations cannot carry.

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 core semantics, then defaults, then unlinking, then return value and blocking conditions — a logical order with little waste. The dense accounting phrasing (H1/J1 override) is domain-relevant rather than padding, though the sentence is long and could be split.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation with no output schema, it covers preconditions (year not closed/lodged), parameter defaults and caps, reversibility via null, and even the shape of the returned numbers. Nothing an agent needs to invoke it correctly appears missing.

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 100%, so the baseline is 3, but the description earns more: it explains the default and cap semantics of 'amount', the multi-payment relationship, and the null-unlink meaning of the required-but-nullable fund_balance_item_id. It does not cover the reasoning/external_ref idempotency params, but those are already well documented in the schema.

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 precise verb and resource: it marks an expense payment as settling a liability carried on an earlier year's balance sheet, with a concrete example (FY24 'Sundry creditors' paid in FY25). This scope is clearly distinguishable from mutation siblings like attribute_cash_transaction or update_cash_transaction, which deal with the current year.

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 when-to-use condition is explicit (the payment settles a prior-year creditor) and it clarifies the accounting consequence ('the operating statement and the return's deductions leave it out — no H1/J1 override needed'), which tells the agent not to reach for an override mechanism. It stops short of naming a sibling as the alternative for current-year expenses, so it is clear context rather than 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