Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Australian Business Verification MCP Search for business named 'Acme Consulting'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides AI agents (like Claude) with tools to look up and verify Australian businesses using the official Australian Business Register (ABR) JSON API.
This server exposes three core tools to the LLM:
lookup_abn: Retrieve business details (entity name, GST status, entity type) using an 11-digit Australian Business Number (ABN).
lookup_acn: Retrieve company details using a 9-digit Australian Company Number (ACN).
search_by_name: Search the register for active or historical entities by their business or legal name.
Related MCP server: filed-mcp-server
Node.js (v18+)
An official ABR GUID (API Key). You can apply for one via the Australian Business Register website.
Install dependencies:
npm installConfigure Environment Variables:
Create a .env file in the root directory and add your ABR GUID:
ABR_GUID=your_guid_hereBuild the project:
npm run buildUsing with Claude Desktop: Add the server to your Claude Desktop configuration file.
Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"australian-business-verification-mcp": {
"command": "node",
"args": [
"YOUR_ABSOLUTE_PATH_TO/australian-business-verification-mcp/build/index.js"
],
"env": {
"ABR_GUID": "your_guid_here"
}
}
}
}
d```
> Note: Make sure to replace `YOUR_ABSOLUTE_PATH_TO` with your actual path, and provide your real ABR_GUID.Lookup Australian business details using an ABN (Australian Business Number). Returns entity name, status, type, and GST info.
| Name | Required | Description | Default |
|---|---|---|---|
| abn | Yes | The 11-digit ABN (spaces are safely ignored) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it returns info. Does not disclose read-only nature, authentication requirements, rate limits, or any side effects. For a lookup tool, the agent needs to know it is safe and idempotent.
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?
Single sentence that is concise, front-loaded with the action and resource, and contains no redundant words.
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?
For a simple tool with one parameter and no output schema, the description mentions return fields. Lacks details on error behavior or format, but sufficient for basic usage.
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% with a clear description for the abn parameter. The tool description only mentions 'using an ABN' without adding new semantic meaning beyond the schema.
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?
Clearly states 'Lookup Australian business details using an ABN' with specific return fields. Distinguishes from siblings like lookup_acn (different identifier) and search_by_name (different search approach).
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?
Provides clear context for when to use (when you have an ABN) but no explicit when-not-to-use or alternatives mentioned. However, the context is clear enough for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lookup Australian company details using an ACN (Australian Company Number).
| Name | Required | Description | Default |
|---|---|---|---|
| acn | Yes | The 9-digit ACN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose response format, read-only nature, or any constraints (auth, rate limits). It only states purpose, lacking behavioral context.
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?
Single sentence of 10 words, efficient and front-loaded with the action verb. No extraneous information.
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?
For a simple lookup tool with one parameter, the description is minimally adequate. However, without an output schema, it could benefit from hinting at the kind of details returned.
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% with a clear description ('The 9-digit ACN'). The description adds no further meaning beyond what the schema already provides, so baseline 3.
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 clearly states the verb 'Lookup' and the resource 'Australian company details' using a specific identifier (ACN). This distinguishes it from sibling tools which use ABN or name.
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 description implies usage when an ACN is available, and the sibling tool names (lookup_abn, search_by_name) provide clear context for alternatives. No explicit when-not, but sufficient for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for active or historical Australian businesses and matching entities by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The business or entity name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'active or historical' scope, but does not disclose whether results are paginated, how results are ordered, or any rate limits. Minimal behavioral insight.
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?
Single sentence, front-loaded with action and scope. No extraneous words or repetition.
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 low complexity and 1 required parameter, the description is minimal. No output schema, so description could explain return format or result limitations. Lacks completeness for a search tool.
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% for the single parameter. Description adds no extra information beyond the schema description. Baseline 3 is appropriate.
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 clearly states the action (search), the target (Australian businesses and entities), and the scope (by name, active or historical). It distinguishes from sibling tools lookup_abn and lookup_acn, which are lookups by identifier.
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 description implies usage when searching by name, but no explicit guidance on when to use or not use this tool vs alternatives. Sibling tools are mentioned but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0lookup_abnlookup_acnsearch_by_nameEach tool targets a unique identifier (ABN, ACN, name) with no overlap in purpose, making them clearly distinct.
All tool names follow a consistent verb_noun pattern (lookup_abn, lookup_acn, search_by_name) using snake_case throughout.
Three tools is well-scoped for verifying Australian businesses via common identifiers (ABN, ACN, name).
Covers the main lookup methods (ABN, ACN, name search) needed for business verification, leaving no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
ABN Lookup MCP — BYOK wrapper around the Australian Business Register's
Hosted MCP server for live public-data APIs and Skills for AI agents.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arbazex/australian-business-verification-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
