Aus Accounting MCP

Review related Payday Super contributions

review_payday_super_contributions

Read-onlyIdempotent

Review grouped payday super contributions for an employer, verifying s 18C(2) item 4 alignment and flagging warnings after receipts are allocated and eligibility flags set.

Instructions

Review related paydays together, including s 18C(2) item 4 alignment.

Supply rows for one employer and preserve exact employee references. Establish eligibility flags before calling. Allocate receipts to rows first; this tool does not allocate raw payments, calculate SG entitlement or confirm transition allocation. Assumes no ATO assessment has issued. Retain every row's warnings, UNKNOWN outcomes and engine metadata. Local review aid, not advice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`as_at`	Yes	Explicit assessment date, YYYY-MM-DD.
`contributions`	Yes	All related contribution rows for one employer, up to 200. Use exact employee references and explicitly establish the three eligibility flags.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	The review ran; this does not mean compliance or a known verdict.
`as_at`	Yes	Date in YYYY-MM-DD form.
`engine`	Yes	Delegated distribution that produced this result.
`caveats`	Yes	Limitations to retain when presenting the result.
`results`	Yes
`disclaimer`	Yes
`engine_version`	Yes	Installed version of that engine.
`assessment_scope`	Yes
`law_content_date`	Yes	Date in YYYY-MM-DD form.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.13Sep 21, 2026

changedInput schema / $defs / ContributionInput / properties / matched_amount / description

Previous value: -"AUD allocated to this row."New value: +"AUD the fund received for this row. Supply it with every received date: a receipt date alone evidences no amount, and an engine with the receipt-amount rule will not assess a full receipt as ON_TIME without it."

changedInput schema / $defs / ContributionInput / properties / received / description

Previous value: -"Evidenced fund-receipt date."New value: +"Evidenced fund-receipt date. Timing only: pair it with matched_amount (or remitted_amount). An engine with the receipt-amount rule (unreleased after payday-super-checker 0.1.6) leaves a bare receipt UNKNOWN rather than ON_TIME; 0.1.6 reads it as a full receipt and says so in a caveat."

addedInput schema / properties / as_at / maxLength
```
Added value: +40
```

Addedv0.1.10Sep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds genuinely valuable behavioral context: it assumes no ATO assessment has issued, preserves warnings/UNKNOWN outcomes/engine metadata, and identifies itself as a local review aid rather than advice. These details go well beyond the structured annotations.

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?

The description is compact and front-loaded with the tool's purpose. Each sentence earns its place by adding a distinct constraint, assumption, exclusion, or boundary. Despite heavy domain jargon, there is no filler.

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?

With an output schema present and careful annotations, the description is largely complete: it covers preconditions, exclusions, assumptions, and preservation requirements. It leaves the meaning of 's 18C(2) item 4 alignment' and 'engine metadata' implicit, and it does not explicitly connect to sibling tools, but these are reasonable omissions for a domain-specialized tool with rich schema coverage.

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% and individual field descriptions are already strong. The description adds useful guidance beyond the schema—'Allocate receipts to rows first,' preserve exact employee references, and the explicit statement that raw payments and SG entitlement are out of scope. It repeats some schema phrases, which prevents a 5.

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 states a specific action—'Review related paydays together'—and adds a concrete legislative anchor, 's 18C(2) item 4 alignment.' This clearly distinguishes it from sibling tools like build_payday_super_evidence_pack and calc_payday_super_deadline.

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 provides strong preconditions and boundaries: establish eligibility flags before calling, allocate receipts first, and explicitly says it does not allocate raw payments, calculate SG entitlement, or confirm transition allocation. However, it does not name alternative sibling tools or give an explicit 'use X instead' routing, so the agent must infer alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server