Acmt001 Mcp

io.github.sebastienrousseauPublished by GitHub account sebastienrousseauv0.0.15Updated Nov 3, 2026

MCP server for ISO 20022 acmt.001 account management message generation and validation.

VerifiedSTDIODesktop onlyFinanceDeveloper Tools

Overview

AI-generated overview

Local MCP server that lets an assistant discover, validate and generate ISO 20022 acmt account management XML messages.

What you can do
  • Discover supported acmt message types and their human names
  • Inspect required fields and full input JSON Schema for a message type
  • Validate batches of flat account records against a message type's schema
  • Validate single financial identifiers such as IBAN, BIC or LEI
  • Generate XSD-validated acmt XML from records held in memory
  • Look up an LEI in the live GLEIF register over the network
When to use it
Useful when an assistant has to build or check ISO 20022 account management messages (account opening, maintenance, closing, identification, switching) from structured account data, or needs quick IBAN, BIC or LEI checks while working on banking data.
Requirements
Runs locally as a Python 3.11+ package installed with pip; the core acmt001 library may need to be installed from source first. Default transport is stdio, with optional streamable HTTP or SSE on 127.0.0.1:8000. The online LEI lookup needs the online extra and network access to the GLEIF API.
Before you install
The HTTP transports have no authentication of their own, so bind loopback or place them behind a trusted gateway. The online LEI tool sends the identifier to the public GLEIF API. For many single-account message types, generate_message renders only the first record, so a batch can silently produce one message; validate first and check output size.

Installation

In SourceWeft

  1. Open Acmt001 Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

acmt001-mcp: An MCP Server for ISO 20022 Account Management

[acmt001-mcp banner]

[Build] [Registry] [Docs] [OpenSSF Scorecard] [OpenSSF Best Practices] [License: Apache-2.0 OR MIT] [Python 3.11 or newer] [Glama MCP server listing]

A Model Context Protocol server that exposes the acmt001 ISO 20022 Account Management library as tools for AI agents and assistants — discover message types, inspect input schemas, validate records and financial identifiers, and generate validated XML, all from your favourite MCP client.

Latest release: v0.0.15: 7 MCP tools over stdio, streamable HTTP or SSE, all backed by the shared acmt001.services layer, for Python 3.11+. Ships in lockstep with acmt001 0.0.15; every CI and image install is hash-pinned, and the tools are fuzzed. See what's new →

[acmt001-mcp Demo]


Contents

Overview

The Model Context Protocol (MCP) is an open standard that lets AI agents and assistants discover and call external tools in a uniform way. acmt001-mcp is an MCP server that turns the acmt001 library into a set of first-class agent tools, so an assistant can generate and validate ISO 20022 acmt Account Management XML messages — the standardised instructions, confirmations, and reports that govern the lifecycle of a bank account (opening, maintenance, closing, identification, and switching) — directly from a conversation.

Every tool is a thin, typed wrapper over acmt001.services — the single shared facade also used by the CLI and REST API — so all interfaces behave identically. Tools return JSON-serialisable data; on a validation error they return an {"error": ...} payload rather than raising.

This package is part of the acmt001 suite — a set of independently installable packages that share the acmt001.services layer:

  • acmt001 — the core library (CLI + REST API)
  • acmt001-mcp — this package, the Model Context Protocol server
  • acmt001-lsp — the Language Server Protocol server for editors
mermaid
flowchart LR    A["MCP client<br/>(Claude Desktop, IDE, agent)"] -->|stdio| B["acmt001-mcp"]    B -->|delegates to| C["acmt001.services"]    C -->|render + validate| D["ISO 20022 acmt XML"]

Install

acmt001-mcp runs on macOS, Linux, and Windows and requires Python 3.11+ and pip. It pulls in the core acmt001 library and the MCP SDK automatically.

sh
python -m pip install acmt001-mcp

Note: while the core acmt001 library is not yet on PyPI, install it from source first:

sh
python -m pip install "git+https://github.com/sebastienrousseau/acmt001.git"python -m pip install acmt001-mcp
Using an isolated virtual environment (recommended)
sh
python -m venv venvsource venv/bin/activate        # macOS/Linuxvenv\Scripts\activate           # Windowspython -m pip install -U acmt001-mcp

Quick Start

Launch the server over stdio (the default transport):

sh
acmt001-mcp

Register it with any MCP client (e.g. Claude Desktop) by adding it to the client's configuration:

json
{  "mcpServers": {    "acmt001": { "command": "acmt001-mcp" }  }}

The agent can then call the tools below to validate account data and generate ISO 20022 messages on demand.

Transports

One command line, three transports:

CommandTransportEndpointProtocol revisions
acmt001-mcpstdiothe client spawns the process2026-07-28, 2025-11-25
acmt001-mcp --transport streamable-httpStreamable HTTPhttp://127.0.0.1:8000/mcp2026-07-28 (stateless, server/discover) and 2025-11-25 (initialize, Mcp-Session-Id) on the same endpoint; responses stream as server-sent events, GET opens the server-to-client stream
acmt001-mcp --transport sseHTTP+SSE (2024-11-05)http://127.0.0.1:8000/sse and /messages/for clients that still expect the older transport

--host and --port change the bind address (defaults 127.0.0.1 and 8000). The HTTP transports carry no authentication of their own: bind loopback, or put the server behind a gateway you trust before binding a routable address. Every release is verified over streamable HTTP with scout in both protocol eras and over SSE with the MCP SDK client; see ADR 0001.

json
{  "mcpServers": {    "acmt001": { "url": "http://127.0.0.1:8000/mcp" }  }}

Tools

All tools delegate to the shared acmt001.services layer, so they behave identically to the CLI and REST API.

  • list_message_types — List the 34 supported acmt message types
  • get_required_fields — Required input fields for a message type
  • get_input_schema — Full input JSON Schema for a message type
  • validate_records — Validate flat records against a message type
  • validate_identifier — Validate an IBAN, BIC, or LEI
  • generate_message — Generate a validated acmt XML message
  • verify_lei_online — Look an LEI up in the live GLEIF register (needs the online extra)

Using the tools

You can invoke the tools in-process — without a transport — straight through the server instance. This mirrors what an agent receives over stdio. The runnable version of this snippet lives in examples/mcp_tools.py.

python
import asyncio
from acmt001_mcp.server import server
# A single flat account-opening record.record = [    {        "msg_id": "ACMT-MSG-0001",        "creation_date_time": "2026-01-15T10:30:00",        "process_id": "ACMT-PRC-0001",        "account_id": "GB29NWBK60161331926819",        "account_currency": "EUR",        "account_name": "Treasury Operating Account",        "account_type_cd": "CACC",        "account_servicer_bic": "NWBKGB2LXXX",        "account_owner_name": "Acme Embedded Finance Ltd",        "account_owner_country": "GB",        "org_full_legal_name": "Acme Embedded Finance Limited",        "org_country_of_operation": "GB",        "org_id_lei": "5493001KJTIIGC8Y1R12",    }]

async def main() -> None:    async def call(name, args):        result = await server.call_tool(name, args)        content = result[0] if isinstance(result, tuple) else result        return content[0].text if content else ""
    # Validate an identifier.    print(await call("validate_identifier",                     {"kind": "lei", "value": "5493001KJTIIGC8Y1R12"}))    # -> {"kind": "lei", "value": "5493001KJTIIGC8Y1R12", "valid": true}
    # Generate a validated ISO 20022 Account Opening Request.    xml = await call("generate_message",                     {"message_type": "acmt.007.001.05", "records": record})    print(xml[:46])  # -> <?xml version="1.0" encoding="UTF-8"?> ...

asyncio.run(main())

Run it directly:

sh
python examples/mcp_tools.py

Benchmarks

sh
python benches/bench_tool_dispatch.py           # full runpython benches/bench_tool_dispatch.py --quick   # what CI runs

The benchmark measures what an agent waits for: the dispatch floor (list_message_types, around a microsecond), the metadata lookups used to build a request, and the two batch tools side by side.

The result worth knowing is the asymmetry between those two. validate_records checks every record, so it is linear in batch size. generate_message, for a single-account message type like the default acmt.007.001.05, renders only the first record — twenty-seven of the thirty-four templates work this way. So validating a hundred records and generating from them costs roughly 260 ms of validation against 6 ms of generation, and returns one message rather than a hundred.

That is correct ISO 20022 behaviour and a real trap when batching, which is why the benchmark prints output size beside the timings: flat bytes across growing input is what tells you the rest of the batch was not rendered. See docs/benchmarks.md.

Documentation

Development

acmt001-mcp uses Poetry and mise.

bash
git clone https://github.com/sebastienrousseau/acmt001-mcp.git && cd acmt001-mcpmise installpoetry installpoetry shell

This package depends on the core acmt001 library. Until it is on PyPI, install it from source first: pip install "git+https://github.com/sebastienrousseau/acmt001.git".

A Makefile orchestrates the quality gates (kept in lockstep with CI):

bash
make check        # all gates (REQUIRED before commit)make test         # pytest, 100% line and branch coveragemake lint         # ruff + blackmake type-check   # mypy --strictmake doc-coverage # interrogate, 100% docstringsmake mutate       # mutmut over the tool handlers, gated on the scoremake docs         # Sphinx site, warnings are errors

The property-based tests (Hypothesis) run as part of make test; set HYPOTHESIS_PROFILE=mutation for the slimmer profile the mutation run uses.

Related MCP Servers

Part of the ISO 20022 MCP Suite — open-source, Apache-2.0 licensed MCP servers for banking and financial-services AI agents:

ServerPurpose
pain001-mcpGenerate & validate ISO 20022 pain.001 payment files (v03–v12, pain.008, SEPA) with rulebook checks
pacs008-mcpGenerate, validate, parse & scheme-check ISO 20022 pacs.008 FI-to-FI credit transfers + Nov-2026 address linting
camt053-mcpParse & reconcile ISO 20022 camt.053 bank-to-customer statements — CBPR+/HVPS+ ready
bankstatementparser-mcpParse bank statements (BAI2, MT940/MT942, CAMT.053, OFX, CSV) into structured transactions
noyalib-mcpLossless YAML 1.2 parsing, formatting & validation (Rust, 100% spec compliance)

MCP Registry

mcp-name: io.github.sebastienrousseau/acmt001-mcp


License

Licensed under the Apache License, Version 2.0. Any contribution submitted for inclusion shall be licensed as above, without additional terms.

Contribution

Contributions are welcome — see the contributing instructions. Thanks to all contributors.

Acknowledgements

Built on the acmt001 ISO 20022 Account Management library and the Model Context Protocol Python SDK.

Source: README.md at commit 8bca7d6

Tools

7

list_message_types

List acmt message types

List every supported ISO 20022 acmt message type and its human name. Use this first, before any generation or validation call, to discover the exact ``message_type`` strings this server accepts (e.g. ``acmt.001.001.08`` Account Opening Instruction). Do not use it to fetch a type's fields or schema -- call ``get_required_fields`` or ``get_input_schema`` for that. Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one per supported message type (e.g. ``acmt.001.001.08``).

Takes no parameters.

get_required_fields

Get required fields

List only the required input field names for an acmt message type. Use this for a quick checklist of the mandatory columns before building account records. When you need full type/format constraints (not just which fields are required), call ``get_input_schema`` instead. Args: message_type: A supported ISO 20022 acmt message type.

Parametersmessage_typerequired

get_input_schema

Get input JSON Schema

Return the full JSON Schema for a message type's flat input record. Use this to learn every field, its type, and its constraints before assembling records, or to drive a form/UI. For just the required-field names use ``get_required_fields``; to actually check records against this schema use ``validate_records``. Args: message_type: A supported ISO 20022 acmt message type.

Parametersmessage_typerequired

validate_records

Validate records against schema

Validate flat account records against a message type's input JSON Schema. Use this before ``generate_message`` to catch structural/type errors per record and get a row-by-row error report. This checks JSON-Schema shape only; to validate a single financial identifier in isolation use ``validate_identifier``. Returns a report ``{"valid": bool, "total": int, "valid_count": int, "errors": [...]}``. Args: message_type: A supported ISO 20022 acmt message type. records: One or more flat account records to validate.

Parametersrecordsrequiredmessage_typerequired

validate_identifier

Validate IBAN, BIC or LEI

Validate a single financial identifier (IBAN, BIC, or LEI). Use this for a one-off identifier check with a clear pass/fail. To validate identifiers embedded across a whole batch of account records, prefer ``validate_records`` rather than calling this per field. Returns ``{"kind": str, "value": str, "valid": bool}``. Args: kind: One of ``"iban"``, ``"bic"``, or ``"lei"`` (case-insensitive). value: The identifier value to check.

Parameterskindrequiredvaluerequired

generate_message

Generate acmt XML from records

Generate a validated ISO 20022 acmt XML message from in-memory records. This is the primary generation tool: pass account records you already hold in memory and receive an XSD-validated XML document; no file is written. Run ``validate_records`` first to surface record-level errors, and ``list_message_types`` to confirm the ``message_type`` string. Returns the validated XML document as a string, or an ``{"error": ...}`` payload (serialized) if generation fails. Args: message_type: A supported ISO 20022 acmt message type. records: One or more flat account records.

Parametersrecordsrequiredmessage_typerequired

verify_lei_online

Verify a LEI against the live GLEIF register

Verify a LEI against the live GLEIF register (reaches the network). Unlike ``validate_identifier``, which checks an LEI's format and check digits entirely offline, this tool performs a live HTTP GET against the public GLEIF REST API (``api.gleif.org``) to confirm the LEI is actually registered and to return the registered entity's details. It therefore requires network access and is marked open-world. Requires the optional ``online`` extra (``pip install acmt001-mcp[online]``) for the ``httpx`` HTTP client; without it a graceful ``{"error": ...}`` is returned rather than raising. Returns a dict with the ``lei``, registered ``legal_name``, entity ``status``, ``country``, and registration ``registration_status``, ``initial_registration_date``, ``last_update_date`` and ``next_renewal_date``. On failure returns ``{"error": ...}``: an ``LEI not found`` error for an unregistered LEI (HTTP 404), or a ``GLEIF API unavailable`` error for any other non-200 response or a transport/connection error. Args: lei_code: A 20-character ISO 17442 Legal Entity Identifier.

Parameterslei_coderequired

Version history

5
  1. v0.0.15LatestOct 29, 2026
  2. v0.0.13Oct 26, 2026
  3. v0.0.11Oct 4, 2026
  4. v0.0.10Oct 4, 2026
  5. v0.0.9Sep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts