camt-exceptions

generate_message

Read-onlyIdempotent

Generate XSD-validated ISO 20022 E&I XML messages (camt.056/camt.029) from structured records for interbank payment cancellations, recalls, or investigations.

Instructions

Generate a schema-validated ISO 20022 E&I XML message from a record.

Purpose: Renders a complete, XSD-compliant ISO 20022 XML document (e.g. camt.056 payment cancellation or camt.029 investigation resolution) from structured field dictionaries, validating the result against the bundled official schema before returning.

When to use:

When raising payment cancellation, recall, or investigation response messages for interbank transmission.
When requiring guaranteed XSD-valid XML output for downstream payment processing.

When NOT to use:

Do NOT use to validate pre-existing XML files without generating; use validate_xml instead.
Do NOT pass incomplete records; check get_required_fields first.

Behavioral transparency: Pure template rendering and in-memory schema validation; side-effect-free and idempotent.

Input 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.15Jul 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 readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that output is validated against a bundled official XSD before returning and that the process is pure template rendering with in-memory validation, which is useful context beyond annotations, though it repeats the side-effect-free/idempotent claims.

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 well-structured with labeled sections (Purpose, When to use, When NOT to use, Behavioral transparency) and is front-loaded with the core action. Every sentence contributes directly to selection or invocation.

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?

For a complex XML generation tool with an output schema already present, the description covers purpose, alternatives, prerequisites, validation behavior, and examples. It gives the agent enough to call the tool correctly without needing return-value details.

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%, and both parameters are described in the schema. The description adds little parameter-level meaning beyond what the schema already provides, though it reinforces that record fields should follow get_required_fields.

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 (Generate), resource (schema-validated ISO 20022 E&I XML message), and concrete output examples (camt.056, camt.029). It clearly distinguishes itself from validate_xml and get_required_fields by naming them in the 'When NOT to use' section.

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?

It gives explicit when-to-use scenarios (payment cancellation, recall, investigation response) and when-not-to-use exclusions with named alternatives. The agent is told exactly which sibling to use for validation-only or incomplete-record cases.

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

Deploy Server