Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Undo ATO import

undo_ato_import
Destructive

Undo an ATO statement import by deleting only the lines it created and restoring the account’s prior opening balance and date; preview changes first with a dry run.

Instructions

DESTRUCTIVE: take an ATO statement import back out of its account — deletes every line that import created and puts back the opening balance and date it replaced. Lines it only updated or found unchanged, and lines typed in by hand, stay. dry_run defaults to true: it returns the preview (lines removed, their processed-date range, the balance and opening balance before and after, blockers) and writes nothing. Show the user the preview and get their go-ahead before calling again with dry_run: false. Refused (blockers) when a line it created is matched to a bank row (unmatch it first with match_ato_payment), when a financial year it touches is closed or lodged, or when a later import covers the same lines (undo that one first). Audit-logged with your reasoning and the removed lines.

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>",
      "ato_account_id": "<ato_account_id>",
      "import_id": "<import_id>"
    },
    "name": "undo_ato_import"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNotrue (default): preview only, nothing written
fund_idYesFund ID (discover via whoami or list_funds)
import_idYesThe import to undo (from list_ato_imports)
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.
ato_account_idYesATO account ID (find via list_ato_accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.14.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, so the description goes well beyond them: it enumerates exactly which rows are deleted versus preserved, states that the replaced opening balance and date are restored, lists the three blocker conditions, and discloses that the write is audit-logged with the agent's reasoning and removed lines. It also explains that the preview is non-writing, which is the key safety fact for a destructive tool.

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 DESTRUCTIVE warning and tightly written, with almost every clause carrying operational information. It is a single dense block, though — the workflow, refusal, and audit-log points would scan faster as separated clauses — which keeps it just short of ideal.

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 destructive, six-parameter tool with no output schema, the definition covers the missing pieces an agent needs: what the preview returns, what gets deleted versus preserved, why it may be refused, and that the action is audited. Nothing material is left to inference.

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 would be 3; the description adds real value by specifying that dry_run defaults to true and by enumerating the preview payload (lines removed, processed-date range, before/after balances, blockers). It says less about fund_id, ato_account_id, import_id, and external_ref, but the schema already documents those adequately.

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?

"Take an ATO statement import back out of its account — deletes every line that import created and puts back the opening balance and date it replaced" names a specific verb, resource, and scope, and explicitly delineates what is NOT touched (lines only updated/unchanged, hand-entered lines). This separates it cleanly from import_ato_statement, list_ato_imports, and match_ato_payment without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit operating procedure (preview with dry_run: true, show the user, then call again with dry_run: false) plus concrete preconditions for refusal and the exact remediation path for each blocker (unmatch via match_ato_payment, undo the later import first). An agent knows both when to call it and when it will be rejected.

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