abn_checkValidate an Australian Business Number by its mod-89 checksum (11 digits).
| Name | Required | Description | Default |
|---|---|---|---|
| abn | Yes | 11-digit Australian Business Number; spaces allowed. |
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| scope | No | ||
| valid | Yes | ||
| reason | Yes | ||
| country | No | ||
| normalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and openWorld false, lowering the bar. The description adds the important constraint that this is only a checksum validation, not a registry lookup, which sets correct expectations about what the tool does not do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence carries purpose, resource, country, algorithm, and length, with zero filler. The title and description do not redundantly restate each other to an excessive degree.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter, an output schema, and annotations that establish safety and idempotency, nothing needed to call this tool correctly is missing. The description fully explains the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the one parameter is well documented with format and space allowance. The description augments this by stating the checksum criterion a valid value must satisfy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate'), a resource ('Australian Business Number'), and the validation method ('mod-89 checksum') in a single sentence. This clearly distinguishes abn_check from sibling tools like vat_mod97_check or company_number_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource is named explicitly, so an agent can infer when to use it: whenever an Australian Business Number needs checksum validation. It does not list alternatives or exclusions, so it stops short of a 5, but the context is unambiguous enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct identifier type or specific function (e.g., IBAN vs. EIN vs. block info), with no overlap even among similar validation routines. The batch and rental tools combine distinct sub-checks without ambiguity, making misselection unlikely.
Tool names are uniformly snake_case and mostly follow a descriptive pattern, but the action verbs vary (e.g., 'check', 'format', 'info', 'guard', 'verdict') rather than a single verb_noun structure. While clearly readable, the pattern is not perfectly uniform.
At 28 tools, the server feels like a broad utility pack rather than a focused domain. The count exceeds the 'heavy' threshold and includes three distinct sub-domains (financial identifiers, rental fraud, on-chain queries), making the surface area hard to navigate coherently.
The identifier validation coverage is thorough (most common checksums), rental checks cover risk, deposit, and verdict, and on-chain tools handle balances, activity, and settlement history. Minor gaps exist (e.g., no token transfer history, no generic identifier detection) but agents can likely work around them.