Australian Accounting MCP

Read a cited ATO ruling paragraph

read_ato_ruling

Read-onlyIdempotent

Retrieve a cited ATO ruling paragraph by its search row_ref, with pagination and optional neighbouring paragraphs, preserving run-specific citations and caveats.

Instructions

Read one cited paragraph from the configured rulings runs.

Pass row_ref exactly as search_ato_rulings returned it; other strings are refused. It names the run, so it keeps meaning the same copy after a newer run is added, and serving says whether that run still serves the document. A document a later run excluded is refused from every copy. Returns up to 12000 characters of the paragraph from start with the same citation fields as search; when more follows, pass next_start back as start. Preserve the citation, the caveats and the non-endorsement statement. Local reads only, not a confirmation of the Commissioner's current view.

Input Schema

TableJSON Schema

Name	Required	Description
`start`	No	Character to read from. Pass the previous read's next_start to continue a long paragraph.
`row_ref`	Yes	row_ref returned by search_ato_rulings, such as 'run-2099-02-01\|TXR/TR20991/NAT/ATO/00001\|3'.
`neighbours`	No	Paragraphs of the same document to return on each side of the cited one, at search length. 0 returns the paragraph alone.

Output Schema

TableJSON Schema

Name	Required	Description
`after`	Yes	Up to neighbours paragraphs of the same document after the cited one in the run's order, nearest first, at search length.
`start`	Yes	Character of the stored paragraph this part starts at.
`before`	Yes	Up to neighbours paragraphs of the same document before the cited one in the run's order, nearest last, at search length.
`corpus`	Yes	The operator's configured rulings runs: how many are configured and serving, documents served and withheld, the fetch-date range, each reuse notice with the runs carrying it, the non-endorsement statement and how results are ordered.
`notice`	Yes
`paragraph`	Yes
`next_start`	Yes	Where the next part begins; pass it as start to continue. null when this part reaches the end of the paragraph.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.20Sep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior: row_ref is stable across newer runs, serving status is reported, a document excluded by a later run is refused from every copy, output is capped at 12000 characters with next_start pagination, and it is a local read that is not a confirmation of the Commissioner's current view. This is exactly the added value annotations cannot carry.

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?

The description is dense but front-loaded, leading with the core action and the row_ref contract before the pagination and caveat details. Some sentences run long and the referent of 'It names the run' is slightly ambiguous, costing a point on structure.

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?

With an output schema present, return fields need not be explained, and the description still covers the operational details an agent needs: refusal of malformed refs, run-scoped stability, exclusion behavior, truncation at 12000 characters, and continuation via start. Nothing material is 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, but the description adds meaning beyond the schema: row_ref 'names the run' and retains meaning after a newer run is added, and next_start should be passed back as start to continue. The neighbours parameter is left entirely to the schema, which is acceptable given full schema coverage.

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 ('Read one cited paragraph from the configured rulings runs') and scopes it to the cited paragraph rather than a document, which distinguishes it from the sibling search_ato_rulings that produces the row_ref. An agent can tell immediately that this is a follow-up read, not a search.

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 says to pass row_ref exactly as search_ato_rulings returned it and that other strings are refused, which gives a clear precondition and ties the tool to its producer. It does not name any alternative tool or state when not to use this one (e.g. when the whole document is wanted), so it stops short of explicit alternatives.

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

Deploy Server