Skip to main content
Glama
Sign In
Beeswax Shares MCP Server

Beeswax Shares MCP Server

by steamau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get the year's checks

get_return_checks
Read-only

Retrieve every financial-year return check with placement, status, state, figure, reason, linked return fields, and recorded answers to identify blocking or attention items before finalising.

Instructions

Every check for a financial year: where it lives (placement — a Books group: "books_bank", "books_income", "books_holdings", "books_other"; a tax return section such as "income" or "assets_liabilities"; or a Compliance group: "compliance_tests", "documents"), its status (ok / warn / bad / na), state (ready, attention, blocking, accepted, na), figure, reason, the return fields it feeds, and any answer a person recorded. Blocking checks on the Books step and on the return stop the return being finalised. A check needing attention can be accepted, or a question answered, with resolve_return_check once the trustee says so; explain what you found with add_smsf_return_field_note on the figures it affects.

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": "get_return_checks"
  }
}

Input Schema

NameRequiredDescriptionDefault
fund_idYesFund ID (discover via whoami or list_funds)
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.8.1

TDQS

A4.4/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description discloses the returned content in detail: placement groups, status values, state values, figure, reason, fed return fields, and recorded answers. It also explains the downstream effect of blocking checks and the trustee-gated resolution path, which is substantive behavior not covered by annotations.

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 with the core scope and remains focused on what the tool returns and how checks affect finalisation. The first sentence is long and heavily parenthetical, which reduces readability, but the enumerated details mostly earn their place.

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 read-only retrieval tool with two fully documented parameters and no output schema, the description sufficiently explains what is returned and why it matters. It covers the check states, blocking implications, and the follow-up actions an agent may need.

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 both fund_id and financial_year are already documented in the schema. The description only implies a financial-year scope and adds no new meaning about the fund_id parameter, so the baseline 3 is appropriate.

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?

The description opens with a specific scope: 'Every check for a financial year', then enumerates the returned dimensions (placement, status, state, figure, reason, return fields, recorded answers). This clearly distinguishes it from the singular get_return_check and from follow-up tools like resolve_return_check.

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?

It gives useful workflow context: blocking checks stop finalisation, and checks needing attention can be accepted or answered via resolve_return_check once the trustee agrees. It does not explicitly say when to choose this over get_return_check or list_smsf_return_gaps, so it stops short of full alternative 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