Australian Accounting MCP

Search legislated rates and thresholds

search_tax_rates

Read-onlyIdempotent

Find Australian tax rates, thresholds, and indexation factors by keyword, year, or topic, with cited legislation references for verification.

Instructions

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

Rows come best first, a heading or topic holding the words ahead of content that does. 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 cover readOnly, idempotent, and non-destructive hints. The description adds rich behavioral detail: ranking order, exactness of amounts and years, the unparsed-text caveat, the need to confirm against official sources, and the closed-world absence of unindexed rates. It enhances rather than contradicts 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 yet comprehensive. It front-loads the purpose, then logically presents ranking, content, year behavior, and critical caveats. Every sentence adds information; there is no fluff or repetition.

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 tool's complexity, the output schema exists, and annotations cover safety, the description is complete: it explains what results look like, how to refine with year, what to be cautious about (unparsed amounts), and what is absent. An agent can call it correctly and interpret results appropriately.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the year parameter's filtering semantics ('rows that state no year are then left out') and clarifies that amounts are unparsed text, which informs interpretation of query results. This goes beyond the schema's straightforward parameter descriptions.

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 verb and resource: 'Search rate, threshold, indexation and factor rows in the configured corpus.' It distinguishes itself from sibling search_tax_legislation by specifying row types and the corpus, and explicitly contrasts with calculation tools ('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 provides clear context on when to use this tool (to retrieve legislated rows as stated) and when not (for calculations, pointing to reviewed engines). It also explains the year filter behavior. However, it does not explicitly name alternatives like search_tax_legislation, so the exclusion is implied rather than explicit.

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

Deploy Server