Pain001 MCP

ISO 20022 payment files for agents: generate, validate, and convert pain.001, pain.008, MT101.

Connector by sebastienrousseau · GitHub account verified by the MCP Registry

IndexedApache-2.0Local (stdio)★ 1

Chalk Labs

Need help deploying Pain001 MCP?

Chalk Labs sets up agents like this inside real teams: connected to your tools, tested on your data, with a human in the loop where it matters.

Book a call

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/sebastienrousseau-pain001-mcp

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

About

ISO 20022 payment files for agents: generate, validate, and convert pain.001, pain.008, MT101.

Reviews

Write a review

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list, install config and code. Checked Oct 25, 2026.

Tools: 17 read · 5 write · 1 delete · 3 not yet classified
Secrets: None asked for
Install scripts: None found
Runs as: Python package

Tools by what they do 26

Read from the source code; the running server may list different tools.

Read 17 · Look things up without changing anything.

convert_mt101
get_corpus_coverage
get_corpus_file
get_corpus_provenance
get_input_schema
get_required_fields
inspect_template
list_corpus_files
list_message_types
list_supported_formats
parse_camt053
parse_pain002

Show 5 more tools

suggest_record_fix
validate_identifier
validate_payment_scheme
validate_records
validate_xml_against_schema

Write 5 · Create, change, send or run things.

commit_payment_batch
generate_message
generate_message_async
generate_message_from_file
migrate_records

Delete 1 · Delete, drop, revoke or wipe things.

simulate_clearing

Not yet classified 3 · We could not tell from the name and description.

sanitize_to_iso20022_charset
simulate_payment_batch
stage_payment_batch

Network hosts it talks to 5

cloudcdn.pro · found in code
docs.pain001.com · found in code
github.com · found in code
glama.ai · found in code
pain001.com · found in code

Tools (26)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

commit_payment_batchCommit staged payment batch with dual control
Commit an authorized staged payment batch with dual-control authorization. Verifies the stage ID and validates the secondary confirmation token using constant-time cryptographic comparison (preventing timing attacks). Transitions the order status from 'staged' to 'committed'. Optionally writes the verified XML payload to the specified destination path. Args: stage_id: Staging identifier from stage_payment_batch. confirmation_token: Secondary secret confirmation token. output_file_path: Optional path to write the committed XML document. Returns: CommitPaymentBatchResult with …
convert_mt101Convert MT101 to pain.001 records
Convert a legacy SWIFT MT101 message into pain.001-ready records. Use this to bridge the Nov-2025+ SWIFT MT→MX migration: parse an MT101 (*Request for Transfer*) into the flat records the other tools consume — feed the result straight to ``validate_records`` / ``validate_payment_scheme`` and then ``generate_message`` to emit pain.001.001.09 XML. An MT101 can request many transfers (repeating sequence B), so this returns *one record per transaction*. Operates on the supplied text only; no file is read or written. Wraps :func:`pain001_loader_mt101.loader.parse_mt101`. Sequence-A ordering-custo…
generate_messageGenerate pain XML from records
Generate a validated ISO 20022 pain XML message from in-memory records. This is the primary generation tool: pass records you already hold in memory. Use ``generate_message_from_file`` when the data lives in a CSV on disk, and ``generate_message_async`` for very large batches you want to run off the event loop. The result is XSD-validated before return; no file is written. Records are normalized before rendering: 'amount'/'currency' aliases, JSON booleans, and bare 'YYYY-MM-DD' dates are accepted, and nb_of_txs/ctrl_sum are computed from the records. On failure the ``{"error": ...}`` payload…
generate_message_asyncGenerate pain XML (async, large batches)
Generate validated pain XML off the event loop, for large batches. Behaves exactly like ``generate_message`` but runs the synchronous renderer in a worker thread so an agent can interleave a long generation with other tool calls. Use ``generate_message`` for small or interactive batches; use this only when the record count is large enough that blocking would matter. Delegates to :func:`pain001.async_adapter.generate_xml_string_async`. Returns the validated XML, or a JSON-encoded ``{"error": ...}`` payload. Args: message_type: A supported ISO 20022 pain message type. records: One or …
generate_message_from_fileGenerate pain XML from a CSV file
Generate validated pain XML from a CSV file on the local disk. Use this when the records live in a CSV file rather than in memory; it reads ``data_file_path`` from the local filesystem, then delegates to ``generate_message``. If you already have the records as dicts, call ``generate_message`` directly. Only CSV is supported today (JSON / JSONL / SQLite / Parquet are planned for a follow-up release). Loads ``data_file_path`` via :func:`pain001.csv.load_csv_data.load_csv_data` so the same path-safety guards apply as in the core library. Args: message_type: A supported ISO 20022 pain messa…
get_corpus_coverageGet schema coverage report
Return the schema coverage verdict of one message type's coverage set. Use this to check that the shipped coverage files reach every element path and choice branch of an edition's XSD before relying on them to smoke a parser or a mapping. Delegates to :func:`pain001.corpus.coverage_report`. Args: version: The message type. Returns: The ``coverage.json`` content (path and branch counts and percentages, completeness, missing and exempt lists), or ``{"error": ...}`` when the edition has no set or there is no corpus.
get_corpus_fileGet example corpus file
Return the XML of one validated example file from the market corpus. Use this to show a model, a tester or a mapping exercise what a correct file for a given country and rail looks like in a given edition. The text is exactly what pain001 ships; it passed the XSD, the ISO MDR rules, the rail profile and the overlay when it was built. Delegates to :func:`pain001.corpus.get_file`. Args: scenario_id: The scenario. version: The message type. variant: The overlay id of a bank variant, else ``None``. Returns: ``{"scenario_id", "version", "variant", "xml"}``, or ``{"error": ..…
get_corpus_provenanceGet example corpus provenance
Return the provenance sidecar of one example file. Use this to know how far to trust a file: the sources it was derived from, the confidence of the evidence (``verified``, ``derived`` or ``assumed``), the validation ladder result per rung, what the builder renamed or dropped to fit the edition, and the file's SHA-256. Delegates to :func:`pain001.corpus.provenance`. Args: scenario_id: The scenario. version: The message type. variant: The overlay id of a bank variant, else ``None``. Returns: The parsed sidecar as a dict, or ``{"error": ...}`` when there is no such file or…
get_input_schemaGet 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 pain message type.
get_required_fieldsGet required fields
List only the required input field names for a pain message type. Use this for a quick checklist of the mandatory columns before building 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 pain message type.
inspect_templateInspect CSV template columns
Return the CSV column headers the message type's bundled template uses. Use this to see the exact column order for hand-building a CSV before ``generate_message_from_file``. This returns column *names* from the bundled sample; for the typed JSON contract (types, required flags) use ``get_input_schema``. Mirrors the in-tree ``pain001.mcp.server.inspect_template`` tool so an agent can introspect the column layout before assembling rows. Args: message_type: A supported ISO 20022 pain message type. Returns: ``{"message_type": str, "columns": list[str]}`` or ``{"error": ...}`` if th…
list_corpus_filesList example corpus files
List the example files pain001 ships: market scenarios and coverage sets. Use this to discover what ready-made, validated ISO 20022 files exist before calling ``get_corpus_file`` or ``get_corpus_provenance``. Market files are realistic payments per country and rail (``scenario_id`` like ``gb.chaps.property-purchase``); a ``variant`` names the bank overlay a file was built with. Coverage files exercise every element and choice branch of one message type and carry no scenario. Delegates to :func:`pain001.corpus.list_files`. Args: kind: ``market``, ``coverage`` or ``None`` for both. co…
list_message_typesList pain message types
List every supported ISO 20022 pain 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. 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. ``pain.001.001.09``).
list_supported_formatsList supported input formats
List the on-disk data formats the pain001 loader can read. Use this to tell a user which file types they may supply to ``generate_message_from_file``. This lists *data-source* formats (CSV, SQLite, …); for the list of ISO 20022 *message* types call ``list_message_types`` instead. Returns a list of ``{"id", "name", "extension"}`` dictionaries covering CSV, SQLite, JSON, JSONL, and Parquet (the last requires the ``pain001[parquet]`` extra).
migrate_recordsMigrate records between versions
Migrate flat payment records between two pain.001 schema versions. Use this to upgrade/downgrade records when your bank requires a different pain.001 version than your source data uses (e.g. move ``.03`` rows to ``.09``); it reports which fields were renamed, derived, or dropped. This transforms records only — run ``validate_records`` afterwards, then ``generate_message`` to emit XML. Wraps :class:`pain001.migration.VersionMapper`. Returns the migrated rows plus a summary of which fields were renamed, derived, or dropped; ``{"error": ...}`` if either version is unsupported. Args: record…

Show 11 more tools

parse_camt053Parse camt.053 statement file
Parse a camt.053 bank-statement XML file on disk into structured data. Use this to read a bank's account statement (the reply that confirms settlement) into a header + entry list. Reads ``xml_file_path`` from the local filesystem. For the payment-status reply (accepted/rejected per transaction) use ``parse_pain002`` instead; to validate a camt.053 string you already hold, this is not it — this tool needs a file path. Wraps :func:`pain001.parse_camt053_statement`. When ``xsd_file_path`` is provided, the document is first validated against that XSD; on a schema or parse error the tool returns …
parse_pain002Parse pain.002 status report file
Parse a pain.002 payment-status report file on disk into structured data. Use this to read the bank's acknowledgement of a submitted pain.001 — the per-transaction accepted/rejected status and reason codes. Reads ``xml_file_path`` from the local filesystem. For the account statement that later confirms booked entries, use ``parse_camt053`` instead. Wraps :func:`pain001.parse_pain002_report`. When ``xsd_file_path`` is provided, the document is first validated against that XSD; on a schema or parse error the tool returns ``{"error": ...}`` rather than raising. Args: xml_file_path: Filesys…
sanitize_to_iso20022_charsetSanitise text to ISO 20022 charset
Sanitise one free-text field to a SWIFT / ISO 20022 character set. Use this on a single free-text value (name, remittance info) to transliterate accents and drop unsupported symbols before placing it in a record, and to see whether the value changed. Operates on one string; to check a whole batch's rulebook compliance use ``validate_payment_scheme``. Two character sets are supported via ``charset``: * ``"SWIFT_X"`` (default, backward-compatible) - the basic set used in most ISO 20022 / pain.001 fields. Delegates to :func:`pain001.sanitize_to_charset`. * ``"SWIFT_Z"`` - the SWIFT extende…
simulate_clearingSimulate clearing network execution
Simulate settlement and clearing network execution for a staged batch. Evaluates network-specific rulebooks and clearing constraints: - EPC-SEPA: EUR currency mandate, SEPA-zone IBAN prefixes, SLEV charge bearer. - FedNow: USD instant gross settlement eligibility. - US-ACH: USD next-day clearing cycle routing. - SWIFT-MX: Cross-border correspondent banking BIC routing. - CHAPS: Same-day RTGS high-value GBP clearing. - BACS: Three-day GBP direct credit clearing. Args: stage_id: Staging identifier from stage_payment_batch. clearing_system: Clearing rail profile to simulate. Returns: …
simulate_payment_batchSimulate payment batch
Simulate and pre-flight a payment batch before XML generation. Performs comprehensive pre-flight verification without generating XML or staging files: 1. Validates records against the message type's JSON Schema. 2. Validates records against an optional payment-scheme rulebook. 3. Computes control sums grouped by currency. 4. Calculates unique debtor and creditor account counts. 5. Detects intra-batch duplicate transactions (same debtor, creditor, amount, currency, and execution date). Returns a structured verdict with totals, sums by currency, duplicate findings, and schema/scheme errors…
stage_payment_batchStage payment batch for simulation and approval
Stage a payment batch for simulation and dual-control approval. Creates an in-memory staged payment order with zero fund movement and a 1-hour expiration window. Computes: 1. Schema validation against the message type's JSON Schema. 2. Optional scheme compliance verification (SEPA, BACS, etc.). 3. Multi-currency control sums and fee estimation. 4. Multi-factor risk scoring (detecting duplicates, high transaction amounts, and generic remittance narratives). 5. In-memory XML compilation and SHA-256 fingerprinting. 6. Cryptographic dual-control confirmation token for subsequent authorization…
suggest_record_fixSuggest review-only record fixes
Suggest deterministic, review-only fixes to non-financial fields. Returns patches or a cannot_autofix reason. Never changes IBANs, BICs, accounts, amounts or currencies, even for whitespace. Review every candidate and validate the full record before generating a payment. Args: record: A flat payment record, left unchanged. validation_error: Finding with field (or path) and rule keys. message_type: Supported schema supplying trusted field bounds.
validate_identifierValidate IBAN or BIC
Validate a single financial identifier (IBAN or BIC). Use this for a one-off identifier check with a clear pass/fail and reason. To validate identifiers embedded across a whole batch, prefer ``validate_records`` / ``validate_payment_scheme`` instead of calling this per field. Returns ``{"kind": str, "value": str, "valid": bool, "error": str}`` (the ``error`` key is present only when ``valid`` is ``False``). Args: kind: One of ``"iban"`` or ``"bic"`` (case-insensitive). value: The identifier value to check.
validate_payment_schemeValidate against scheme rulebook
Validate records against a payment-scheme rulebook (e.g. SEPA). Use this after ``validate_records`` to enforce scheme-specific business rules (SEPA field lengths, allowed characters, currency/BIC constraints) that JSON-Schema validation alone does not cover. ``validate_records`` checks structural shape; this checks rulebook compliance for one profile. Delegates to :func:`pain001.validate_scheme`. Supported profiles: ``sepa-sct``, ``sepa-sdd``, ``sepa-inst``, ``xborder-ct``. Args: records: Payment records as a list of flat dicts. profile: The scheme profile name. Returns: ``{"pr…
validate_recordsValidate records against schema
Validate flat 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; for payment-scheme rulebook checks (SEPA field lengths, charset, etc.) also run ``validate_payment_scheme``. Returns a report ``{"valid": bool, "total": int, "valid_count": int, "errors": [...]}``. Args: message_type: A supported ISO 20022 pain message type. records: One or more flat payment records to validate.
validate_xml_against_schemaValidate XML string against XSD
Validate a raw pain.001 / pain.008 XML string against its official XSD. Use this to check XML you already have as a string (e.g. received from another system) without touching the filesystem. To validate records *before* they become XML, use ``validate_records``; to parse a statement or status-report file, use ``parse_camt053`` / ``parse_pain002``. Wraps :func:`pain001.xml.validate_via_xsd.validate_xml_string_via_xsd`. Args: xml_content: The XML document as a string. message_type: A supported ISO 20022 pain message type. Returns: ``{"valid": bool, "message_type": str, "error": …

Signals

Stars: 1
Forks: 0
Open issues: 0
Weekly downloads: 210
Last commit: Oct 23, 2026 (11 days ago)
Last release: Oct 23, 2026 (11 days ago)
Last package publish: Oct 23, 2026 (11 days ago)

From GitHub (fetched Oct 24, 2026) and the package registry.

Details

Registry name: io.github.sebastienrousseau/pain001-mcp
Version: 0.0.74
Auth: No auth
Packages: pypi pain001-mcp
License: Apache-2.0
Repository: github.com/sebastienrousseau/pain001-mcp
First seen: Oct 24, 2026
Last checked: Oct 24, 2026
Source: Official MCP Registry github-graphql

More from sebastienrousseau

Done for you

Rather not set it up yourself?

Chalk Labs scopes, builds and runs agents for your team: the task audit, the eval harness, the integrations and the weekly ops report. Fixed scope, priced before we start.

See how we build AI agents →Read the case studies

Chalk Labs is a two-founder AI and growth studio. We build AI agents, CRMs and MVPs for Web3 and AI companies, and have shipped 50+ product and token launches.

launches shipped: 50+; launches shipped
media placements: 500+; media placements
founders on every account: 2; founders on every account

Press we've placed: Forbes · CoinDesk · Decrypt · Cointelegraph · The Block

Rahil Jain, Co-founder, Chalk Labs. Ex-Goldman Sachs engineer. You talk to the person who builds it.

Get Pain001 MCP running in your business

Tell us what you want to automate. A founder replies within one working day with a plan, not a pitch deck.

Need help deploying Pain001 MCP?

Call Get help

Cite this page

Pain001 MCP. Agent Mart. https://agentmart.dev/connectors/sebastienrousseau-pain001-mcp (last updated 2026-10-24)