iso20022-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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Search the ISO 20022 catalogue by use-case, message type or keyword (e.g. 'reconciliation', 'make a payment', 'pacs.008') and get the matching message types, their family, and which package provides them. When to use: First, to discover which ISO 20022 message type fits your workflow and which backing package supplies it. Not for: Inspecting fields or checking records once the message type is known; 'describe' and 'validate' cover those. Behavior: Pure in-memory lookup; read-only and idempotent with zero network or filesystem I/O. |
| list_familiesA | List every ISO 20022 family the gateway routes to (pain, pacs, camt, acmt): its capabilities, backing package, and whether that package is installed in this environment. When to use: Use to check environment readiness and verify whether optional backing packages (pain001-mcp, pacs008-mcp, camt053-mcp, acmt001-mcp) are installed. Not for: Searching specific schemas; 'search' and 'describe' cover those. Behavior: Pure in-memory introspection; read-only and idempotent. |
| list_serversA | List the whole ISO 20022 suite the gateway knows: the message families (pain/pacs/camt/acmt), the Exceptions & Investigations messages (camt.056/camt.029), and the specialized servers (reconciliation, agent-payment bridge) with what each does. When to use: Use to discover available specialized servers across the suite and route cross-cutting payments workflows. Not for: Building or reading messages; the gateway tools 'generate', 'parse' and 'validate' do that. Behavior: Pure in-memory catalog listing; read-only and idempotent. |
| describeA | Describe a message type: its required fields and input JSON Schema, resolved from the family's backing server. When to use: After 'search', to obtain the schema and required field names for the flat records that 'validate' and 'generate' take. Not for: Raw XML payloads; 'parse' reads those. Behavior: Read-only, idempotent resolution from local schemas. Errors return a structured {'error': ...} payload rather than raising. |
| validateA | Validate records for a message type against its JSON Schema, via the family's backing server. When to use: Ahead of 'generate', to verify record field types, required fields, date formats (YYYY-MM-DD), and IBAN/BIC constraints without generating XML. Not for: Raw XML documents; the backing server's XSD validation tools and 'parse' handle those. Behavior: Pure deterministic validation; read-only and idempotent with zero network I/O. |
| generateA | Generate a validated ISO 20022 XML message from records; the XML document is returned in the 'xml' key. On failure the 'error' value lists every missing or invalid field at once — fix them all and retry once. When to use: Outbound initiation and interbank messages (pain.001, pacs.008, acmt.001, camt.056). Not for: Inbound statements (camt.053); they have no generator and return an explanatory error. Behavior: Pure transformation; read-only and idempotent. |
| parseA | Parse an inbound ISO 20022 XML message into structured data. Parse coverage is per-family: pacs (e.g. pacs.008) and camt (e.g. camt.053) only. The initiation families pain and acmt are outbound-only — they have NO parser here, so a generate→parse round-trip for pain.001 or acmt.001 fails; 'validate' or the backing server's XSD validation checks those instead. When to use: Use to extract structured transactions, entries, debtor/creditor data, and balances from inbound messages (pacs.008 customer credit transfers, camt.053 statements). Not for: Outbound initiation families (pain.001, acmt.001). Behavior: Pure in-memory XML parsing; read-only and idempotent. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| route_iso20022_task | Guided prompt teaching the model how to route a task across the gateway. The MCP client sends this to the model to establish the recommended meta-tool order so it uses the gateway correctly instead of guessing a message type. Args: goal: The payments task in plain language. Returns: A prompt string instructing the model how to proceed. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| families_resource | Expose the routed ISO 20022 families as a JSON resource. Returns the same family catalogue as the ``list_families`` tool (:func:`registry.family_summary`) -- each family's capabilities, backing package, and whether that package is installed here -- serialised as JSON, so an agent can load the suite map as reference context without a tool call. Mirrors the ``list_families`` tool, which takes no arguments and cannot fail, so no error envelope is needed. |
| servers_resource | Expose the full ISO 20022 suite map as a JSON resource. Returns the same payload as the ``list_servers`` tool (:func:`registry.list_all_servers`) -- message families, the Exceptions & Investigations messages, and the specialised servers -- serialised as JSON. Mirrors the ``list_servers`` tool, which takes no arguments and cannot fail, so no error envelope is needed. |
TDQS
Scored across 7 tools
The core transform tools (search, describe, validate, generate, parse) each target a distinct action and are hard to confuse. However, list_families and list_servers both perform catalogue-style listing and could be misselected, and search overlaps with them at the discovery level. The explicit 'When to use / Not for' notes mitigate this, but the boundary between the three listing/discovery tools is not perfectly crisp.
Most names are single imperatives (search, describe, validate, generate, parse) with a consistent snake_case, verb-first pattern for the two listing tools (list_families, list_servers). The mix of bare verbs and verb_noun is a minor deviation but remains predictable and readable.
Seven tools is well-scoped for an ISO 20022 gateway spanning discovery, schema description, validation, generation, and parsing. Each tool earns its place with no redundant entries.
The surface covers the discovery-to-transform lifecycle (search, describe, validate, generate, parse) and documents direction-specific limits. Minor gaps exist—pain/acmt messages have no parser and camt.053 has no generator—but these are intentional, documented, and covered by backing-server XSD validation, so agents are not left at a dead end.