iso20022-mcp

generate

Read-onlyIdempotent

Create validated ISO 20022 XML messages from flat records for outbound payments and interbank messages, returning XML or listing all missing/invalid fields to fix.

Instructions

Generate a validated ISO 20022 XML message from records; the XML document is returned in the 'xml' key. On failure the 'error' value lists every missing or invalid field at once — fix them all and retry once. When to use: Outbound initiation and interbank messages (pain.001, pacs.008, acmt.001, camt.056). Not for: Inbound statements (camt.053); they have no generator and return an explanatory error. Behavior: Pure transformation; read-only and idempotent.

Input Schema

Name	Required	Description	Default
`records`	Yes	List of flat record objects (field name → value). Field names come from the family's input schema — call describe(message_type) for the required fields. For pain.001 credit transfers the key fields are: id, date ('YYYY-MM-DD' accepted), initiator_name, payment_id, requested_execution_date ('YYYY-MM-DD'), debtor_name, debtor_account_IBAN, debtor_agent_BIC, creditor_name, creditor_account_IBAN, creditor_agent_BIC, payment_amount (alias 'amount'), currency (alias 'payment_currency'), remittance_information; batch_booking takes JSON true/false, and nb_of_txs/ctrl_sum are computed automatically. IBAN and BIC values are strictly validated, never coerced.
`message_type`	Yes	ISO 20022 message type, e.g. 'pain.001.001.09', 'pacs.008' or 'camt.053'. For pain messages a fully-versioned type is preferred; the bare family name 'pain.001' resolves to 'pain.001.001.09'.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.5Jul 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/destructive=false, so 'pure transformation; read-only and idempotent' is largely redundant. However, the description adds genuinely new behavior: errors list every missing/invalid field at once and the caller should fix all and retry once. That error/retry contract is valuable context not present in 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?

Front-loaded with purpose and return value, then clearly labeled 'When to use', 'Not for', and 'Behavior' segments. Dense but every clause carries signal; no filler sentences.

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?

An output schema exists, so return values need not be fully re-explained, yet the 'xml'/'error' keys are still surfaced. Purpose, routing, failure behavior, and validation strictness are all covered for a 2-parameter transformation tool.

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 description coverage is 100%, so both parameters are already documented in depth (fields, aliases, validation). The description adds little parameter-specific meaning beyond reiterating validation behavior, so the baseline 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?

States a specific verb and resource ('Generate a validated ISO 20022 XML message from records') and immediately names the return key. It is clearly distinguishable from siblings like parse and validate, and the message-family examples make the scope concrete.

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

Usage Guidelines5/5

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

Has explicit 'When to use' (outbound initiation and interbank messages) and 'Not for' (inbound camt.053, which has no generator). Both inclusion and exclusion conditions are spelled out, leaving nothing to inference.

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

Deploy Server