structured-address-fix-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_policiesA | List every available address policy (rulebook) with its tier. |
| classify_addressA | Classify a postal address as structured, hybrid, or unstructured. |
| assess_addressA | Score a single address against a policy and return its findings. |
| assess_messageA | Assess every addressed party in a pacs.008 / pain.001 message. |
| remediate_addressA | Propose the compliant form of an address, with explained changes. |
| remediate_messageC | Assess and remediate every addressed party in a message. |
| preview_patchA | Return the patch operations remediation would apply (a dry run). |
| explain_findingA | Explain what a finding code means and how to resolve it. |
| get_cutover_dateA | Report when the structured-address requirement binds, if it yet does. |
| normalize_country_codeA | Resolve a country name or code to its ISO 3166-1 alpha-2 code. |
| split_street_and_buildingA | Split a street line into street name, building, and sub-building. |
| validate_postal_policyA | Validate an address's post_code against a country's format policy. |
| parse_address_libpostalA | Parse a free-text address into ISO 20022 postal fields. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review_address_remediation | Guide an agent through reviewing a postal-address remediation. Teaches the end-to-end tool workflow -- classify, assess, remediate, then preview the patch -- and stresses hand-checking low-confidence fixes before they are accepted. Args: policy_id: The policy to frame the review against (defaults to cbpr-2026). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| policies_resource | The catalog of address policies as JSON (mirrors list_policies). |
| cutover_date_resource | The binding cutover date as JSON (mirrors get_cutover_date). |
TDQS
Scored across 13 tools
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.