AUO exposes a stateless Model Context Protocol (MCP) server at https://api.auo.com.au/mcp. Any MCP-compatible client (an AI agent, Claude, a custom orchestration layer) can call AUO tools directly, using the same bearer token as the REST API.

​
Key characteristics

  • Same auth as REST. Pass your auo_sk_test_ or auo_sk_live_ token in the Authorization header when connecting. The test/live sandbox distinction works identically.
  • Stateless. Each request is independent. No session state is held between calls.
  • Read-only by design. The MCP surface exposes exactly 6 tools, all read-oriented. No delete, roll, or update tools are available via MCP. Account scoping comes from the token, never a tool argument.
  • Same core as REST. Each tool calls the same internal function as the corresponding REST endpoint. MCP and REST cannot produce different results for the same query.

​
The 6 tools

ToolWhat it doesREST equivalent
resolve_entityResolve an ABN, ACN, or name to a canonical entity with enrichment and provenancePOST /v1/resolve
screen_entityScreen a name or identifier against sanctions and banned-persons registersPOST /v1/screen
validate_abnCheck an ABN’s format and compute its check digitGET /v1/validate/{abn}
validate_acnCheck an ACN’s format and compute its check digitGET /v1/validate/{acn}
watch_entityCreate a watch subscription for an entity and return the signing secretPOST /v1/watch
list_watchesList active watch subscriptions for the accountGET /v1/watch
screen_entity keeps the possible-match-never-cleared posture: results are review, no_match, or unavailable. Never pass or fail. “No match found” is not a clearance. See Screening posture for the rationale.

​
Connecting a client

Point your MCP client at the AUO endpoint with your bearer token. The exact configuration format depends on your client. The generic pattern:
MCP client config (generic)
{
  "mcpServers": {
    "auo": {
      "transport": {
        "type": "streamable-http",
        "url": "https://api.auo.com.au/mcp",
        "headers": {
          "Authorization": "Bearer auo_sk_live_your_key_here"
        }
      }
    }
  }
}
Replace auo_sk_live_your_key_here with your actual key. Use auo_sk_test_... during development to avoid consuming your live quota.
Never put your bearer token in a URL or log file. Pass it as a header value only, as shown above.

​
Connecting Claude

If you are using Claude as your agent and your client supports MCP server configuration, add the entry above to your MCP servers list. Claude will then have access to all 6 AUO tools and can resolve entities, run screening checks, and manage watches on your behalf.

​
Tool authentication and scoping

Account scoping is handled entirely by the bearer token. There is no account ID parameter in any tool argument. When you call list_watches, the response contains only the subscriptions that belong to the account the token was issued for. This means:
  • A test token (auo_sk_test_) sees synthetic fixtures only, across all 6 tools.
  • A live token (auo_sk_live_) sees real data and counts against your plan allowance.
  • There is no way to access another account’s data via a tool argument.

​
Example: resolving an entity via MCP

A tools/call for resolve_entity with an ABN produces the same response shape as POST /v1/resolve:
Tool call
{
  "method": "tools/call",
  "params": {
    "name": "resolve_entity",
    "arguments": {
      "abn": "51824753556"
    }
  }
}
The response includes the canonical entity, enrichment blocks, and the per-field provenance (source and as_of). See API reference: resolve for the full response schema.

​
Next steps

Authentication

Bearer tokens, test vs live, and the key lifecycle.

API reference: resolve

Full request and response schema for entity resolution.

API reference: screen

Full request and response schema for watchlist screening.

Watch and webhooks

Create a watch subscription and receive signed webhook events.