Aus Accounting MCP

Search legislated rates and thresholds

search_tax_rates

Read-onlyIdempotent

Look up tax rates, thresholds, and indexation factors by keyword, year, or topic. Retrieve the exact Act, section, and compilation reference for verification.

Instructions

Search rate, threshold, indexation and factor rows in the configured corpus.

Each row carries the amounts and years exactly as the provision states them, with the Act, section, compilation number and register page that set them. year narrows to rows stating that year; rows that state no year are then left out, so drop the filter to see a rate the provision does not date. Amounts are unparsed text, not a calculation: a row can be superseded, indexed elsewhere or subject to conditions the row does not carry, so confirm the operative figure against the official source. Rates the corpus builds no rows for, including any figure set outside legislation, are simply absent. Use the reviewed engines for a calculation.

Input Schema

TableJSON Schema

Name	Required	Description
`year`	No	Optional year exactly as the provision states it, such as '2026-27'; only rows whose stated years include it are returned.
`limit`	No	Maximum rows per page.
`query`	Yes	Words to find together in one rate or threshold row, case-insensitive.
`topic`	No	Optional words the corpus topic must contain, such as 'superannuation' or 'capital gains'.
`offset`	No	Continue with next_offset using the same query and unchanged corpus. A page can omit next_offset while has_more is true at the 10000-result boundary; narrow the query instead.

Output Schema

TableJSON Schema

Name	Required	Description
`corpus`	Yes	Corpus-level source, retrieval date and licence terms from the operator's configured corpus; empty when the corpus ships no manifest.
`notice`	Yes
`matches`	Yes
`has_more`	Yes
`next_offset`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.13Sep 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool read-only and idempotent, but the description adds substantial behavior: rows preserve exact provision wording, year filtering drops undated rows, amounts are unparsed text and may be superseded, and rates absent from the corpus are simply missing. There is no contradiction with 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and tightly packed: the opening sentence states purpose, while each subsequent sentence earns its place by explaining a limitation, a filter nuance, or an alternative. There is no filler.

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 rich input schema, annotations, and presence of an output schema, the description covers search scope, result provenance, the year-filter edge case, reliability caveats, and when to use an alternative. Nothing important appears missing for correct invocation.

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 is 3. The description adds meaning beyond the schema by clarifying year-filter edge behavior ('rows that state no year are then left out') and warning that amount values are unparsed text, which affects how query results should be interpreted.

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 verb and resource ('Search rate, threshold, indexation and factor rows') and the title narrows scope to 'legislated rates and thresholds.' It also distinguishes itself from calculation tools by closing with 'Use the reviewed engines for a calculation.'

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?

The description gives clear context: use this for raw legislated rate/threshold rows, and explicitly says not to use it for calculations, pointing to 'reviewed engines.' It does not name specific sibling tools for statutory text or calculation, so the exclusion guidance is directional rather than exhaustive.

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

Deploy Server