How do I use camt-exceptions?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@camt-exceptions Generate camt.056 for duplicate payment of 1000 EUR" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

camt-exceptions

by sebastienrousseau

Overview Schema Related Servers Score Discussions

Python

Remote

camt-exceptions: ISO 20022 Exceptions & Investigations, generated + XSD-valid

Generate and validate ISO 20022 Exceptions & Investigations (E&I) camt messages — with an MCP server. Starts with camt.056 (FI-to-FI Payment Cancellation Request): the message a bank sends to recall or cancel a payment it already dispatched — a duplicate, an erroneous amount, a fraud recall. Output is validated against the official bundled XSD before it's returned.

Latest release: v0.0.14 — camt.056 + camt.029 generation + validation, 4 MCP tools over stdio, 100% branch coverage, for Python 3.10+. Part of the ISO 20022 MCP suite. Additional E&I messages (camt.029, camt.026, camt.027, camt.087) plug into the same engine.

Why E&I

When a payment goes wrong, the fix is an Exceptions & Investigations message — and these are the least tooled corner of ISO 20022. camt.056 alone covers the single most common need: "I need to cancel/recall that payment." This library makes it a one-call, schema-valid operation for an agent, with the same depth as the credit-transfer generators elsewhere in the suite.

Related MCP server: camt053-mcp

Install

pip install camt-exceptions
# or run the MCP server without installing:
uvx camt-exceptions

MCP client config (e.g. Claude Desktop):

{
  "mcpServers": {
    "camt-exceptions": {
      "command": "camt-exceptions-mcp"
    }
  }
}

Quick start — cancel a payment

from camt_exceptions import generator as g

xml = g.generate_message("camt.056.001.12", {
    "assignment_id": "CXL-001",
    "assigner_agent_bic": "DEUTDEFF",
    "assignee_agent_bic": "COBADEFF",
    "creation_date_time": "2026-03-02T10:00:00",
    "original_msg_id": "MSG-ORIG-001",
    "original_msg_nm_id": "pacs.008.001.08",
    "transactions": [{
        "original_end_to_end_id": "E2E-001",
        "original_interbank_settlement_amount": "1000.00",
        "original_interbank_settlement_currency": "EUR",
        "cancellation_reason_cd": "DUPL",       # duplicate payment
    }],
})
assert g.validate_xml("camt.056.001.12", xml)["is_valid"]   # True

Tools

list_message_types — List supported E&I message types and names.
get_required_fields — Required top-level fields for a message type.
generate_message — Generate a validated E&I XML message from a record (validated against the bundled XSD before return).
validate_xml — Validate raw XML against a message type's bundled XSD.

Supported messages

Message	Name	Status
`camt.056.001.12`	FI to FI Payment Cancellation Request	✅
`camt.029.001.14`	Resolution of Investigation	✅
`camt.026`	Unable to Apply	planned
`camt.027`	Claim Non-Receipt	planned
`camt.087`	Request to Modify Payment	planned

Each new message plugs into the same engine: bundle its official XSD + template.xml and register it in MESSAGE_TYPES. Generated output is always XSD-validated before return, so correctness is machine-checked, not asserted.

Note: the payment-status and return messages of the E&I family — pacs.002 (Payment Status Report) and pacs.004 (Payment Return) — are already generated, XSD-valid, by pacs008-mcp.

The suite

Part of a family of vendor-neutral, Python-native ISO 20022 MCP servers:

iso20022-mcp — unified gateway across the families.
pain001-mcp · pacs008-mcp · camt053-mcp · acmt001-mcp — per-family servers.
reconcile-mcp — statement/payment reconciliation.

Development

git clone https://github.com/sebastienrousseau/camt-exceptions
cd camt-exceptions
python -m venv .venv && . .venv/bin/activate
pip install -e . && pip install pytest pytest-cov ruff black mypy
pytest                      # 100% branch coverage gate; output is XSD-validated
ruff check camt_exceptions tests && black --check camt_exceptions tests && mypy camt_exceptions

Licence

Code licensed under the Apache License, Version 2.0. Bundled ISO 20022 message schemas (*.xsd) are © ISO 20022 and redistributed under the ISO 20022 terms; they are the same schemas published at iso20022.org.

mcp-name: io.github.sebastienrousseau/camt-exceptions

Available Tools

4 tools

generate_messageA

Read-onlyIdempotent

Generate a validated ISO 20022 E&I XML message from a record. For camt.056, the record cancels/recalls a previously sent payment (assignment ids + agent BICs + a list of 'transactions' with the original payment references and a cancellation reason code). Output is validated against the bundled XSD before it is returned.

ParametersJSON Schema

Name	Required	Description	Default
`record`	Yes	Message fields; see get_required_fields.
`message_type`	Yes	An E&I message type, e.g. 'camt.056.001.12' (see list_message_types).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

The description discloses that output is validated against bundled XSD and explains the cancellation scenario. Annotations indicate readOnlyHint=true, which is consistent with generating output without side effects.

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?

Two sentences, front-loaded with the main purpose, then necessary details. Every sentence adds value without redundancy.

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 the presence of an output schema, the description appropriately focuses on input semantics and behavioral details. It covers the essential aspects for correct invocation.

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

Parameters5/5

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

Schema coverage is 100% and the description adds value by explaining the record structure for camt.056 and directing to get_required_fields. The message_type parameter is given an example.

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 it generates a validated ISO 20022 E&I XML message from a record, with a specific example for camt.056. This distinguishes it from siblings like list_message_types and get_required_fields.

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 indicates when to use the tool (to generate a validated XML message) and directs users to sibling tools for prerequisites. It does not explicitly exclude alternatives, but the context is clear.

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

get_required_fieldsA

Read-onlyIdempotent

Return the required top-level fields for an E&I message type.

ParametersJSON Schema

Name	Required	Description	Default
`message_type`	Yes	An E&I message type, e.g. 'camt.056.001.12' (see list_message_types).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds that it returns 'required top-level fields', providing specific output context. 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?

A single, well-structured sentence that front-loads the action and object. Every word is necessary and adds value.

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 the presence of an output schema, the description adequately covers the tool's purpose. For a simple lookup tool, this is 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 coverage is 100% and the schema already describes message_type with a clear example and reference to list_message_types. The description does not add further semantic detail beyond what the schema provides.

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 'return' and clearly identifies the resource as 'required top-level fields for an E&I message type'. It distinguishes itself from siblings (list_message_types, generate_message, validate_xml) by focusing on fields rather than types, generation, or validation.

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

Usage Guidelines3/5

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

The description implies usage by stating that message_type should be an E&I message type, and the schema references list_message_types, suggesting a preceding step. However, it does not explicitly state when to use this tool versus alternatives or provide any when-not conditions.

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

list_message_typesA

Read-onlyIdempotent

List the supported ISO 20022 Exceptions & Investigations message types (e.g. camt.056 payment cancellation request) and their names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds domain context (ISO 20022) and an example but does not disclose additional behavioral traits such as output format or performance constraints.

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?

Single sentence, no filler. Directly states purpose with an example. Highly efficient.

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 zero-parameter list tool with an output schema, the description is largely sufficient. It could mention the output format but the schema covers that. Still slightly lacking in linking to sibling tools.

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, and schema coverage is 100%. The description adds meaning by specifying the standard and example, which is more than what the schema provides (empty). Baseline for 0 params is 4.

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 supported ISO 20022 message types, provides a specific example (camt.056), and distinguishes itself from sibling tools which focus on generating or validating messages.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_required_fields or generate_message. The description does not mention context or prerequisites.

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

validate_xmlA

Read-onlyIdempotent

Validate raw ISO 20022 XML against an E&I message type's bundled XSD; returns is_valid plus any schema errors.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	Raw ISO 20022 XML to validate.
`message_type`	Yes	An E&I message type, e.g. 'camt.056.001.12' (see list_message_types).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/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, indicating a safe, idempotent operation. The description adds the specific return values (is_valid and schema errors) but does not contradict 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 a single sentence with no wasted words, front-loading the action and outcomes.

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 low parameter count, full schema coverage, presence of output schema, and clear annotations, the description is complete. It explains what the tool does and what it returns.

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?

Schema coverage is 100% with descriptions for both parameters. The description adds an example value for message_type and references list_message_types, enhancing understanding beyond the schema alone.

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 validates raw ISO 20022 XML against an XSD and returns is_valid and errors. It distinguishes from siblings by referencing list_message_types for available 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 provides context by mentioning 'against an E&I message type's bundled XSD' and referencing list_message_types. However, it does not explicitly state when not to use or alternatives beyond mentioning the sibling list.

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

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing message types, retrieving required fields, generating a message, and validating XML. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., list_message_types, generate_message), making them predictable and easy to understand.

Tool Count5/5

With 4 tools, the set is well-scoped for the domain of ISO 20022 Exceptions & Investigations message generation and validation. Each tool serves a necessary function without redundancy.

Completeness4/5

The tools cover the core workflow of listing types, getting schema details, generating messages, and validating them. A minor gap exists in that generate_message specifically mentions camt.056, but the description implies support for other types as well. Lacks tools for parsing or transforming existing messages, but the set is reasonably complete for its intended purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ISO 20022 Generator A
com.iso20022generator
Generate and validate SEPA ISO 20022 XML (pain.001, pain.008) and SWIFT MT103 payment messages.
Finance Legal & Compliance Payments & Billing
41
iso20022oracle A
io.tooloracle
ISO20022Oracle - 12 ISO 20022 tools: pacs/pain/camt parsing, MX validation, MT migration.
Finance Payments & Billing
122
einvoicewiz A
com.einvoicewiz
Generate & validate EN 16931 e-invoices (Factur-X, ZUGFeRD, XRechnung); verification certificates
Payments & Billing Legal & Compliance
71
Factur-X e-invoicing A
io.github.LeBorgneAntoine
Generate, validate and read Factur-X / EN 16931 e-invoices (France, EU): PDF/A-3, CII, UBL 2.1.
Finance Legal & Compliance Payments & Billing
41

Related MCP Servers

einvoice-mcp
Finance App Automation
makririch
A
license
A
quality
D
maintenance
MCP server for DACH e-invoicing. Create XRechnung (UBL) and ZUGFeRD 2.3 (Factur-X CII) invoices, validate against EN 16931 rules, extract data from XML, and convert between UBL, CII and JSON formats.
Updated 5 months ago (2026-04-13 15:27 UTC)
6
54
2
MIT
camt053-mcp
Finance Data Platforms
sebastienrousseau
F
license
A
quality
A
maintenance
MCP server that enables AI agents to parse, validate, and reverse ISO 20022 bank statements, with tools for discovering message types and return reasons.
Updated 3 days ago (2026-08-31 14:18 UTC)
24
1
pain001-mcp
Finance Payments & Billing
sebastienrousseau
F
license
A
quality
A
maintenance
A Model Context Protocol server that exposes the pain001 ISO 20022 Customer Credit Transfer Initiation library as agent tools, enabling AI assistants to generate and validate standardized payment XML messages.
Updated 3 days ago (2026-08-31 10:29 UTC)
17
1
acmt001-mcp
Finance Data Platforms
sebastienrousseau
F
license
A
quality
A
maintenance
MCP server for ISO 20022 acmt.001 Account Opening (and companion acmt.* messages): message-type discovery, required-field lookup, JSON Schema introspection, IBAN/BIC/LEI validation, flat-record validation, and validated acmt XML generation.
Updated 5 days ago (2026-08-29 17:47 UTC)
6
1

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastienrousseau/camt-exceptions'

If you have feedback or need assistance with the MCP directory API, please join our Discord server