Skip to main content
Glama

Convert legacy MT940 to camt.053

convert_mt940_to_camt053
Read-onlyIdempotent

Convert legacy SWIFT MT940 statements into camt.053 JSON structure. Enables downstream processing of MT940 data until its retirement in 2028.

Instructions

Convert a legacy SWIFT MT940 statement into a camt.053 structure.

Use this as the Phase-1 migration wedge: SWIFT MT940 customer statements
retire in **November 2028**, so this tool bridges the gap by turning raw
MT940 text into the same JSON-serialisable camt.053 document shape that
``parse_statement`` returns (group header plus statements, each with its
account, balances, and entries). Downstream tools (``list_entries``,
``filter_entries``, ``classify_entry``, ``export_journal``) then work on the
result unchanged.

Wraps the ``camt053-loader-mt940`` library's ``parse_mt940``; the MT parsing
itself is delegated (no MT grammar is reimplemented here). The resulting
``ParsedDocument`` is serialised with the same ``to_dict()`` the server's
other parse tools use, so agents get a consistent structure. Nothing is read
from or written to disk.

Returns the converted document as a JSON-serialisable dict, or an
``{"error": ...}`` payload if the MT940 text cannot be parsed (e.g. a
missing ``:20:`` reference or a malformed balance / statement line).

Args:
    mt940_text: The raw MT940 statement text as a string.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mt940_textYesThe raw legacy SWIFT MT940 statement text as a string (``:20:`` / ``:25:`` / ``:28C:`` / ``:60F:`` / ``:61:`` / ``:86:`` / ``:62F:`` fields). Passed verbatim from the bank or ERP; no file path is accepted.
Behavior4/5

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

Description adds value beyond annotations: explains library delegation, no disk I/O, error return format with specific examples. Annotations already declare read/hint/idempotent; description reinforces safety and adds technical detail.

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?

Front-loaded with purpose, well-structured into migration context and technical details. Slightly verbose but every sentence earns its place. Could be tightened slightly.

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?

Covers all relevant aspects: purpose, usage context, error handling, relationship to siblings, technical implementation. Lacks detailed output structure but references parse_statement's shape and mentions return type.

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 detailed description for the single parameter. Description's Args section mostly repeats the schema but adds context about expected MT940 fields. Baseline 3 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?

Verb 'convert' + specific resources 'legacy MT940' and 'camt.053' clearly state the tool's function. Distinguishes from sibling 'parse_statement' by framing as a migration wedge for legacy format.

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 recommends use as Phase-1 migration wedge with retirement date November 2028. States that downstream tools work on result unchanged, implying alternatives like 'parse_statement' for native camt.053.

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

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