This MCP server helps AI agents classify, assess, and remediate ISO 20022 postal addresses to ensure compliance with the mandatory structured‑address rule taking effect on 14 November 2026 (SWIFT CBPR+).
Classify (classify_address): Determine whether an address is structured, hybrid, or unstructured.
Assess (assess_address, assess_message): Score a single address or all parties in a pacs.008 / pain.001 message against a policy (e.g. cbpr-2026, sepa, hvps-plus) to flag compliance gaps.
Remediate (remediate_address, remediate_message): Propose the compliant form of an address, produce before/after states, patch operations, and confidence scores; optionally apply fixes to a whole message.
Preview patches (preview_patch): Dry‑run remediation to see what would change without modifying the message.
Explain findings (explain_finding): Get plain‑language descriptions of finding codes (e.g. SAF001) and how to resolve them.
List policies (list_policies): Discover available rulebooks and their tiers.
Get cutover date (get_cutover_date): Retrieve the binding 14 November 2026 deadline and the scheme that mandates it.
Provides assessment and remediation of postal addresses against the SEPA policy, including policy listing, classification, compliance findings, and proposed structured-address fixes.
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., "@structured-address-fix-mcp assess this pacs.008 message for structured address compliance"
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 server that exposes the
structured-address-fix ISO 20022 postal-address library as tools for
AI agents and assistants — classify an address's shape, assess it against a
scheme policy, and remediate it (or a whole pacs.008 / pain.001 message) into
the structured form the November 2026 cutover requires, all from your
favourite MCP client.
The 14 November 2026 cliff. On that date CBPR+, HVPS+, T2, CHAPS, and Fedwire stop accepting fully unstructured postal addresses: a payment whose debtor/creditor address is a free-text blob is rejected.
structured-address-fix-mcpputs the readiness check and the fix in front of your agent —assess_messageflags the offending parties,remediate_messageproposes the compliant form, andget_cutover_datereports the binding date. v0.0.2, stdio transport, 13 tools, Python 3.12+.
Related MCP server: camt053-mcp
The Model Context Protocol (MCP) is an open standard that lets AI agents
and assistants discover and call external tools in a uniform way.
structured-address-fix-mcp is an MCP server that turns the
structured-address-fix library into a set of first-class agent tools,
so an assistant can read a postal address — or every addressed party in an
ISO 20022 pacs.008 / pain.001 message — and bring it into line with the
structured-address rules that become mandatory on 14 November 2026,
directly from a conversation.
The headline capability is the one-shot remediation workflow: assess a message, find the parties whose addresses will be rejected at the cliff, and emit the compliant form with each change explained and confidence-scored.
Every tool is a thin, typed wrapper over structured_address_fix.services —
the single shared facade also used by the CLI — so all interfaces behave
identically. Tools return JSON-serialisable data; on an error they return an
{"error": ...} payload rather than raising.
Website: https://sebastienrousseau.github.io/structured-address-fix/
Source code: https://github.com/sebastienrousseau/structured-address-fix-mcp
Bug reports: https://github.com/sebastienrousseau/structured-address-fix-mcp/issues
flowchart LR
A["MCP client<br/>(Claude Desktop, IDE, agent)"] -->|stdio| B["structured-address-fix-mcp"]
B -->|delegates to| C["structured_address_fix.services"]
C -->|classify + assess + remediate| D["ISO 20022 postal addresses<br/>(pacs.008 / pain.001)"]structured-address-fix-mcp is the postal-address specialist in a set of
coordinated, vendor-neutral MCP servers for the ISO 20022 migration.
Dependency ranges are kept aligned across the suite, so the servers co-install
cleanly in a single Python environment: start with one, add the rest as your
workflow grows.
Server | Scope | Install | Use it when |
ISO 20022 postal-address classification, assessment, and remediation for the Nov 2026 structured-address cliff |
| You need to get debtor/creditor addresses cliff-ready — this package | |
Generate, validate, parse & scheme-check ISO 20022 pacs.008 FI-to-FI credit transfers, with Nov-2026 address linting |
| You work with pacs.008 messages end to end | |
Generate & validate ISO 20022 pain.001 payment-initiation files (v03–v12, pain.008, SEPA) with rulebook checks |
| You originate outbound payment files | |
ISO 20022 camt.05x bank statements: parse, validate, filter, reverse; MT94x migration; CBPR+ readiness |
| You work with bank-to-customer statements | |
Orchestration gateway: detect → validate → clearing-profile lint → readiness score, plus remediation and |
| You want one high-level readiness / orchestration entry point over the suite | |
Manages, validates and serves bank-specific clearing profiles / rule packs; premium rule-pack entitlement gating |
| You lint payments against your own institution's market practice | |
Compiles readiness findings, remediation diffs and simulated responses into a sealed, Ed25519-signable audit evidence pack |
| You need tamper-evident audit / certification artifacts |
The suite also includes the iso20022-mcp
gateway (unified search / describe / validate / generate / parse
meta-tools across the whole message catalogue) and
acmt001-mcp (account
management). Where pacs008-mcp lints a message for address problems,
structured-address-fix-mcp is the specialist that classifies, assesses, and
fixes the addresses themselves against per-scheme policies.
structured-address-fix-mcp runs on macOS, Linux, and Windows and requires
Python 3.12+ and pip. It pulls in the core structured-address-fix
library and the MCP SDK automatically.
python -m pip install structured-address-fix-mcppython -m venv venv
source venv/bin/activate # macOS/Linux
venv\Scripts\activate # Windows
python -m pip install -U structured-address-fix-mcpFor the 10-minute install → MCP client config → first conversation
tutorial, see docs/quickstart.md.
Launch the server over stdio (the FastMCP default transport):
structured-address-fix-mcpRegister it with any MCP client (e.g. Claude Desktop) by adding it to the client's configuration:
{
"mcpServers": {
"structured-address-fix": { "command": "structured-address-fix-mcp" }
}
}The command speaks MCP on stdin/stdout — it is meant to be launched by an MCP client, not used interactively. The agent can then call the tools below to assess and remediate postal addresses on demand.
All tools delegate to the shared structured_address_fix.services layer, so
they behave identically to the CLI. Tools return JSON-serialisable data; on a
domain, validation, or value error they return an {"error": ...} payload.
list_policies — List every available address policy (rulebook) with its tier (e.g. cbpr-2026, sepa, hvps-plus, generic-structured)
classify_address — Classify a postal address as structured, hybrid, or unstructured (a quick shape check)
assess_address — Score a single address against a policy and return its findings
assess_message — Assess every addressed party in a pacs.008 / pain.001 message against a policy
remediate_address — Propose the compliant form of an address, with the before/after and confidence-scored patch operations
remediate_message — Assess and remediate every addressed party in a message; optionally apply the operations and return the patched XML
preview_patch — Return the patch operations remediation would apply to a message (a dry run)
explain_finding — Explain what a finding code (e.g. SAF001) means and how to resolve it
get_cutover_date — Return the binding November 2026 structured-address cutover date and the scheme that sets it
normalize_country_code — Resolve a country name or code to its ISO 3166-1 alpha-2 code, accepting English names, local endonyms (Deutschland, España, Nippon) and everyday aliases (UK, USA, Holland, UAE)
split_street_and_building — Split a street line into street name, building and sub-building, handling both the leading-number convention (10 Downing Street) and the trailing-number one used across much of continental Europe
validate_postal_policy — Validate an address's post_code against a country's format policy (US ZIP / ZIP+4, GB alphanumeric, and others)
parse_address_libpostal — Parse a free-text address into ISO 20022 postal fields; uses libpostal's statistical parser when the optional postal extra is installed, and a deterministic fallback otherwise
Optional parameters shared across the assessment/remediation tools: policy_id
(defaults to cbpr-2026), as_of (an YYYY-MM-DD date that decides the cliff
wording; defaults to today), and country_hint (an ISO 3166-1 alpha-2 code to
assume when an address carries no country of its own).
You can invoke the tools in-process — without a transport — straight through the
FastMCP instance. This mirrors what an agent receives over stdio. The runnable
version of this snippet lives in examples/mcp_tools.py.
import asyncio
from structured_address_fix_mcp import server
# A fully unstructured address: two free-text lines, no structured fields.
# At the 14 Nov 2026 cliff this form is rejected across the major schemes.
unstructured = {
"address_lines": ["10 Downing St", "London SW1A 2AA"],
"country": "GB",
}
async def main() -> None:
async def call(name, args):
result = await server.server.call_tool(name, args)
# mcp 2.x returns a CallToolResult (read .content); 1.x
# returns the content list, or a (content, meta) tuple.
content = getattr(result, "content", None)
if content is None:
content = result[0] if isinstance(result, tuple) else result
return content[0].text if content else ""
# When does the cliff bite?
print(await call("get_cutover_date", {}))
# -> {"date": "2026-11-14", "scheme": "SWIFT CBPR+ UG2026"}
# What shape is this address in right now?
print(await call("classify_address", {"address": unstructured}))
# -> {"classification": "unstructured"}
# Propose the compliant form, with each change explained.
print(await call("remediate_address",
{"address": unstructured, "policy_id": "cbpr-2026"}))
# -> {"policy_id": "cbpr-2026", "findings": [...], "suggestions": [...],
# "is_compliant_before": false, "is_compliant_after": true, ...}
asyncio.run(main())Run it directly:
python examples/mcp_tools.pyPart of the ISO 20022 MCP Suite — open-source, Apache-2.0 licensed MCP servers for banking and financial-services AI agents:
Server | Purpose |
Generate, validate, parse & scheme-check ISO 20022 pacs.008 FI-to-FI credit transfers + Nov-2026 address linting | |
Generate & validate ISO 20022 pain.001 payment files (v03–v12, pain.008, SEPA) with rulebook checks | |
Parse, validate, filter & reverse ISO 20022 camt.05x bank statements; MT94x migration; CBPR+ readiness | |
Generate & validate ISO 20022 acmt account-management messages | |
Unified gateway: |
You have no MCP client. This server only makes sense paired with an
MCP-aware host (Claude Desktop, the IDE plugins, an agent framework). For
scripted / CI use, the structured-address-fix CLI covers the same ground
without the stdio protocol overhead.
You need a long-lived network service. v0.1 speaks stdio only — one process per operator, launched by the client, no network surface. An HTTP/OAuth transport for shared, multi-tenant deployments is on the roadmap, not in this release.
You need streaming responses. Tool calls return whole values, not streams. Large messages are assessed and remediated in one call, not chunked over multiple responses.
You need to build the pacs.008 / pain.001 message. Out of scope; this
server fixes the addresses inside a message. Use
pacs008-mcp or
pain001-mcp to
generate and validate the message itself.
structured-address-fix-mcp uses Poetry and mise.
git clone https://github.com/sebastienrousseau/structured-address-fix-mcp.git && cd structured-address-fix-mcp
mise install
poetry install
poetry shellNote: the server depends on the core
structured-address-fixlibrary. Until it is published to PyPI, the dev dependency group installs it from the sibling checkout (../structured-address-fix); seeCONTRIBUTING.md.
A Makefile orchestrates the quality gates (kept in lockstep with CI):
make check # all gates (REQUIRED before commit): lint + type-check + test + examples
make test # pytest
make lint # ruff + black
make type-check # mypy --strict
make security # banditstructured-address-fix-mcp is a thin wrapper — every tool delegates to
structured_address_fix.services, where the defence-in-depth for XML parsing
(defusedxml) lives. Tools catch the documented domain, validation, and value
errors and return an {"error": ...} envelope per the suite convention; they
never propagate raw exceptions to the MCP client. Reporting practice, supported
versions, and the full supply-chain posture (SLSA L3 provenance, PEP 740
attestations, SBOMs, and the NIST SP 800-218 SSDF practice mapping) are
documented in SECURITY.md. Vulnerabilities go via GitHub
Private Vulnerability Reporting, not public issues.
README.md — this file
CHANGELOG.md — release notes
SECURITY.md — disclosure + supported versions
SUPPORT.md — how to get help
ROADMAP.md — what's next (HTTP/OAuth transport, observability, entitlement gating)
MAINTAINERS.md — who can merge
docs/quickstart.md — 10-minute install → first conversation
docs/deployment-cookbook.md — stdio client configs (Claude Desktop, Cursor, containers)
examples/ — runnable scripts
glama.json — Glama directory manifest
mcp-name: io.github.sebastienrousseau/structured-address-fix-mcp
Licensed under the Apache License, Version 2.0. Any contribution submitted for inclusion shall be licensed as above, without additional terms.
Contributions are welcome — see the contributing instructions. Thanks to all contributors.
Built on the structured-address-fix ISO 20022 postal-address library
and the Model Context Protocol Python SDK.
Score a single address against a policy and return its findings.
Args:
address: The postal address to assess.
policy_id: The policy to assess against (defaults to cbpr-2026).
as_of: The assessment date (YYYY-MM-DD); defaults to today.
country_hint: Country to assume when the address has none.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | The assessment date as an ISO 8601 string (YYYY-MM-DD). Decides cliff wording; defaults to today. | |
| address | Yes | An ISO 20022 postal address as a JSON object using canonical field names, e.g. {'street_name': 'Downing St', 'building_number': '10', 'post_code': 'SW1A 2AA', 'town_name': 'London', 'country': 'GB'} or {'address_lines': ['10 Downing St', 'London SW1A 2AA'], 'country': 'GB'}. | |
| policy_id | No | The policy to assess against (see list_policies). Defaults to 'cbpr-2026' when omitted. | |
| country_hint | No | ISO 3166-1 alpha-2 hint when the address has no country of its own. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral traits beyond these, so it meets the baseline but does not exceed it.
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 structured and front-loaded, but the Args section is somewhat repetitive of the schema. At 165 words, it is adequately concise but not 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?
Given the existence of an output schema, the description does not need to explain return values. All parameters are documented, and the description adds useful context about defaults and address format. The complexity (4 parameters, nested objects) is well-covered.
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 100%, so the description's Args section largely duplicates schema info. It adds minor value like default values and address format hints, but not enough to raise the score above the baseline.
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 'Score' and the resource 'a single address against a policy', and mentions 'return its findings'. This distinguishes from siblings like classify_address and list_policies.
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 for scoring addresses and mentions list_policies for policy reference, but does not explicitly state when to use this tool versus alternatives like assess_message or classify_address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess every addressed party in a pacs.008 / pain.001 message.
Args:
xml: The ISO 20022 message document.
policy_id: The policy to assess against (defaults to cbpr-2026).
as_of: The assessment date (YYYY-MM-DD); defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | An ISO 20022 message as XML. | |
| as_of | No | The assessment date as an ISO 8601 string (YYYY-MM-DD). Decides cliff wording; defaults to today. | |
| policy_id | No | The policy to assess against (see list_policies). Defaults to 'cbpr-2026' when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it assesses every addressed party and specifies default behavior, which is consistent with annotations and provides context beyond them.
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 extremely concise: three sentences for purpose and an argument list. It is front-loaded with the core action and contains no unnecessary 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?
Given the simple parameter set and presence of an output schema, the description covers the essential aspects: supported message types, defaults, and core function. It does not mention preconditions or error handling, but this is acceptable given the output schema.
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%, so parameters are well-described. The description adds value by specifying that the xml parameter must be a pacs.008 or pain.001 message, and clarifies defaults for policy_id and as_of. This complements the schema without redundancy.
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 ('assess'), the specific resource ('every addressed party in a pacs.008 / pain.001 message'), and distinguishes itself from siblings like assess_address (single address) and remediate_message (modification).
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 assessing a pacs.008 or pain.001 message, but does not explicitly state when to use this tool versus siblings like assess_address or remediate_message. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify a postal address as structured, hybrid, or unstructured.
Use this for a quick shape check before deciding whether to remediate.
For the specific compliance findings under a policy, use
``assess_address`` instead.
Args:
address: The postal address to classify.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | An ISO 20022 postal address as a JSON object using canonical field names, e.g. {'street_name': 'Downing St', 'building_number': '10', 'post_code': 'SW1A 2AA', 'town_name': 'London', 'country': 'GB'} or {'address_lines': ['10 Downing St', 'London SW1A 2AA'], 'country': 'GB'}. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, destructiveHint. The description adds minimal new context ('quick shape check'), but does not contradict annotations. Since annotations are comprehensive, a score of 3 is appropriate.
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?
Description is short and front-loaded with the main purpose. It includes a clear usage guide and an Args section. Every sentence is essential; no wasted 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?
Given the simple tool (one parameter, classification output), the description fully covers what an agent needs: purpose, usage context, and alternative. Output schema exists but is not required to be explained.
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 100% with a detailed explanation of the 'address' parameter. The description simply restates 'The postal address to classify,' adding no new meaning. Baseline of 3 applies.
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?
Description clearly states 'Classify a postal address as structured, hybrid, or unstructured.' The verb 'classify' and the specific categories make the purpose precise. It also distinguishes from sibling assess_address by indicating a quick shape check.
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?
Explicitly says 'Use this for a quick shape check before deciding whether to remediate.' and contrasts with 'For specific compliance findings, use assess_address instead.' This provides clear when-to-use and an alternative, meeting the highest standards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a finding code means and how to resolve it.
Args:
code: The finding code to explain.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | A finding code, e.g. 'SAF001' (see the codes in any assessment result). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint as true, and destructiveHint as false. The description adds that it also explains how to resolve the finding, which provides additional behavioral context beyond annotations.
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 sentences: one conveying the core purpose and one listing the parameter. Information is front-loaded and no waste, though the 'Args:' section is somewhat redundant with the schema.
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 tool with an output schema, the description adequately covers purpose and resolution behavior. Could mention prerequisites or data source but is sufficient given low complexity.
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 of the 'code' parameter including an example. The description's 'The finding code to explain' adds minimal new meaning, returning to 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 uses specific verbs 'explain' and 'resolve' with the resource 'finding code', clearly distinguishing it from sibling tools that assess or remediate.
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 tool versus alternatives like assess_address or assess_message. The description only states what it does without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report when the structured-address requirement binds, if it yet does.
Swift accepted a community request on 27 August 2026 and deferred every
payments change in Standards Release 2026, the structured-address
requirement among them. No replacement date has been set; Swift will
confirm timing by December 2026 at the latest.
``date`` is therefore ``None``. It is left null rather than filled with
the withdrawn date because an agent reading this hands the answer to
somebody planning a migration, and a date with no force is worse than no
date at all. The requirement itself was agreed by the community in 2023
and stands: ``status`` says deferred, not withdrawn.
The deferral is Swift's, and covers CBPR+. Domestic market
infrastructures set their own timing and several were aligned to the same
November date; check the schemes you settle through rather than assuming
they moved with Swift.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses that ``date`` is None, that null is intentionally preferred over a withdrawn date, and that ``status`` is deferred rather than withdrawn. This is valuable behavioral context that prevents the agent from fabricating a date or mischaracterizing the requirement.
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 purpose is front-loaded in the first sentence, and the subsequent paragraphs earn their place by explaining the deferral, the null semantics, and the domestic-scope caveat. It is wordier than a simple lookup might need, but no sentence is filler given the nuanced context the agent must understand.
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?
With zero parameters, existing annotations, and an output schema, the description supplies everything else needed: the current status, why the date is null, that the requirement stands, and how far the deferral extends. An agent can select, invoke, and interpret this tool correctly from the definition alone.
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?
The input schema has zero parameters, so there is nothing for the description to enrich on the input side. The description's references to ``date`` and ``status`` concern the output, and the empty schema already has full coverage.
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 first sentence, 'Report when the structured-address requirement binds, if it yet does,' names a specific action and resource, and the title ties it to the ISO 20022 cutover date. This clearly identifies what the tool does without ambiguity and separates it from the address-mutation and validation siblings.
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 draws an explicit scope boundary: the deferral is Swift's and covers CBPR+, while domestic market infrastructures set their own timing. It advises checking the relevant schemes rather than assuming they moved with Swift, which gives the agent useful when-not guidance, though no alternative tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every available address policy (rulebook) with its tier.
Use this first to discover the ``policy_id`` values the other tools
accept (e.g. ``cbpr-2026``, ``sepa``, ``hvps-plus``,
``generic-structured``).
Returns a list of ``{"id": ..., "title": ..., "tier": ...}`` objects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the return format (list of objects with id, title, tier), which is useful. No side effects or auth needs are mentioned, but none are expected for a read-only list. No contradictions.
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 extremely concise: two sentences with a brief example list. Every sentence adds value, and the most important usage guidance is placed first.
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 that there is an output schema (though not shown), the description provides a summary of return values. The tool is simple with no parameters, and the description covers purpose, usage, and output format sufficiently.
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?
The input schema has no parameters and 100% description coverage. The description does not need to add parameter details. Baseline 4 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 that the tool lists all available address policies with their tier. It uses specific verbs ('list') and resource ('address policies') and distinguishes from sibling tools which are about classification, assessment, and remediation.
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?
It explicitly tells the agent to use this tool first to discover policy_id values for other tools, providing concrete examples like 'cbpr-2026' and 'sepa'. This offers clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a country name or code to its ISO 3166-1 alpha-2 code.
Accepts English names, common local-language endonyms (Deutschland,
España, Nippon), everyday aliases (UK, USA, Holland, UAE), and existing
2- or 3-letter codes. Matching is case-, accent-, and punctuation-
insensitive.
Args:
country_name_or_code: The country name, alias, or code to resolve.
Returns a ``{"country_code": "DE"}`` object, or ``{"error": ...}`` when
the input matches no known country.
| Name | Required | Description | Default |
|---|---|---|---|
| country_name_or_code | Yes | A country name, endonym, alias, or 2/3-letter code, e.g. 'Deutschland', 'UK', 'U.S.A.', 'DEU'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses important behavior: matching is case-, accent-, and punctuation-insensitive, and unmatched input yields an error object rather than throwing or guessing. This gives the agent accurate expectations about edge cases.
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 well-structured: a one-sentence definition, accepted inputs, matching behavior, an Args section, and a Returns section. Every sentence earns its place and the most important purpose is front-loaded.
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 tool with annotations and an output schema, the description covers purpose, accepted input variety, normalization rules, and error behavior. Nothing needed for correct invocation 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?
The schema already fully documents the single parameter with examples, so the baseline is 3. The description adds meaning by clarifying normalization behavior and by listing the broader categories of accepted aliases, which helps the agent craft valid inputs.
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 opening sentence uses a specific verb and resource: 'Resolve a country name or code to its ISO 3166-1 alpha-2 code.' It clearly distinguishes itself from the address/message-related sibling tools by domain and by stating its exact transformation.
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 clearly identifies what inputs are accepted (English names, local endonyms, aliases, 2/3-letter codes) and what happens on failure. It does not name an alternative tool or explicitly say 'use this when,' but its acceptance criteria make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a free-text address into ISO 20022 postal fields.
Uses the optional libpostal statistical parser (the ``postal`` binding,
which requires the system libpostal C library) when it is installed,
and otherwise degrades to this repo's own regex heuristics. Either way
the address is mapped to ``StrtNm``, ``BldgNb``, ``PstCd``, ``TwnNm``
and ``Ctry``. The result's ``parser`` field is ``"libpostal"`` or
``"fallback"`` so callers know which path ran. Runs purely on CPU with
no network or filesystem access, though the libpostal path depends on
an external C library.
Args:
unstructured_address: The free-text address to parse.
country_hint: Country to assume when the text names none.
Returns ``{"parser": ..., "address": {StrtNm, BldgNb, PstCd, TwnNm,
Ctry}}``.
| Name | Required | Description | Default |
|---|---|---|---|
| country_hint | No | An ISO 3166-1 alpha-2 hint (or country name) used when the address text does not name its own country. | |
| unstructured_address | Yes | A single free-text postal address, e.g. '12 Rue de Rivoli, 75001 Paris, France'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it discloses the optional libpostal C library dependency, the fallback regex path, the 'parser' field that reports which path ran, and that it runs purely on CPU with no network or filesystem access. This is rich, useful context that the annotations alone do not provide.
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 well-structured and front-loads the core purpose, with separate sentences for behavior, output mapping, and operational constraints. It is slightly longer than strictly necessary because the Args and Returns sections partially duplicate the schema and output schema, but every section remains readable and purposeful.
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 the strong annotations, full schema coverage, and existing output schema, the description is complete enough for an agent to call this tool correctly. It covers input requirements, fallback behavior, dependency constraints, and output shape, leaving no critical gap for safe invocation.
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 100%, so the schema already fully documents both parameters. The description's Args section largely restates the schema's meaning without adding significant new detail, so it does not elevate the parameter semantics beyond the baseline.
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 a specific verb and resource: 'Parse a free-text address into ISO 20022 postal fields.' It also lists the concrete output fields (StrtNm, BldgNb, PstCd, TwnNm, Ctry), making the operation easy to understand. It does not explicitly contrast with sibling tools such as classify_address or assess_address, so it falls short of a 5.
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 gives clear context: this tool is for parsing a free-text address into structured postal fields, and it explains that it can run with libpostal or fall back to regex heuristics. It does not explicitly state when to use this tool instead of sibling tools or when not to use it, so it lacks exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the patch operations remediation would apply (a dry run).
Args:
xml: The ISO 20022 message document.
policy_id: The policy to remediate for (defaults to cbpr-2026).
as_of: The assessment date (YYYY-MM-DD); defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | An ISO 20022 message as XML. | |
| as_of | No | The assessment date as an ISO 8601 string (YYYY-MM-DD). Decides cliff wording; defaults to today. | |
| policy_id | No | The policy to assess against (see list_policies). Defaults to 'cbpr-2026' when omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces this by explicitly stating it is a 'dry run', meaning no side effects. This adds behavioral context beyond annotations, clarifying the tool's non-destructive nature.
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 short and to the point, with a clear one-sentence purpose followed by a bulleted list of arguments. No redundant information. It is appropriately sized and well-structured, though it could be slightly more concise by removing the 'Args:' label.
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 the presence of an output schema (not shown), the description does not need to explain return values. However, the description does not hint at the output format (e.g., list of operations). For a tool that returns patch operations, some context on the structure would improve completeness. Overall adequate but not fully complete.
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 100%, so the schema already documents all parameters. The description's parameter explanations closely mirror the schema descriptions (e.g., 'The ISO 20022 message document' vs 'An ISO 20022 message as XML'). The value added over the schema is minimal, so a baseline score of 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 starts with 'Return the patch operations remediation would apply (a dry run).' This clearly states the tool provides a dry-run preview of remediation patches. The verb 'preview' and resource 'patch' are unambiguous, and the tool is distinguished from siblings like 'remediate_message' which applies the patch.
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 gives no explicit guidance on when to use this tool versus alternatives. Sibling tools like 'assess_message' and 'remediate_message' exist, but no comparison or context is provided. Users are left to infer the appropriate use case for a dry run vs actual remediation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose the compliant form of an address, with explained changes.
Returns the findings, the before/after addresses, and the patch
operations (each carrying the finding it resolves, the source token,
and a confidence score).
Args:
address: The postal address to remediate.
policy_id: The policy to remediate for (defaults to cbpr-2026).
as_of: The assessment date (YYYY-MM-DD); defaults to today.
country_hint: Country to assume when the address has none.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | The assessment date as an ISO 8601 string (YYYY-MM-DD). Decides cliff wording; defaults to today. | |
| address | Yes | An ISO 20022 postal address as a JSON object using canonical field names, e.g. {'street_name': 'Downing St', 'building_number': '10', 'post_code': 'SW1A 2AA', 'town_name': 'London', 'country': 'GB'} or {'address_lines': ['10 Downing St', 'London SW1A 2AA'], 'country': 'GB'}. | |
| policy_id | No | The policy to assess against (see list_policies). Defaults to 'cbpr-2026' when omitted. | |
| country_hint | No | ISO 3166-1 alpha-2 hint. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds what the tool returns (findings, before/after, patch operations) and explains parameters. No contradictions, but no additional behavioral traits beyond annotations.
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?
Description is short and front-loaded with the main purpose. The Args section is succinct. No unnecessary 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?
Output schema exists, so return values are covered. Annotations and schema provide safety context. However, usage guidance is missing, which would improve completeness.
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 100%, and the description's Args section adds informal examples (e.g., address format with street_name, building_number). This adds some value, but the schema already provides detailed descriptions for all parameters.
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 it proposes the compliant form of an address with explained changes. Verb+resource is specific. However, it does not differentiate from sibling tools like assess_address which might also check compliance.
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 tool versus alternatives like assess_address or classify_address. The description only explains parameters, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess and remediate every addressed party in a message.
Args:
xml: The ISO 20022 message document.
policy_id: The policy to remediate for (defaults to cbpr-2026).
apply: Whether to apply the operations and return patched XML.
as_of: The assessment date (YYYY-MM-DD); defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | An ISO 20022 message as XML. | |
| apply | No | When true, apply the operations and return the patched XML in 'patched_xml'. | |
| as_of | No | The assessment date as an ISO 8601 string (YYYY-MM-DD). Decides cliff wording; defaults to today. | |
| policy_id | No | The policy to assess against (see list_policies). Defaults to 'cbpr-2026' when omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, implying no modification, but the description discusses applying operations and returning patched XML when apply=true, which contradicts the annotation. The description does not reconcile this inconsistency.
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 concise with a clear summary and parameter list. No fluff, but structure is functional rather than optimized for quick scanning.
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 the contradiction and lack of detail about what remediation entails (e.g., adding tags, modifying content), the description feels incomplete. Output schema exists but doesn't compensate for behavioral gaps.
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%, so the schema fully documents parameters. The description adds context about the default policy and applying operations, but otherwise repeats schema info without significant added meaning.
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 it assesses and remediates every addressed party in a message. It distinguishes from sibling tools like assess_address and remediate_address by operating on the whole message, but it does not explicitly differentiate from assess_message or provide a sibling comparison.
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 tool versus alternatives such as assess_message or remediate_address. The description mentions default policy and assessment date but does not contextualize usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a street line into street name, building, and sub-building.
Handles the leading-number convention (US/UK: ``10 Downing Street``),
the trailing-number convention (much of continental Europe: ``Rue de
Rivoli 12``), and an optional sub-building marker (``Flat 2``, ``Apt
3B``, ``Suite 400``). When no building number is present the whole line
is returned as ``street_name`` (never an error).
Args:
street_line: The free-text street line to split.
Returns ``{"street_name", "building_number", "sub_building"}`` with
``building_number`` / ``sub_building`` set to ``null`` when absent.
| Name | Required | Description | Default |
|---|---|---|---|
| street_line | Yes | A single free-text street line, e.g. '10 Downing Street', 'Rue de Rivoli 12', or 'Flat 2, 221B Baker Street'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses concrete parsing behavior: support for both numbering conventions, optional sub-building markers, null outputs when absent, and never returning an error for a missing building number. This is exactly the kind of non-obvious behavior an agent needs.
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 compact, front-loaded with the operation, and uses a clear Args/Returns structure. Every sentence adds either input semantics, output semantics, or edge-case behavior.
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 single-parameter pure function with full schema coverage and annotations, the description covers input, output shape, null conventions, and edge cases. The existing output schema also covers return values, so nothing necessary 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 100% and the schema already names the parameter with examples. The description's Args line adds little beyond restating that street_line is free-text to split, so the baseline of 3 applies.
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 ('split'), resource ('street line'), and the three output components. It clearly distinguishes itself from sibling address tools by focusing on splitting into street_name, building_number, and sub_building.
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 gives clear context for when it applies by naming the two numbering conventions and the no-building-number case, so an agent can recognize the right input shape. It does not explicitly compare against siblings such as parse_address_libpostal, but no misleading guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an address's post_code against a country's format policy.
Supported policies: US (5-digit ZIP or ZIP+4), GB (alphanumeric UK
postcode), DE and FR (5 digits), JP (3-then-4 digits). The address is a
canonical-field JSON object; only its ``post_code`` is inspected.
Args:
address: The structured address whose post_code to validate.
country_code: The alpha-2 code selecting the policy.
Returns ``{"is_compliant": bool, "policy_errors": [...]}``. An unknown
country or a missing post_code is reported as non-compliant with a
descriptive error rather than raising.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | An ISO 20022 postal address as a JSON object using canonical field names, e.g. {'street_name': 'Downing St', 'building_number': '10', 'post_code': 'SW1A 2AA', 'town_name': 'London', 'country': 'GB'} or {'address_lines': ['10 Downing St', 'London SW1A 2AA'], 'country': 'GB'}. | |
| country_code | Yes | The ISO 3166-1 alpha-2 code whose post_code policy to apply (US, GB, DE, FR, JP). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it states that only post_code is inspected, and that unknown country or missing post_code returns non-compliant with a descriptive error rather than raising. This is exactly the kind of extra behavioral context that helps an agent.
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 well-structured: a one-sentence summary, a compact list of supported policies, a scope note, and a clear Args/Returns breakdown. Every sentence contributes operational knowledge and the most important information is front-loaded.
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 validation tool with two required parameters, full schema descriptions, rich annotations, and an explicit return format, the description covers all essential operational details: supported formats, input shape, return keys, and error behavior. There is no significant missing information an agent would need to invoke it correctly.
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?
The schema has 100% parameter description coverage, so the baseline is 3. The description adds meaningful value by enumerating the exact country code formats (e.g., US 5-digit ZIP or ZIP+4, GB alphanumeric) and emphasizing that only the post_code field of the address is considered. This supplements the schema descriptions usefully.
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 opens with a specific verb-resource pair: 'Validate an address's post_code against a country's format policy.' It also clarifies the exact scope (only post_code is inspected) and lists the supported country policies, making the tool's role distinct from siblings like assess_address or remediate_address.
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 clearly states the supported policies (US, GB, DE, FR, JP) and the condition of the tool—it only inspects post_code, not other address fields. It gives adequate context for when to use it, but it does not explicitly mention alternatives or state when not to use it relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools are clearly separated by scope (single address vs message, assess vs remediate), but preview_patch substantially overlaps remediate_message with apply=false, and the parsing helpers have fuzzy boundaries. Descriptions and cross-references help, but an agent could still select the wrong tool in several cases.
All tool names follow the same verb_noun snake_case convention: list_, assess_, remediate_, preview_, explain_, get_, normalize_, split_, validate_, parse_. The pattern is predictable and makes the action and target easy to infer.
Thirteen tools is within the ideal range for a domain covering policy discovery, assessment, remediation, patch preview, explanation, and address parsing helpers. The count feels appropriate for the breadth of the structured-address-fix workflow, not padded or excessive.
The tool surface covers the core workflow well: list policies, assess messages and addresses, preview and apply remediation, explain findings, and normalize/parse address components. Minor gaps exist, such as no way to enumerate all finding codes and parse_address_libpostal not mapping every ISO 20022 sub-field, but agents can work around these.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastienrousseau/structured-address-fix-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server