1. Click on "Deploy 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., "@Pactus Parse this pacs.008 XML message for me." 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.

Pactus

by deniskarlinsky

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Pactus

PyPI

Pactus is an MCP server for parsing and validating ISO 20022 payment messages directly from chat. It exposes nine tools that let AI assistants inspect or validate pacs.008, pacs.002, pain.001, and camt.053 messages — the message types at the centre of the CBPR+ migration — without leaving the conversation. It is aimed at developers and bank-integration teams who need to read, debug, or explain ISO 20022 traffic during the transition away from MT messages.

Status

pip install pactus-mcp
# or
uv add pactus-mcp

Related MCP server: pain001-mcp

Quick start

git clone https://github.com/deniskarlinsky/iso20022-mcp
cd iso20022-mcp
uv sync
uv run pytest

Connecting to Claude Desktop

Install via uvx for zero-setup use, or run from a local checkout for development.

Add Pactus to your Claude Desktop config:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

From PyPI (recommended)

{
  "mcpServers": {
    "pactus": {
      "command": "uvx",
      "args": ["pactus-mcp"]
    }
  }
}

From a local clone (for development)

{
  "mcpServers": {
    "pactus": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/iso20022-mcp", "pactus-mcp"]
    }
  }
}

Restart Claude Desktop. The Pactus tools will appear in the tools menu.

Available tools

Tool	Message type	Purpose
`ping`	—	Health check; returns service name and version.
`parse_pacs008`	`pacs.008.001.08`	Parse a FI-to-FI Customer Credit Transfer.
`parse_pacs002`	`pacs.002.001.10`	Parse a FI-to-FI Payment Status Report.
`parse_pain001`	`pain.001.001.09`	Parse a Customer Credit Transfer Initiation.
`parse_camt053`	`camt.053.001.08`	Parse a Bank-to-Customer Account Statement.
`validate_pacs008`	`pacs.008.001.08`	Validate a FI-to-FI Customer Credit Transfer against its XSD.
`validate_pacs002`	`pacs.002.001.10`	Validate a FI-to-FI Payment Status Report against its XSD.
`validate_pain001`	`pain.001.001.09`	Validate a Customer Credit Transfer Initiation against its XSD.
`validate_camt053`	`camt.053.001.08`	Validate a Bank-to-Customer Account Statement against its XSD.

The four parse tools return a structured Pydantic model on success, or {"error": "..."} on failure. The four validate tools return a ValidationReport listing every XSD violation with line, column, and path information — even when there are multiple errors. All tools never raise; the agent can explain what went wrong.

Tool reference

parse_pacs008

pacs.008 is the primary interbank credit transfer message and the mandatory format for all CBPR+ cross-border traffic from November 2025. It carries one or more credit transfer instructions between financial institutions, each with settlement amount, charge bearer, debtor, and creditor agents.

{
  "group_header": {
    "message_id": "MSG20240508001",
    "creation_datetime": "2024-05-08T10:00:00",
    "number_of_transactions": 1,
    "settlement_method": "CLRG"
  },
  "transactions": [
    {
      "end_to_end_id": "E2E20240508001",
      "transaction_id": "TX20240508001",
      "settlement_amount": {"value": "1000.00", "currency": "USD"},
      "charge_bearer": "SHAR",
      "debtor": {"name": "Acme Corporation"},
      "debtor_agent": {"bic": "CHASUS33"},
      "creditor": {"name": "Global Supplies Ltd"},
      "creditor_agent": {"bic": "DEUTDEDB"}
    }
  ]
}

parse_pacs002

pacs.002 is the status report sent in response to a pacs.008. It reports whether each transaction was accepted, rejected, or is in an intermediate state. Rejections carry one or more structured reason codes (e.g. AC01 incorrect account, AG01 transaction forbidden) that explain the outcome.

{
  "group_header": {
    "message_id": "STS20260510001",
    "creation_datetime": "2026-05-10T14:30:00"
  },
  "original_group_info": {
    "original_message_id": "MSG20240508001",
    "original_message_name_id": "pacs.008.001.08",
    "original_creation_datetime": "2024-05-08T10:00:00",
    "group_status": "ACSC"
  },
  "transaction_statuses": [
    {
      "original_end_to_end_id": "E2E-001",
      "original_transaction_id": "TX-001",
      "status": "ACSC",
      "status_reasons": [],
      "acceptance_datetime": "2026-05-10T14:29:45"
    }
  ]
}

parse_pain001

pain.001 is the initiating message in a credit transfer flow, sent by a corporate or customer to their bank. It groups transactions into one or more PaymentInformation batches that share a debtor account, execution date, and service level. The LLM sees the full hierarchy: group header → batches → transactions.

{
  "group_header": {
    "message_id": "PAIN20260510-001",
    "creation_datetime": "2026-05-10T09:00:00",
    "number_of_transactions": 1,
    "control_sum": "1500.00",
    "initiating_party_name": "ACME Corp"
  },
  "payment_informations": [
    {
      "payment_information_id": "BATCH-2026-05-10-A",
      "payment_method": "TRF",
      "requested_execution_date": "2026-05-12",
      "debtor": {"name": "ACME Corp"},
      "debtor_account_iban": "DE89370400440532013000",
      "debtor_agent": {"bic": "DEUTDEFFXXX"},
      "charge_bearer": "SLEV",
      "service_level_code": "SEPA",
      "transactions": [
        {
          "end_to_end_id": "E2E-PAIN-001",
          "amount": {"value": "1500.00", "currency": "EUR"},
          "creditor": {"name": "Acme Supplier SARL"},
          "creditor_account_iban": "FR1420041010050500013M02606",
          "remittance_info": ["Invoice 2026-0042"]
        }
      ]
    }
  ]
}

parse_camt053

camt.053 is the structured account statement sent by a bank to its customer. It reports opening and closing balances and individual debit/credit entries for a period, each optionally broken down to individual transaction details. It is the primary source for automated bank reconciliation.

{
  "group_header": {
    "message_id": "CAMT053-SINGLE-001",
    "creation_datetime": "2026-05-10T08:00:00"
  },
  "statements": [
    {
      "statement_id": "STMT-2026-05-09-001",
      "account_iban": "DE89370400440532013000",
      "account_currency": "EUR",
      "balances": [
        {
          "type_code": "OPBD",
          "amount": {"value": "10000.00", "currency": "EUR"},
          "credit_debit": "CRDT",
          "balance_date": "2026-05-09"
        }
      ],
      "entries": [
        {
          "entry_ref": "NTRY-001",
          "amount": {"value": "1500.00", "currency": "EUR"},
          "credit_debit": "DBIT",
          "status": "BOOK",
          "booking_date": "2026-05-09",
          "bank_tx_domain": "PMNT",
          "bank_tx_family": "ICDT",
          "bank_tx_subfamily": "ESCT"
        }
      ]
    }
  ]
}

validate_pacs008

Validates a pacs.008.001.08 message against its XSD and returns every violation in one pass. Use this when you need to know all the errors in a message rather than just the first one the parser encounters.

{
  "valid": false,
  "schema_id": "pacs.008.001.08",
  "violations": [
    {
      "line": 5,
      "column": 3,
      "path": "/{urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08}Document/{urn:...}FIToFICstmrCdtTrf",
      "message": "Element '{urn:...}WrongElement': This element is not expected.",
      "domain": "SCHEMASV",
      "type_name": "SCHEMAV_CVC_COMPLEX_TYPE_2_4",
      "level": "ERROR"
    }
  ]
}

validate_pacs002

Validates a pacs.002.001.10 message against its XSD and returns every violation in one pass.

validate_pain001

Validates a pain.001.001.09 message against its XSD and returns every violation in one pass.

validate_camt053

Validates a camt.053.001.08 message against its XSD and returns every violation in one pass.

Security model

XXE and entity-expansion hardening: All parse and validate tools reject input containing <!DOCTYPE> or <!ENTITY> declarations before any XML parsing occurs. This blocks XXE file-read, SSRF, and billion-laughs DoS patterns.
Build integrity: Generated xsdata models are SHA-256 verified in CI on every commit (sha256sum -c GENERATED_HASHES.txt). Regeneration is reproducible from the vendored XSDs.
Supply chain: GitHub Actions workflows use SHA-pinned action references (commit-hash @ pins, not mutable tags).
Distribution integrity: PyPI artifacts are published via OIDC Trusted Publishing and signed with Sigstore. SBOMs (CycloneDX and SPDX) are generated and vulnerability-scanned on every CI run; release artifacts include the SBOM.
Vulnerability disclosure: See SECURITY.md.

Architecture

Pactus uses a hexagonal layout: pactus/core/ is pure business logic with no MCP awareness, mcp_server.py is a thin FastMCP wrapper, and the generated xsdata models live in pactus/generated/ and never escape parsers.py. See architecture.md for the diagram.

Development

uv run ruff check
uv run ruff format
uv run mypy
uv run pytest

The project targets mypy --strict.

License

MIT

Available Tools

9 tools

parse_camt053A

Parse a camt.053.001.08 Bank-to-Customer Cash Management Statement.

camt.053 is the structured account statement sent by a bank to its customer. It reports balances (opening, closing, interim) and individual debit/credit entries for a period, each optionally broken down to individual transaction details. It is the primary source for automated bank reconciliation.

Returns a structured ParsedCamt053 on success, or {"error": "..."} on failure.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The camt.053 XML message as a string.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Discloses return format (ParsedCamt053 on success, error on failure) and intended purpose. No annotations exist, so description adequately covers behavioral traits for a read-only parsing tool.

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?

Six sentences with no fluff. First sentence states action, second provides context, third explains return. Efficiently structured and front-loaded.

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?

Simple tool with one parameter and output schema present. Description explains business context (accounts statement, bank reconciliation) and return value. Complete for given complexity.

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?

Only parameter 'xml' is fully described in schema (100% coverage). Description adds no extra meaning beyond 'The camt.053 XML message as a string.' Baseline score of 3 applies.

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?

Specifically states 'Parse a camt.053.001.08 Bank-to-Customer Cash Management Statement', identifies the exact message type, and distinguishes from sibling tools (e.g., parse_pacs008) by focusing on a unique resource.

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?

Clearly describes when to use: for bank reconciliation with camt.053 statements. Does not explicitly state when not to use or list alternatives, but sibling context implies other parse tools for different messages.

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

parse_pacs002A

Parse a pacs.002.001.10 (FI-to-FI Payment Status Report) message.

pacs.002 is the response to a pacs.008 credit transfer. It reports whether each transaction was accepted, rejected, or is in an intermediate state. Each transaction carries a status code and optionally one or more structured reason codes explaining the outcome.

Returns a structured ParsedPacs002 on success, or {"error": "..."} on failure.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pacs.002 XML message as a string.

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?

The description discloses the return behavior: a structured ParsedPacs002 on success or an error object on failure. It also describes the content of the pacs.002 message (status codes and reason codes). Since no annotations are provided, this is adequate, though side effects are not mentioned (likely none).

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, front-loaded, and well-structured. It starts with the main purpose, adds domain context, and ends with return behavior. Every sentence adds value.

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 presence of an output schema, the description adequately covers the essential context: input (XML string), output structure, and relation to other message types. It does not address encoding or size limits, but these are not critical for parsing tools.

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% with a description for the 'xml' parameter. The tool description does not add significant meaning beyond the schema; it simply restates that the parameter is the XML message. Baseline for high coverage is 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 clearly states it parses a pacs.002.001.10 message, specifies it is the response to pacs.008, and distinguishes it from sibling parse tools like parse_pacs008. The verb 'parse' and resource 'pacs.002' are explicit.

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 explains that pacs.002 is the response to a pacs.008 credit transfer, providing context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives beyond the implied sibling tools.

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

parse_pacs008A

Parse a pacs.008.001.08 (FI-to-FI Customer Credit Transfer) message.

pacs.008 is the most common ISO 20022 message in cross-border payments and is required for all SWIFT cross-border traffic from November 2025. Each message carries one or more credit transfer instructions between financial institutions.

Returns a structured ParsedPacs008 with the group header (message-level metadata) and a list of transactions (each instruction). On parse or validation failure, returns {"error": "..."} so the agent can explain rather than crashing.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pacs.008 XML message as a string.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavior: it returns a structured ParsedPacs008 object or an error dictionary on failure, preventing crashes. This tells the agent exactly what to expect.

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. It starts with the core purpose, provides relevant context, and ends with return behavior. Every sentence is informative without redundancy.

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 description covers purpose, usage context, and error handling. Although an output schema exists but is not shown, the description summarizes the return structure adequately. It could potentially mention more about the parsed fields, but remains sufficient for an agent.

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?

The single parameter 'xml' is fully described in the schema with coverage of 100%. The description does not add extra meaning beyond what the schema already states, meeting the baseline expectation.

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 identifies the tool as parsing a pacs.008.001.08 message, providing specific context about its use in cross-border payments and SWIFT requirements. It distinguishes from sibling tools that handle different message types (pacs002, pain001, etc.).

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 explains the tool's role in parsing pacs.008 messages and mentions its importance for SWIFT traffic. While it does not explicitly list alternatives or when not to use it, the context of siblings (e.g., validate_pacs008) implies the distinction between parsing and validation.

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

parse_pain001A

Parse a pain.001.001.09 Customer Credit Transfer Initiation message.

pain.001 is the initiating message in a credit transfer flow, sent by a corporate or customer to their bank. It carries one or more payment batches (PaymentInformation), each grouping transactions that share a debtor account, execution date, and service level.

Returns a structured ParsedPain001 on success, or {"error": "..."} on failure.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pain.001 XML message as a string.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description reveals that the tool returns a structured object on success or an error on failure. It mentions the message's internal batches but does not detail edge cases, validation behavior, or 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.

Conciseness4/5

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

The description is efficient, using three sentences to convey purpose, structure context, and return type. It is front-loaded with the core action, though the middle paragraph could be slightly tighter.

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 (one parameter) and presence of an output schema, the description sufficiently covers the input and output. It explains the message's batch structure, which aids understanding, though error details are sparse.

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?

The sole parameter 'xml' is fully described in the schema. The description adds no further detail about format, size limits, or encoding, so it provides minimal value beyond the schema.

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

Purpose4/5

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

The description clearly states it parses a specific pain.001.001.09 message, providing context about its role in credit transfers. It distinguishes from sibling parsing tools (e.g., parse_pacs008) by naming the message type and describing its structure.

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 explains the message's purpose but does not explicitly state when to use this tool over alternatives. It implies usage when a pain.001 XML is encountered, but lacks guidance on prerequisites or exclusion criteria.

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

pingB

Health check tool. Returns service metadata.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

Description states it returns service metadata, but no annotations are provided to cover behavioral traits like side effects or auth needs. Minimal disclosure of what 'metadata' entails is given.

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 concise sentences with no redundancy. Every word serves a purpose, making it efficient for quick understanding.

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

Completeness3/5

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

For a simple tool with no parameters, the description is minimal but sufficient. The presence of an output schema covers return value details, so completeness is adequate.

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, so schema coverage is 100%. The description does not need to add parameter meaning; it adequately explains the tool's action.

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

Purpose4/5

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

The description clearly states it is a health check tool that returns service metadata. Its purpose is distinct from sibling tools (parsing/validating financial messages), though not explicitly differentiated.

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 or when to avoid it. The context of sibling tools implies it's for service health checks, but explicit when-to-use/when-not-to-use instructions are missing.

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

validate_camt053A

Validate a camt.053.001.08 message against its XSD.

Returns a structured ValidationReport listing every XSD violation found, with line/column/path information. Unlike parse_camt053, this does not stop at the first error — all violations are reported so the user can fix them in one pass.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The camt.053 XML message as a string.

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?

No annotations are provided, so the description fully carries behavioral disclosure. It explains that validation returns a structured report with line/column/path info and that it doesn't stop at first error, which is key behavioral context. However, it does not mention idempotency or side effects, though validation is inherently read-only.

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 two sentences, each earning its place: the first states the purpose, the second adds behavioral detail and contrast with a sibling. No wasted words.

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 that an output schema exists (implied by 'structured ValidationReport'), the description does not need to detail return fields. It does describe key output features (line/column/path, all violations). It could mention handling of malformed XML but that is likely covered by XSD validation. The tool is simple with one parameter, so the description is adequate.

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?

The input schema has 100% description coverage for the single parameter 'xml', which is already described as 'The camt.053 XML message as a string.' The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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 a specific message type (camt.053.001.08) against its XSD, with a specific verb and resource. It also distinguishes itself from the sibling tool parse_camt053 by noting it reports all violations.

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 a comparison with parse_camt053, explaining why one might choose it over parsing. However, it does not explicitly state when to validate vs. other sibling tools like validate_pacs008, or mention prerequisites like schema availability.

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

validate_pacs002A

Validate a pacs.002.001.10 message against its XSD.

Returns a structured ValidationReport listing every XSD violation found, with line/column/path information. Unlike parse_pacs002, this does not stop at the first error — all violations are reported so the user can fix them in one pass.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pacs.002 XML message as a string.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description adequately discloses that validation is against XSD, it reports all violations (not just first), and provides line/column/path information. It could mention if the operation is read-only, but the behavior is well-explained.

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 concise sentences with no filler. The first states the primary function, the second adds the critical differentiator. Every word earns its place.

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 tool has a single parameter, full schema coverage, and an output schema (though not shown), the description covers the essential behavior and distinguishes it from siblings. It is complete for its complexity level.

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?

The schema already describes the 'xml' parameter fully, so the description adds value by clarifying the validation context (XSD) and output format. This goes beyond mere schema information.

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 a pacs.002.001.10 message against its XSD, and specifically contrasts with the sibling parse_pacs002, which stops at the first error. This makes the purpose distinct and unambiguous.

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 explains when to use this tool instead of parse_pacs002 (to get all violations in one pass). It does not discuss other alternatives or when not to use it, but the sibling context makes usage clear.

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

validate_pacs008A

Validate a pacs.008.001.08 message against its XSD.

Returns a structured ValidationReport listing every XSD violation found, with line/column/path information. Unlike parse_pacs008, this does not stop at the first error — all violations are reported so the user can fix them in one pass.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pacs.008 XML message as a string.

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?

With no annotations, the description discloses key behaviors: validation against XSD, returning all violations with location details, and not stopping at the first error. Does not mention side effects or statelessness, but validation implies read-only.

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 concise sentences, front-loaded with purpose, second sentence adding unique value and differentiation. Every sentence earns its place.

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?

With an output schema existing, the description covers essential aspects: validation scope, report contents, and error reporting behavior. Could mention that it only performs schema validation (not business rules), but the XSD reference implies that.

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 adds no new information beyond the schema's parameter description. Baseline score applies.

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 a specific message type (pacs.008.001.08) against its XSD. It distinguishes itself from the sibling parse_pacs008 by highlighting that it returns all violations rather than stopping at the first error.

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?

Explicitly contrasts with parse_pacs008, guiding users when to choose this tool for comprehensive validation. No explicit exclusion for other siblings, but the message type differentiation in the name suffices.

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

validate_pain001A

Validate a pain.001.001.09 message against its XSD.

Returns a structured ValidationReport listing every XSD violation found, with line/column/path information. Unlike parse_pain001, this does not stop at the first error — all violations are reported so the user can fix them in one pass.

ParametersJSON Schema

Name	Required	Description	Default
`xml`	Yes	The pain.001 XML message as a string.

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?

No annotations provided, so description bears full weight. It discloses that it returns all violations, does not stop at first error, and includes line/column/path info. Lacks details on side effects or auth needs, but otherwise transparent.

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 succinct sentences. First sentence delivers core purpose; second adds behavioral detail and sibling differentiation. Zero wasted words.

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 single parameter, existing output schema, and sibling context, the description sufficiently covers behavior and differentiation. Does not mention prerequisites (e.g., network access), but overall 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?

With 100% schema description coverage (xml parameter already described in schema), the description adds minimal parameter-specific meaning beyond context. Baseline 3 is appropriate.

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 states a specific verb ('Validate') and resource ('pain.001.001.09 message against its XSD'). It also distinguishes the tool from sibling parse_pain001, making the purpose unmistakably clear.

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?

Explicit comparison to parse_pain001 tells the agent when to use this tool (for comprehensive validation) vs. its sibling (which stops at first error). No explicit when-not scenarios, but the guidance is strong.

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.

9 tool updatesv1.1.0Jul 29, 2026
- First observedparse_camt053
- First observedparse_pacs002
- First observedparse_pacs008
- First observedparse_pain001
- First observedping
- First observedvalidate_camt053
- First observedvalidate_pacs002
- First observedvalidate_pacs008
- First observedvalidate_pain001

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-07-29 07:25 across 9 tools

Disambiguation5/5

Each tool targets a specific ISO 20022 message type and action (parse vs validate), with no overlap. The ping tool is uniquely for health checks.

Naming Consistency5/5

All tools follow a consistent verb_messageType pattern (e.g., parse_pacs008, validate_pacs002). The naming is uniform and predictable.

Tool Count5/5

9 tools cover the essential operations (parse and validate) for four common payment message types. The count is well-scoped for this domain.

Completeness4/5

The server covers the core parse and validate needs for the most frequent ISO 20022 payment messages. A minor gap is the absence of related messages like camt054 or pacs004, but the current set is sufficient for typical use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

banking-intelligence A
ai.ohmyfin
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Finance Payments & Billing Legal & Compliance
342
modern-treasury A
io.usefulapi
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Finance Payments & Billing
172
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
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

Related MCP Servers

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 6 days ago (2026-09-08 22:52 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 2 days ago (2026-09-12 21:37 UTC)
21
1
-
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 16 days ago (2026-08-29 18:44 UTC)
16
1
-
swift-iso20022-mcp
techybiky
A
license
A
quality
C
maintenance
An MCP server that provides AI agents with tools to validate SWIFT MT and ISO 20022 MX payment messages, check BIC/IBAN correctness, and convert between MT and MX formats.
Updated 2 months ago (2026-07-18 11:15 UTC)
7
2 npm
MIT