What can you do with this server?

acmt001-mcp is an MCP server that enables AI agents to discover, validate, and generate ISO 20022 Account Management (acmt) XML messages through six tools: * List supported message types (list_message_types): Discover all 34 supported acmt message types (e.g., acmt.001.001.08 Account Opening Instruction) and their human-readable names — the recommended starting point. * Get required fields (get_required_fields): Retrieve a checklist of mandatory input field names for any supported message type, useful for building account records before generation. * Get full input schema (get_input_schema): Fetch the complete JSON Schema for a message type, including all fields, types, and constraints — ideal for form generation or pre-validation. * Validate account records (validate_records): Check one or more flat account records against a message type's schema and receive a row-by-row error report, catching structural/type errors before XML generation. * Validate financial identifiers (validate_identifier): Perform a pass/fail check on a single IBAN, BIC/SWIFT code, or LEI, returning {"kind": ..., "value": ..., "valid": bool}. * Generate ISO 20022 XML messages (generate_message): Transform flat account records into a fully XSD-validated ISO 20022 acmt XML document — no file I/O required; returns the XML string or an error payload if generation fails.

acmt001-mcp

by sebastienrousseau

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

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

acmt001-mcp banner

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.5 — six MCP tools over stdio, all backed by the shared acmt001.services layer, for Python 3.10+. See what's new →

Related MCP server: pacs008-mcp

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.

Website: https://acmt001.com
Source code: https://github.com/sebastienrousseau/acmt001-mcp
Bug reports: https://github.com/sebastienrousseau/acmt001-mcp/issues

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

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.10+ and pip. It pulls in the core acmt001 library and the MCP SDK automatically.

python -m pip install acmt001-mcp

Note: while the core acmt001 library is not yet on PyPI, install it from source first:
python -m pip install "git+https://github.com/sebastienrousseau/acmt001.git"
python -m pip install acmt001-mcp

python -m venv venv
source venv/bin/activate        # macOS/Linux
venv\Scripts\activate           # Windows
python -m pip install -U acmt001-mcp

Quick Start

Launch the server over stdio (the FastMCP default transport):

acmt001-mcp

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

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

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

Using the tools

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 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:

python examples/mcp_tools.py

Benchmarks

python benches/bench_tool_dispatch.py           # full run
python 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.

Development

acmt001-mcp uses Poetry and mise.

git clone https://github.com/sebastienrousseau/acmt001-mcp.git && cd acmt001-mcp
mise install
poetry install
poetry 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):

make check        # all gates (REQUIRED before commit)
make test         # pytest
make lint         # ruff + black
make type-check   # mypy --strict

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

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

MCP Registry

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

Licence

Licensed under the Apache Licence, 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.

Available Tools

6 tools

generate_messageGenerate acmt XML from recordsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`records`	Yes	One or more flat account records, each a dict of field name -> value, from which the acmt XML is generated; run validate_records first to surface record-level errors.
`message_type`	Yes	A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, destructiveHint. The description adds that no file is written, records must be in memory, and returns XML string or error payload. This supplements annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: first sentence states purpose, then adds context, usage tips, return value, and args. Every sentence provides essential information with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (not shown), but the description explains return values clearly. It covers prerequisites and no file writing. For a simple 2-param tool with good annotations and schema, the description is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description's 'Args' section mostly repeats schema info. It adds marginal value by emphasizing 'flat' records and the prerequisite to validate, but these are already in schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate a validated ISO 20022 acmt XML message from in-memory records' with specific verb and resource. It distinguishes itself from siblings by noting it is the primary generation tool and referencing prerequisites like validate_records and list_message_types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises running validate_records first and list_message_types to confirm message_type, providing clear usage context. It implicitly suggests when not to use this tool (e.g., before validation), but could be more explicit about alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_input_schemaGet input JSON SchemaA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`message_type`	Yes	A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types).

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing the tool as a safe, idempotent read operation. The description does not add additional behavioral context beyond what is already captured by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose. Each sentence adds value, and the structure is clear with a brief usage note and sibling references.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 rich annotations and schema, the description covers purpose, usage, and alternatives. It does not explicitly state that the return is a JSON Schema object, but this is implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter message_type already has a detailed description and enum in the schema. The description repeats the parameter info without adding new meaning, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the full JSON Schema for a message type's flat input record. It explicitly distinguishes from sibling tools by mentioning alternatives for required fields (get_required_fields) and validation (validate_records).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use this to learn every field, its type, and its constraints before assembling records, or to drive a form/UI.' It also specifies when not to use it by directing to siblings for specific cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_required_fieldsGet required fieldsA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`message_type`	Yes	A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly safe and non-destructive. The description adds no additional behavioral context beyond stating it lists fields, which is appropriate. With annotations covering the safety profile, a score of 3 is reasonable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at 4 lines, front-loading the purpose and then providing usage guidance. No unnecessary information. Slightly more verbose than necessary but still well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, output schema exists, low complexity), the description adequately covers purpose, usage, and parameter. No need to detail return values since output schema is available. Complete for its context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description's parameter documentation ('message_type: A supported ISO 20022 acmt message type') adds no extra meaning beyond what is already in the schema's description and enum list. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List only the required input field names for an acmt message type' with a specific verb (list) and resource (required field names). It explicitly distinguishes from the sibling tool get_input_schema by noting that the sibling provides full type/format constraints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('quick checklist of mandatory columns before building account records') and when not to use it ('when you need full type/format constraints, call get_input_schema instead'), providing clear guidance on alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_message_typesList acmt message typesA

Read-onlyIdempotent

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``).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent, so the description's value is in detailing the return format (list of dictionaries). This adds context beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences front-loading purpose, usage, and output. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description sufficiently describes the return format and purpose. No gaps for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline 4 applies. The description correctly does not add parameter info as none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists every supported ISO 20022 acmt message type with human names, and distinguishes itself from sibling tools like get_required_fields and get_input_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use this tool first before generation/validation calls, and provides alternatives for fetching field schemas (get_required_fields, get_input_schema).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_identifierValidate IBAN, BIC or LEIA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	Yes	The financial identifier scheme to validate against (case-insensitive). Must be exactly one of: 'bic', 'iban', 'lei'.
`value`	Yes	The identifier value to check, e.g. an IBAN, BIC/SWIFT code, or LEI; validated according to the given kind.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's role is lighter. It adds the return format {'kind', 'value', 'valid'}, which is useful context for the agent. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise (5 sentences) with front-loaded purpose, no wasted words. Every sentence adds value, including the return format and parameter list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple validation tool with 2 parameters and no output schema, the description fully covers what the tool does, when to use it, and what it returns. The explicit return object compensates for the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates the parameters with minor additions (case-insensitivity already in schema), but does not add significant new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Validate' and the resource 'single financial identifier (IBAN, BIC, or LEI)', distinguishing it from the sibling tool 'validate_records' which handles batch validation. It is specific and leaves no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this for a one-off identifier check' and directs to use 'validate_records' for batch records, providing clear when-to-use and when-not-to-use guidance with a named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_recordsValidate records against schemaA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`records`	Yes	One or more flat account records, each a dict of field name -> value; validated against the message type's input JSON Schema (see get_input_schema / get_required_fields).
`message_type`	Yes	A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types).

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe, non-destructive operation. The description complements this by specifying the exact return format ({'valid', 'total', 'valid_count', 'errors'}), which adds valuable behavioral context beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs and a structured 'Args' section. Every sentence adds value: purpose, usage guidance, return type, and parameter summaries. No redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description explicitly provides the return format, making it complete. It also references sibling tools (get_input_schema, get_required_fields) for further context. Given the tool's simplicity (2 required parameters), this is fully sufficient for an AI agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both parameters in detail. The description provides a brief summary of each parameter (e.g., 'A supported ISO 20022 acmt message type') but adds little beyond what the schema includes. It mentions links to related tools, which is helpful, but not enough to elevate above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Validate') and resource ('flat account records against a message type's input JSON Schema'). It clearly distinguishes the tool from siblings like validate_identifier and generate_message by stating what it checks (JSON-Schema shape) and its intended use before generate_message.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('before generate_message') and when not to ('to validate a single financial identifier... use validate_identifier'). It also clarifies that it only checks JSON-Schema shape, setting proper expectations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.0.5Jul 11, 2026

Changedgenerate_message2 fields changed

changedInput schema / properties / message_type / description

Previous value: -"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."New value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types)."

addedInput schema / properties / message_type / enum

Added value: +[
+  "acmt.001.001.08",
+  "acmt.002.001.08",
+  "acmt.003.001.08",
+  "acmt.005.001.06",
+  "acmt.006.001.07",
+  "acmt.007.001.05",
+  "acmt.008.001.05",
+  "acmt.009.001.04",
+  "acmt.010.001.04",
+  "acmt.011.001.04",
+  "acmt.012.001.04",
+  "acmt.013.001.04",
+  "acmt.014.001.05",
+  "acmt.015.001.05",
+  "acmt.016.001.05",
+  "acmt.017.001.05",
+  "acmt.018.001.05",
+  "acmt.019.001.04",
+  "acmt.020.001.04",
+  "acmt.021.001.04",
+  "acmt.022.001.04",
+  "acmt.023.001.04",
+  "acmt.024.001.04",
+  "acmt.027.001.06",
+  "acmt.028.001.06",
+  "acmt.029.001.06",
+  "acmt.030.001.04",
+  "acmt.031.001.06",
+  "acmt.032.001.06",
+  "acmt.033.001.02",
+  "acmt.034.001.06",
+  "acmt.035.001.02",
+  "acmt.036.001.01",
+  "acmt.037.001.02"
+]

Changedget_input_schema2 fields changed

changedInput schema / properties / message_type / description

Previous value: -"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."New value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types)."

addedInput schema / properties / message_type / enum

Added value: +[
+  "acmt.001.001.08",
+  "acmt.002.001.08",
+  "acmt.003.001.08",
+  "acmt.005.001.06",
+  "acmt.006.001.07",
+  "acmt.007.001.05",
+  "acmt.008.001.05",
+  "acmt.009.001.04",
+  "acmt.010.001.04",
+  "acmt.011.001.04",
+  "acmt.012.001.04",
+  "acmt.013.001.04",
+  "acmt.014.001.05",
+  "acmt.015.001.05",
+  "acmt.016.001.05",
+  "acmt.017.001.05",
+  "acmt.018.001.05",
+  "acmt.019.001.04",
+  "acmt.020.001.04",
+  "acmt.021.001.04",
+  "acmt.022.001.04",
+  "acmt.023.001.04",
+  "acmt.024.001.04",
+  "acmt.027.001.06",
+  "acmt.028.001.06",
+  "acmt.029.001.06",
+  "acmt.030.001.04",
+  "acmt.031.001.06",
+  "acmt.032.001.06",
+  "acmt.033.001.02",
+  "acmt.034.001.06",
+  "acmt.035.001.02",
+  "acmt.036.001.01",
+  "acmt.037.001.02"
+]

Changedget_required_fields2 fields changed

changedInput schema / properties / message_type / description

Previous value: -"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."New value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types)."

addedInput schema / properties / message_type / enum

Added value: +[
+  "acmt.001.001.08",
+  "acmt.002.001.08",
+  "acmt.003.001.08",
+  "acmt.005.001.06",
+  "acmt.006.001.07",
+  "acmt.007.001.05",
+  "acmt.008.001.05",
+  "acmt.009.001.04",
+  "acmt.010.001.04",
+  "acmt.011.001.04",
+  "acmt.012.001.04",
+  "acmt.013.001.04",
+  "acmt.014.001.05",
+  "acmt.015.001.05",
+  "acmt.016.001.05",
+  "acmt.017.001.05",
+  "acmt.018.001.05",
+  "acmt.019.001.04",
+  "acmt.020.001.04",
+  "acmt.021.001.04",
+  "acmt.022.001.04",
+  "acmt.023.001.04",
+  "acmt.024.001.04",
+  "acmt.027.001.06",
+  "acmt.028.001.06",
+  "acmt.029.001.06",
+  "acmt.030.001.04",
+  "acmt.031.001.06",
+  "acmt.032.001.06",
+  "acmt.033.001.02",
+  "acmt.034.001.06",
+  "acmt.035.001.02",
+  "acmt.036.001.01",
+  "acmt.037.001.02"
+]

Changedvalidate_identifier2 fields changed

changedInput schema / properties / kind / description

Previous value: -"The identifier scheme to validate against: one of 'iban', 'bic', or 'lei' (case-insensitive)."New value: +"The financial identifier scheme to validate against (case-insensitive). Must be exactly one of: 'bic', 'iban', 'lei'."

addedInput schema / properties / kind / enum

Added value: +[
+  "bic",
+  "iban",
+  "lei"
+]

Changedvalidate_records2 fields changed

changedInput schema / properties / message_type / description

Previous value: -"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."New value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction. Must be exactly one of: 'acmt.001.001.08', 'acmt.002.001.08', 'acmt.003.001.08', 'acmt.005.001.06', 'acmt.006.001.07', 'acmt.007.001.05', 'acmt.008.001.05', 'acmt.009.001.04', 'acmt.010.001.04', 'acmt.011.001.04', 'acmt.012.001.04', 'acmt.013.001.04', 'acmt.014.001.05', 'acmt.015.001.05', 'acmt.016.001.05', 'acmt.017.001.05', 'acmt.018.001.05', 'acmt.019.001.04', 'acmt.020.001.04', 'acmt.021.001.04', 'acmt.022.001.04', 'acmt.023.001.04', 'acmt.024.001.04', 'acmt.027.001.06', 'acmt.028.001.06', 'acmt.029.001.06', 'acmt.030.001.04', 'acmt.031.001.06', 'acmt.032.001.06', 'acmt.033.001.02', 'acmt.034.001.06', 'acmt.035.001.02', 'acmt.036.001.01', 'acmt.037.001.02' (see list_message_types)."

addedInput schema / properties / message_type / enum

Added value: +[
+  "acmt.001.001.08",
+  "acmt.002.001.08",
+  "acmt.003.001.08",
+  "acmt.005.001.06",
+  "acmt.006.001.07",
+  "acmt.007.001.05",
+  "acmt.008.001.05",
+  "acmt.009.001.04",
+  "acmt.010.001.04",
+  "acmt.011.001.04",
+  "acmt.012.001.04",
+  "acmt.013.001.04",
+  "acmt.014.001.05",
+  "acmt.015.001.05",
+  "acmt.016.001.05",
+  "acmt.017.001.05",
+  "acmt.018.001.05",
+  "acmt.019.001.04",
+  "acmt.020.001.04",
+  "acmt.021.001.04",
+  "acmt.022.001.04",
+  "acmt.023.001.04",
+  "acmt.024.001.04",
+  "acmt.027.001.06",
+  "acmt.028.001.06",
+  "acmt.029.001.06",
+  "acmt.030.001.04",
+  "acmt.031.001.06",
+  "acmt.032.001.06",
+  "acmt.033.001.02",
+  "acmt.034.001.06",
+  "acmt.035.001.02",
+  "acmt.036.001.01",
+  "acmt.037.001.02"
+]

5 tool updatesv0.0.4Jul 10, 2026

Changedgenerate_message2 fields changed

addedInput schema / properties / message_type / description

Added value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."

addedInput schema / properties / records / description

Added value: +"One or more flat account records, each a dict of field name -> value, from which the acmt XML is generated; run validate_records first to surface record-level errors."

Changedget_input_schema1 field changed

addedInput schema / properties / message_type / description

Added value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."

Changedget_required_fields1 field changed

addedInput schema / properties / message_type / description

Added value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."

Changedvalidate_identifier2 fields changed

addedInput schema / properties / kind / description

Added value: +"The identifier scheme to validate against: one of 'iban', 'bic', or 'lei' (case-insensitive)."

addedInput schema / properties / value / description

Added value: +"The identifier value to check, e.g. an IBAN, BIC/SWIFT code, or LEI; validated according to the given kind."

Changedvalidate_records2 fields changed

addedInput schema / properties / message_type / description

Added value: +"A supported ISO 20022 acmt message type, e.g. 'acmt.001.001.08' Account Opening Instruction -- call list_message_types for the exact accepted strings."

addedInput schema / properties / records / description

Added value: +"One or more flat account records, each a dict of field name -> value; validated against the message type's input JSON Schema (see get_input_schema / get_required_fields)."

6 tool updatesv0.0.3Jul 10, 2026
- First observedgenerate_message
- First observedget_input_schema
- First observedget_required_fields
- First observedlist_message_types
- First observedvalidate_identifier
- First observedvalidate_records

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Scored 2026-07-11 13:00 across 6 tools

Disambiguation5/5

Each tool serves a unique, clearly defined purpose: listing message types, retrieving schema details, validating records or identifiers, and generating XML. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow the same verb_noun pattern in lowercase with underscores (e.g., list_message_types, validate_records), providing a predictable and uniform interface.

Tool Count5/5

With 6 tools, the server covers the essential workflow—discovery, schema inspection, validation, and generation—without being bloated or too sparse for its stated purpose.

Completeness5/5

The tools provide a complete lifecycle for generating validated acmt XML messages: discover supported types, examine field requirements, validate inputs at both record and identifier level, and produce the final XML.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282
mcp-spec-compliance-mcp
io.github.CSOAI-ORG
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
Testing & QA Tools Developer Tools
2
xytara MCP Executor B
com.naxytra
Public MCP server for summaries, DNS lookup, catalog, replies, and JSON checks.
Text Summarization Networking & Infrastructure
2

Related MCP Servers

mcp-facture-electronique-fr
Payments & Billing Finance
cmendezs
A
license
A
quality
A
maintenance
Model Context Protocol (MCP) server for French Electronic Invoicing (NF XP Z12-013). Provide tools to validate, generate, and explore API specifications for PDP/OD interoperability.
Updated a day ago (2026-09-09 21:51 UTC)
34
Apache 2.0
pacs008-mcp
Finance Payments & Billing
sebastienrousseau
F
license
A
quality
A
maintenance
An MCP server that exposes the pacs008 ISO 20022 FI-to-FI Customer Credit Transfer library as tools for AI agents and assistants, enabling generation, validation, and parsing of pacs.008 credit transfer XML messages.
Updated 12 days ago (2026-08-29 18:44 UTC)
16
1
-
iso20022-mcp
Finance Payments & Billing
sebastienrousseau
F
license
A
quality
A
maintenance
Unified gateway for ISO 20022 message families, providing meta-tools to search, describe, validate, generate, and parse financial messages.
Updated 12 days ago (2026-08-29 22:05 UTC)
7
1
-
fix-protocol-mcp
Finance Developer Tools
slenderongithub
A
license
A
quality
C
maintenance
MCP server for parsing, validating, building and explaining FIX protocol trading messages — offline, no API keys.
Updated 2 months ago (2026-07-17 12:12 UTC)
4
MIT

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

Contents

Overview

Install

Quick Start

Tools

Using the tools

Benchmarks

Development

Related MCP Servers

MCP Registry

Licence

Contribution

Acknowledgements

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers