au-compliance-kit

ABN, ACN, TFN, BSB or account number validation

identifier_validation

Read-onlyIdempotent

Checks an Australian Business Number (ABN), Australian Company Number (ACN) or tax file number (TFN) with the official check-digit algorithms, or the format of a BSB or bank account number. Returns valid true or false, with the normalised form or the reason it fails. Use it before storing or submitting an identifier. It confirms the number is well formed, not that it is registered or belongs to anyone: use the ABR's ABN Lookup for registration. Runs locally; nothing is sent anywhere.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>",
      "value": "<value>"
    },
    "name": "identifier_validation"
  }
}

Input Schema

Name	Required	Description	Default
`type`	Yes	Which identifier: abn, acn, tfn, bsb or bank_account.
`value`	Yes	The number, with or without spaces or dashes, e.g. "51 824 753 556".

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and locality are partly covered. The description still adds real context the annotations only imply: "Runs locally; nothing is sent anywhere" plus the return shape (valid true/false with normalised form or failure reason). It stops short of detail such as which failure reasons are returned or handling of leading zeros.

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?

Five short sentences, front-loaded with what is checked and what is returned, then usage, then scope caveat, then execution model. No sentence is redundant and each carries a distinct constraint.

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?

For a two-parameter, fully documented, non-destructive local tool with no output schema, the description covers the return contract, the scope limit, and the execution environment. Nothing an agent needs in order to call it correctly or interpret the result is missing.

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 by explaining that abn/acn/tfn use official check-digit algorithms while bsb/bank_account are format-only, which changes how an agent should interpret a false result per type. The whitespace/dash tolerance is already in the schema, so no extra credit there.

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?

States a specific verb ("Checks") and enumerates the exact resource set, and it distinguishes the two behaviors: check-digit algorithms for ABN/ACN/TFN versus format-only for BSB/bank_account. An agent can tell precisely what this tool computes without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ("before storing or submitting an identifier") and an explicit exclusion with an alternative ("use the ABR's ABN Lookup for registration"). It also bounds the claim ("confirms the number is well formed, not that it is registered"), which prevents misuse as a verification-of-ownership tool.

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

All au-compliance-kit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.