Resolve Australian postcodes to locality, state and coordinates.
Scored across 3 tools
The three tools are mostly distinct: postal_lookup handles a single postcode, batch_postal handles multiple postcodes, and distance computes distance between two postcodes. However, batch_postal could technically handle a single postcode and overlaps in output territory with postal_lookup, creating minor ambiguity.
Names are all snake_case and readable, but they follow mixed conventions: batch_postal is a modifier+noun, distance is a bare noun, and postal_lookup is noun+noun. There is no consistent verb_noun pattern, though the names are not chaotic.
Three tools is well-scoped for a focused Australian postcode lookup server. Each tool serves a clear, non-redundant purpose: single lookup, batch lookup, and distance calculation.
The core lookup operations are covered, including batch resolution and distance calculation. Minor gaps exist, such as reverse lookup from locality to postcode or searching postcodes by state/suburb, but these are likely workable via the existing tools.
PRO. Resolve up to 100 Australian postcodes.
| Name | Required | Description | Default |
|---|---|---|---|
| postcodes | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the 100-item cap and Australian scope, but says nothing about authentication requirements despite the access_token parameter, nor about error handling for invalid postcodes, rate limits, or what a resolved result contains.
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?
Two short sentences, front-loaded with the operation and its scope. The unexplained "PRO" prefix is the only wasted token; otherwise the description is tight.
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 two-parameter read tool with no annotations and no output schema, the description is thin. It omits auth expectations, return shape (what a resolved postcode yields), and failure behavior, leaving the agent to guess at important call-time details.
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 50%: access_token is documented in the schema, while the required postcodes array is not. The description partially compensates by clarifying that the array holds Australian postcodes and is capped at 100, but gives no format details or validation rules.
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 states a specific verb and resource ("Resolve ... Australian postcodes") and adds batch scope with a 100-item cap. It distinguishes itself implicitly from the single-lookup sibling via "batch" and the limit, but never names postal_lookup or explains the distinction explicitly.
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 100-postcode cap implies this is the bulk path versus postal_lookup, but the description never states when to choose one over the other or when not to use this tool. Usage must be inferred from the word "batch" and the limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRO. Approximate km between two Australian postcodes.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that results are approximate, the scope is Australian postcodes, and 'PRO' suggests a tier/subscription distinction, but it omits auth behavior, error handling, and invocation constraints beyond the schema.
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?
The description is very short and front-loads the core purpose. 'PRO.' is slightly cryptic, but the overall structure is efficient with no padding.
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 distance calculation, the description conveys the key return concept (approximate km) despite no output schema. However, it leaves input format and behavior for invalid or non-Australian postcodes unspecified, and does not relate the tool to its siblings.
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 description coverage is only 33%, with access_token documented in the schema. The description clarifies that from/to are Australian postcodes, adding meaning beyond the bare parameter names, but it does not specify postcode format or further access_token behavior.
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 states a clear operation and resource: approximate distance in km between two Australian postcodes. It is specific enough to distinguish from a simple postal lookup, though it does not explicitly name sibling tools or their differences.
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?
There is no guidance on when to use this tool versus postal_lookup or batch_postal, nor any stated exclusions or prerequisites. The only usage signal is that it applies to two Australian postcodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Resolve an Australian postcode to locality, state and lat/lon.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the lookup is free, limited to Australia, and returns locality, state and coordinates, but says nothing about invalid/missing postcode behavior, rate limits, or response structure.
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?
One compact sentence with the key scope and return values front-loaded; 'FREE' is brief and relevant to tool selection. There is no wasted text.
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 one-parameter lookup with no output schema, the description names the return fields and geographic scope, which is close to sufficient. It could be stronger by stating what happens for an unknown postcode, but nothing essential for a successful call is missing.
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 0% and the single parameter is undocumented in the schema, so the description must compensate. It adds that the postcode is Australian, which narrows valid input, but gives no format expectations (e.g. four digits) or error semantics.
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?
States a specific verb ('Resolve') and resource ('Australian postcode') and names the outputs (locality, state, lat/lon), so the agent knows exactly what the tool does. It does not distinguish itself from the sibling batch_postal, leaving the single-vs-batch distinction implicit.
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?
No guidance on when to use this instead of batch_postal or distance; the single-lookup scope is only implied. The agent must infer that batch_postal is for multiple postcodes and distance is for measuring separation.
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.
batch_postaldistancepostal_lookupResolve Canadian postal codes to city, province and coordinates.
Resolve Japanese 〒 postcodes to prefecture, city and town.
Australian address autocomplete, validation and geocoding from G-NAF, the national register.
Free, keyless postal/ZIP code lookup: place name(s), state/region, and coordinates.
Add one secure layer between your agents and this server.