Skip to main content
Glama
Bigred97

io.ausdata/asic-mcp

latest

Return current ASIC register snapshots or recent matching records per entity; filter by dataset fields to inspect one adviser, licensee, or banned person.

Instructions

Return the most recent observation(s) per measure for a dataset.

For register data, "latest" is the current weekly/monthly snapshot capped at limit rows (default 50). For time-bounded fields (date_banned, date_ceased), latest returns the most recent matching record per entity.

Pass filters to drill into one entity (no truncation hits) or raise limit to request more rows.

Examples: # Current registered status for one adviser (precise filter, no truncation) resp = await latest( "ASIC_FINANCIAL_ADVISERS", filters={"adviser_number": "1234567"}, )

# First 50 most-recent banned persons (truncated; full count in resp.truncated_at)
resp = await latest("ASIC_BANNED_PERSONS")

# Get 500 rows in one go (still capped, but bigger window)
resp = await latest("ASIC_AFS_LICENSEE", limit=500)

# Full authorisation text for one AFS licensee
resp = await latest(
    "ASIC_AFS_LICENSEE",
    filters={"licensee_name": "Macquarie Bank Limited"},
    include_full_authorisation=True,
)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows to return. ASIC registers can be huge — ASIC_AFS_AUTH_REP alone has ~360,000 rows. Without a cap the response blows an agent's context window. Pass filters to narrow the search; raise `limit` only if you genuinely need a bulk dump. Truncated responses set DataResponse.truncated_at to the original row count so agents can detect + surface it.
filtersNoSame filter shape as get_data. Useful for narrowing to one entity. MCP clients that cannot send a native object may pass this as a JSON-encoded string instead, e.g. '{"adviser_number": "1234567"}'.
dataset_idYesCurated dataset ID.
include_full_authorisationNoASIC_AFS_LICENSEE only. The `authorisation` field carries 2-3 KB of license boilerplate per record. To stay under the portfolio's 10k-token target, that field is truncated to ~200 chars by default. Pass True to receive the full text — typically used when narrowing to one licensee. Ignored for the other ASIC datasets.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
csvNo
unitNo
queryNo
staleNo
periodNo
sourceNoAustralian Securities and Investments Commission (ASIC), via data.gov.au
recordsNo
row_countNo
dataset_idYes
source_urlYes
attributionNoSource: Australian Securities and Investments Commission, licensed under Creative Commons Attribution 3.0 Australia (CC BY 3.0 AU) — https://creativecommons.org/licenses/by/3.0/au/. Data accessed via data.gov.au. © Commonwealth of Australia.
dataset_nameYes
retrieved_atYes
stale_reasonNo
truncated_atNo
server_versionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.22

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the 50-row default cap, that huge registers blow the context window, that truncation sets DataResponse.truncated_at, and that `authorisation` is silently truncated to ~200 chars unless include_full_authorisation=True. It does not state read-only status, permissions, or rate limits, which keeps it out of the top band.

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?

Front-loaded with a one-line summary, then contract details, then worked examples; every block earns its place and the examples double as invocation templates. It is longer than strictly necessary, with some repetition of limit behavior between prose and schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still explains the truncated_at signal, which is the key thing an agent must react to. Combined with the filter/limit guidance, it is complete enough to call correctly, missing only sibling-selection guidance and any note on write-safety or auth.

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 description coverage is 100%, so the baseline is 3; the description exceeds it by adding rationale and cross-parameter interaction (filter vs. limit tradeoff, include_full_authorisation being ASIC_AFS_LICENSEE-only,-string fallback for filters). The examples duplicate the schema's own examples rather than adding new syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Return the most recent observation(s) per measure for a dataset', and clarifies two distinct semantics (register snapshot vs. time-bounded fields). It never explicitly contrasts itself with siblings like get_data or list_curated, so an agent must infer the boundary, but the purpose itself is unambiguous.

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?

Gives concrete guidance: pass `filters` to drill into one entity without truncation, or raise `limit` for a bulk dump, backed by four worked examples. It stops short of an explicit 'use latest instead of get_data when...' rule, so the selection boundary against siblings is left implicit.

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