Skip to main content
Glama

Generate pain XML from a CSV file

generate_message_from_file
Read-onlyIdempotent

Generate validated ISO 20022 pain XML messages from a CSV file on the local disk. Reads one payment record per row and outputs the corresponding XML.

Instructions

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 message type.
    data_file_path: Path to a CSV file with one record per row.

Returns:
    The validated XML, or a JSON-encoded ``{"error": ...}`` payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
message_typeYesA supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.008.001.02' (see list_message_types).
data_file_pathYesLocal filesystem path to a CSV file with one payment record per row and a header matching the template columns (see inspect_template). Only CSV is supported today.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds context about reading from local filesystem, delegating to another function, and path-safety guards. No contradiction with annotations.

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?

Well-structured with clear sections: purpose, usage, args, returns. Front-loaded with the main action. Some technical detail about the load function could be trimmed, but overall efficient.

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?

Covers purpose, alternative tools, input format, return type, and even future plans. Includes output schema reference. Fully adequate for a tool with extensive annotations and sibling guidance.

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 detailed descriptions for both parameters. The description repeats parts of the schema and adds minor context (e.g., CSV-only for data_file_path). No significant new meaning beyond schema.

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 generates validated pain XML from a CSV file. It specifies the resource ('pain XML') and the source ('CSV file on local disk'), and distinguishes from sibling 'generate_message' which works with in-memory dicts.

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?

Explicitly says 'Use this when the records live in a CSV file rather than in memory' and directs to 'generate_message' for dicts. Also mentions current CSV-only support and planned formats, providing when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

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/pain001-mcp'

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