io.github.sebastienrousseau/acmt001-mcp

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.

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.

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.

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

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.

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.

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.