Skip to main content
Glama
ryanduguid

Aus Accounting MCP

Build a Payday Super evidence pack

build_payday_super_evidence_pack
Read-onlyIdempotent

Assess Payday Super contributions and generate an evidence pack that flags exceptions for human review, with CSV, markdown, JSON, and decision-log outputs.

Instructions

Return report.csv, practitioner-review.md, exceptions.json and decision-log.md.

The engine owns all assessment and rendering. Returns UTF-8 file contents in memory, with no file reads or writes for caller-supplied paths. Missing receipt evidence remains missing; all non-ON_TIME rows require human review. The report omits employee identifiers, but input references still enter the calling host. Review aid, not advice or lodgement. Requires an engine with evidence-pack support.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_atYesExplicit assessment date, YYYY-MM-DD.
contributionsYesEstablished contribution rows for one employer. Supply all related rows and the three eligibility flags. Use fabricated rows for demonstrations.
response_detailNoFull repeats the pack in text for compatibility. Compact keeps all files in structuredContent.files and summarises text; use only with a host that reads them.full

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesThe review ran; this does not mean compliance or a known verdict.
as_atYesDate in YYYY-MM-DD form.
filesYes
engineYesDelegated distribution that produced this result.
caveatsYesLimitations to retain when presenting the result.
disclaimerYes
engine_versionYesInstalled version of that engine.
law_content_dateYesDate in YYYY-MM-DD form.
review_exit_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.13
    • 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
  2. Addedv0.1.11

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description adds substantial behavioral context: file returns happen in memory with no caller-supplied file writes, missing receipt evidence is preserved as missing, non-ON_TIME rows require human review, employee identifiers are omitted from the report, and the output is a review aid rather than advice. These are exactly the kind of non-obvious behaviors an agent needs to know.

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 concrete output files, then efficiently delivers only high-value behavioral caveats. Every sentence adds meaning: memory-only returns, missing-evidence handling, human review, identifier omission, legal disclaimer, and engine prerequisite. No wasted words.

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?

Given the output schema exists, the input schema covers all parameters, and annotations cover the read-only safety profile, the description fills the remaining gaps: exact file names, in-memory behavior, privacy handling, human-review needs, and the engine-support requirement. Nothing critical is missing for correct invocation.

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%, with rich parameter descriptions for contributions, as_at, and response_detail, so the description does not need to repeat parameter semantics. It correctly leaves parameter detail to the schema, earning the baseline 3.

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?

The description identifies a specific deliverable set ('report.csv, practitioner-review.md, exceptions.json and decision-log.md') and clearly frames the tool as building a Payday Super evidence pack. It stops short of distinguishing itself from the closely related sibling review_payday_super_contributions, so it earns 4 rather than 5.

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

Usage Guidelines2/5

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

The description gives no explicit when-to-use guidance and names no alternative tools or exclusion conditions. It mentions a prerequisite ('Requires an engine with evidence-pack support') but does not help an agent choose this tool over review_payday_super_contributions or other siblings.

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