Australian Accounting MCP

Review related Payday Super contributions

review_payday_super_contributions

Read-onlyIdempotent

Review grouped payday super contributions for one employer, aligning rows to s 18C(2) item 4 and flagging receipt timing or eligibility issues. Local review aid, not advice.

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.22Oct 6, 2026
- addedInput schema / $defs / ContributionInput / properties / matched_amount / pattern
```
Added value: +"^\\s*-?[0-9]+(?:\\.[0-9]{1,2})?\\s*$"
```
- addedInput schema / $defs / ContributionInput / properties / remitted_amount / pattern
```
Added value: +"^\\s*-?[0-9]+(?:\\.[0-9]{1,2})?\\s*$"
```
- addedInput schema / $defs / ContributionInput / properties / sg_amount / pattern
```
Added value: +"^\\s*-?[0-9]+(?:\\.[0-9]{1,2})?\\s*$"
```

Changed1 schema field changedv0.1.14Sep 23, 2026

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

Previous 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."New value: +"Evidenced fund-receipt date. Timing only: pair it with matched_amount (or remitted_amount). Checker 0.1.7 leaves a timely receipt without an amount UNKNOWN; a late receipt stays LATE without reducing the shortfall. Earlier checker 0.1.6 assumes full receipt and says so in a caveat."

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

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds scope boundaries (no raw payment allocation, no SG entitlement calculation, no transition allocation confirmation) and a state precondition that the engine assumes no ATO assessment. It also instructs to preserve warnings/UNKNOWN outcomes, which is useful behavioral context beyond the 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?

Roughly six short sentences with the purpose and the one-employer scoping rule front-loaded, followed by prereqs and exclusions. Dense domain jargon but no filler; only minor loss for the clipped, fragment-heavy phrasing.

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?

An output schema exists, so return values need not be explained, and the description covers the prerequisites, the exclusions and the engine state assumption an agent needs before calling. It is nearly complete, missing only a pointer to the sibling tool that handles the excluded calculations.

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% and the nested ContributionInput fields are thoroughly documented in the schema, so this dimension is schema-driven. The description only reinforces the semantics already present ('one employer', 'exact employee references', 'three eligibility flags') without adding format or constraint detail. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Review related paydays together') plus a domain anchor ('s 18C(2) item 4 alignment') and a scoping rule (one employer, exact employee references). It is clearly distinct from siblings like calc_payday_super_deadline or build_payday_super_evidence_pack, though it never names them, so it stops short of full sibling differentiation.

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?

Gives real preconditions ('Establish eligibility flags before calling', 'Allocate receipts to rows first') and explicit exclusions ('does not allocate raw payments, calculate SG entitlement or confirm transition allocation'), plus the state assumption ('no ATO assessment has issued'). It stops short of 5 because it never routes the agent to a named alternative tool for the excluded cases.

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

Deploy Server