Signal8 MCP vs Camt053 MCP

list_message_types

List every supported ISO 20022 camt.05x message type and its name. Use this first, before any validation or generation call, to discover the exact ``message_type`` strings this server accepts. For the return-reason codes rather than message types, call ``list_return_reasons`` instead. Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one per supported message type (e.g. ``camt.053.001.14``).

list_return_reasons

List every known ISO external return reason code with its name. Use this to discover the ``reason_code`` values that ``filter_entries`` and ``generate_reversal`` accept (e.g. ``AC04`` Closed Account). For the supported message types rather than reason codes, use ``list_message_types``. Returns a list of ``{"code": ..., "name": ...}`` dictionaries (e.g. ``{"code": "AC04", "name": "Closed Account Number"}``).

get_required_fields

List only the required input field names for a camt message type. Use this for a quick checklist of the mandatory columns before building reversing-entry 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 camt.05x message type.

get_input_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 camt.05x message type.

validate_records

Validate flat records against a message type's input JSON Schema. Use this on in-memory reversing-entry records to catch structural/type errors per row before generation. To validate a whole camt.05x *document* (XML) against its XSD instead, use ``validate_statement``. Returns a report ``{"valid": bool, "total": int, "valid_count": int, "errors": [...]}``. Args: message_type: A supported ISO 20022 camt.05x message type. records: One or more flat reversing-entry records to validate.

validate_identifier

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

parse_statement

Parse an incoming camt.05x statement XML string into structured data. Use this to turn a raw statement into a navigable dict (header, statements, accounts, balances, entries). To pull just the flat entry list use ``list_entries``; to only check the document is schema-valid use ``validate_statement``. Returns the parsed document as a JSON-serialisable dict (group header plus statements, each with its account, balances, and entries), or an ``{"error": ...}`` payload if the XML cannot be parsed. Args: xml: The raw statement XML as a string.

convert_mt940_to_camt053

Convert a legacy SWIFT MT940 statement into a camt.053 structure. Use this as the Phase-1 migration wedge: SWIFT MT940 customer statements retire in **November 2028**, so this tool bridges the gap by turning raw MT940 text into the same JSON-serialisable camt.053 document shape that ``parse_statement`` returns (group header plus statements, each with its account, balances, and entries). Downstream tools (``list_entries``, ``filter_entries``, ``classify_entry``, ``export_journal``) then work on the result unchanged. Wraps the ``camt053-loader-mt940`` library's ``parse_mt940``; the MT parsing itself is delegated (no MT grammar is reimplemented here). The resulting ``ParsedDocument`` is serialised with the same ``to_dict()`` the server's other parse tools use, so agents get a consistent structure. Nothing is read from or written to disk. Returns the converted document as a JSON-serialisable dict, or an ``{"error": ...}`` payload if the MT940 text cannot be parsed (e.g. a missing ``:20:`` reference or a malformed balance / statement line). Args: mt940_text: The raw MT940 statement text as a string.

convert_mt942

Convert a legacy SWIFT MT942 interim report into a camt.052 structure. Use this as the Phase-1 migration wedge for intraday reporting: SWIFT MT94x messages retire in **November 2028**, so this tool bridges the gap by turning raw MT942 *Interim Transaction Report* text into the same JSON-serialisable camt.052 (Bank-to-Customer Account **Report**) document shape the server's parse tools return (group header plus statements, each with its account, balances, and entries). MT942 is the intraday sibling of MT940: where MT940 maps to camt.053 (end-of-day statement), MT942 maps to camt.052, so the resulting ``message_type`` is ``camt.052.001.08``. Downstream tools (``list_entries``, ``filter_entries``, ``classify_entry``, ``export_journal``) then work on the result unchanged. Wraps the ``camt053-loader-mt942`` library's ``parse_mt942``; the MT parsing itself is delegated (no MT grammar is reimplemented here). The resulting ``ParsedDocument`` is serialised with the same ``to_dict()`` the server's other parse tools use, so agents get a consistent structure. Nothing is read from or written to disk. **Documented model limitation.** The ``camt053`` typed model is camt.053-statement-oriented: it has no dedicated field for camt.052's floor-limit (``<Lmt>``) or transaction-summary (``<TxsSummry>``) blocks. Rather than drop that data, the loader surfaces it on the balance list using clearly proprietary ``type_code`` values so consumers can recognise and filter them: ``:34F:`` floor limits become ``FLIMD`` / ``FLIMC`` balances, and ``:90D:`` / ``:90C:`` entry-count summaries become ``SUMD:<count>`` / ``SUMC:<count>`` balances (the ISO ``NbOfNtries`` count is encoded after the colon; the sum is the balance ``amount``). See the loader's README. Returns the converted document as a JSON-serialisable dict, or an ``{"error": ...}`` payload if the MT942 text cannot be parsed (e.g. a missing ``:20:`` reference or a malformed floor-limit / summary / statement line). Args: mt942_text: The raw MT942 interim transaction report text as a string.

validate_statement

Validate an incoming camt.05x statement XML against its XSD schema. Use this to confirm a document is well-formed and schema-valid before processing it. This checks XSD conformance only; for the Nov 2026 CBPR+ business rules use ``check_cbpr_readiness``, and to extract the data use ``parse_statement``. Detects the document's message type, validates it against the matching ISO 20022 schema, and returns a report ``{"valid": bool, "message_type": str, "errors": [...]}``. A well-formed but schema-invalid document yields ``valid=False`` with a populated ``errors`` list (and the detected ``message_type``); a valid one yields ``valid=True`` with no errors. Returns an ``{"error": ...}`` payload instead if the XML cannot be parsed (e.g. it is malformed or is not a camt ``Document``). Args: xml: The raw statement XML as a string.

check_cbpr_readiness

Check a camt.053 statement against the CBPR+ Nov 2026 acceptance rules. Use this to audit a statement for the business-rule changes (schema version, structured postal addresses) enforced from the Nov 2026 cutover. For plain XSD schema validity use ``validate_statement`` instead; for just the cutover date use ``get_cbpr_cutover_date``. A coordinated CBPR+ / Fedwire / CHAPS / T2 cutover lands on **14-16 November 2026**: unstructured-only postal addresses get rejected, ``camt.110/111`` exceptions and investigations become mandatory, and T2S R2026.NOV upgrades camt.053 / 054 to schema revision MR2026. This tool walks the supplied payload and reports every issue that will fail the Nov 2026 acceptance rules: * **Schema version** vs the CBPR+ current set (``camt.053.001.08`` / ``camt.053.001.13``); ``.02``-``.07`` are flagged as deprecated warnings; unknown / non-camt.053 namespaces as errors. * **Postal addresses**: every ``<PstlAdr>`` is classified as fully structured, hybrid, or **unstructured-only** (``<AdrLine>`` without ``<TwnNm>`` + ``<Ctry>`` siblings, the Nov 2026 reject case). Returns a dictionary ``{"cbpr_ready": bool, "schema_version": str | None, "checked_at": ISO-8601 UTC, "cutover_date": "2026-11-16", "issues": [...], "summary": {...}}``. ``cbpr_ready`` is ``True`` iff no ``severity="error"`` issue was raised. An ``{"error": ...}`` envelope is returned instead if the XML is malformed or refused by the hardened pre-flight (DOCTYPE / ENTITY / oversized payload). Args: xml: The raw camt.05x statement XML as a string.

get_cbpr_cutover_date

Return the official CBPR+ / Nov 2026 cutover date as ISO 8601. Use this to quote the enforcement date directly, without parsing a document. To actually audit a statement against the rules that take effect on that date, call ``check_cbpr_readiness`` instead. The cutover (``2026-11-16``) is the date after which the rules checked by ``check_cbpr_readiness`` are enforced by the major clearing systems; payments that fail will be rejected at receive-time. Surfaced as a discrete tool so agents can quote it directly without having to call a readiness check first.