pacs008-mcp is an MCP server that exposes ISO 20022 pacs payment message tooling to AI agents across five capability areas:
Discovery & Inspection
List all supported pacs message types (e.g., pacs.008, pacs.002, pacs.004) and registered scheme profiles (CBPR+, HVPS+, Fedwire, CHAPS, T2 RTGS, SCT Inst, generic)
Inspect a scheme's rules (UETR requirements, charge bearers, remittance caps, cardinality, LEI)
Retrieve required fields or the full JSON Schema for any message type
Validation
Validate flat payment records against a message type's JSON Schema (row-by-row error reporting)
Validate records against a scheme's business rules
Validate raw XML against the bundled XSD for a given message type
Generation & Parsing
Generate fully XSD-validated ISO 20022 pacs XML from in-memory payment records
Parse and classify inbound ISO 20022 XML, identifying type, family, version, namespace, and Business Application Header
Legacy Migration
Convert SWIFT MT103 messages into pacs.008-ready records (MT→MX migration)
Address Management (November 2026 Compliance)
Classify addresses as structured, hybrid, or unstructured
Validate single or batch addresses against a policy (default: hybrid_or_structured)
Repair legacy unstructured addresses using country-aware heuristics (GB, US, DE, FR, JP)
Provides support for generating, validating, and managing ISO 20022 pacs messages for SEPA Instant Credit Transfers (SCT Inst) and other SEPA payment schemes.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pacs008-mcp generate a pacs.008 XML for a 1000 EUR cross-border payment"
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.
A Model Context Protocol server that exposes the pacs008
ISO 20022 FI-to-FI Customer Credit Transfer library as tools for AI agents and
assistants — discover message types and scheme profiles, validate records
against the JSON Schema and against a rail's usage guidelines, generate
validated XML, validate raw XML against the bundled XSD, and parse inbound
messages, all from your favourite MCP client.
Latest release: v0.0.6 — 15 MCP tools over stdio, all backed by the
pacs008library, for Python 3.10+. Addsconvert_mt103, the legacy SWIFT MT103 → pacs.008 (MT→MX) migration path.
Related MCP server: Pactus
The Model Context Protocol (MCP) is an open standard that lets AI agents
and assistants discover and call external tools in a uniform way. pacs008-mcp
is an MCP server that turns the pacs008 library into a set of
first-class agent tools, so an assistant can generate, validate, and parse
ISO 20022 pacs.008 FI-to-FI Customer Credit Transfer XML messages — and
the related pacs.002/.004 status and return messages — directly from a
conversation.
Every tool is a thin, typed wrapper over the pacs008 library — the same
package used by the CLI and REST API — so all interfaces behave identically.
Tools return JSON-serialisable data; on a validation error they return an
{"error": ...} payload rather than raising.
Website: https://pacs008.com
Source code: https://github.com/sebastienrousseau/pacs008-mcp
Bug reports: https://github.com/sebastienrousseau/pacs008-mcp/issues
flowchart LR
A["MCP client<br/>(Claude Desktop, IDE, agent)"] -->|stdio| B["pacs008-mcp"]
B -->|delegates to| C["pacs008 library"]
C -->|render + validate| D["ISO 20022 pacs XML"]pacs008-mcp runs on macOS, Linux, and Windows and requires Python 3.10+
and pip. It pulls in the core pacs008 library and the MCP SDK
automatically.
python -m pip install pacs008-mcpNote: while the core
pacs008library is not yet on PyPI, install it from source first:python -m pip install "git+https://github.com/sebastienrousseau/pacs008.git" python -m pip install pacs008-mcp
Launch the server over stdio (the FastMCP default transport):
pacs008-mcpRegister it with any MCP client (e.g. Claude Desktop) by adding it to the client's configuration:
{
"mcpServers": {
"pacs008": { "command": "pacs008-mcp" }
}
}All tools wrap the pacs008 library, so they behave identically to the CLI and
REST API.
list_message_types — List the 20 supported ISO 20022 pacs message types
list_schemes — List the registered scheme / usage-guideline profiles
get_scheme — Inspect a scheme profile's rules
get_required_fields — Required input fields for a message type
get_input_schema — Full input JSON Schema for a message type
validate_records — Validate flat records against a message type's schema
validate_scheme — Validate records against a scheme's usage guidelines
generate_message — Generate a validated pacs XML message
validate_xml — Validate a raw XML string against the bundled XSD
parse_message — Parse & classify an inbound ISO 20022 message
convert_mt103 — Convert a legacy SWIFT MT103 into pacs.008-ready records (MT→MX migration)
classify_address — Classify a postal address as structured / hybrid / unstructured
validate_address — Validate one postal address against an address policy
repair_address — Upgrade legacy unstructured address lines toward hybrid/structured form
validate_addresses — Batch-validate every party address across payment rows
On 14 November 2026, fully unstructured postal addresses are decommissioned
across SWIFT CBPR+, HVPS+, TARGET2 RTGS, CHAPS, Fedwire and Lynx — after that
date, any cross-border or high-value payment carrying an unstructured-only
postal address is rejected at the rail. The four address tools above wrap
the pacs008 library's standards.address module so an agent can get ahead of
the deadline: classify_address shows where an address stands, validate_address
/ validate_addresses enforce a policy (defaulting to the cliff rule
hybrid_or_structured, which rejects unstructured addresses), and
repair_address runs country-aware heuristics (GB, US, DE, FR, JP,
plus a best-effort fallback) to lift legacy address lines into hybrid form.
The repair step is experimental — audit its output before submitting downstream.
You can invoke the tools in-process — without a transport — straight through the
FastMCP instance. This mirrors what an agent receives over stdio. The runnable
version of this snippet lives in examples/mcp_tools.py.
import asyncio
from pacs008_mcp.server import server
record = [
{
"msg_id": "MSG001",
"creation_date_time": "2026-01-15T10:30:00",
"nb_of_txs": "1",
"settlement_method": "CLRG",
"interbank_settlement_date": "2026-01-15",
"end_to_end_id": "E2E001",
"interbank_settlement_amount": "1000.00",
"interbank_settlement_currency": "EUR",
"charge_bearer": "SHAR",
"debtor_name": "Debtor Corp",
"debtor_agent_bic": "DEUTDEFF",
"creditor_agent_bic": "COBADEFF",
"creditor_name": "Creditor Ltd",
}
]
async def main() -> None:
async def call(name, args):
result = await server.call_tool(name, args)
content = result[0] if isinstance(result, tuple) else result
return content[0].text if content else ""
print(await call("list_schemes", {}))
xml = await call("generate_message",
{"message_type": "pacs.008.001.08", "records": record})
print(xml[:46]) # -> <?xml version="1.0" encoding="UTF-8"?> ...
asyncio.run(main())Run it directly:
python examples/mcp_tools.pypacs008-mcp uses Poetry and mise.
git clone https://github.com/sebastienrousseau/pacs008-mcp.git && cd pacs008-mcp
mise install
poetry install
poetry shellThis package depends on the core
pacs008library. Until it is on PyPI, install it from source first:pip install "git+https://github.com/sebastienrousseau/pacs008.git".
A Makefile orchestrates the quality gates (kept in lockstep with CI):
make check # all gates (REQUIRED before commit)
make test # pytest
make lint # ruff + black
make type-check # mypy --strictPart of the ISO 20022 MCP Suite — open-source, Apache-2.0 licensed MCP servers for banking and financial-services AI agents:
Server | Purpose |
Generate & validate ISO 20022 pain.001 payment files (v03–v12, pain.008, SEPA) with rulebook checks | |
Parse & reconcile ISO 20022 camt.053 bank-to-customer statements — CBPR+/HVPS+ ready | |
Generate & validate ISO 20022 acmt account-management messages | |
Parse bank statements (BAI2, MT940/MT942, CAMT.053, OFX, CSV) into structured transactions | |
Lossless YAML 1.2 parsing, formatting & validation (Rust, 100% spec compliance) |
mcp-name: io.github.sebastienrousseau/pacs008-mcp
Licensed under the Apache Licence, Version 2.0. Any contribution submitted for inclusion shall be licensed as above, without additional terms.
Contributions are welcome — see the contributing instructions. Thanks to all contributors.
Built on the pacs008 ISO 20022 FI-to-FI Customer Credit Transfer
library and the Model Context Protocol Python SDK.
Classify a postal address as structured, hybrid, or unstructured.
Use this to see where an address stands against the SWIFT structured-address
rule: ``structured`` (town + country + structured detail, no free-form
lines), ``hybrid`` (town + country + 1-2 free-form ``adr_line`` lines, the
minimum CBPR+ UG2026 bar), or ``unstructured`` (free-form only — rejected
from the cliff date). To check acceptability under a policy use
``validate_address``; to upgrade legacy lines use ``repair_address``.
Returns ``{"classification": str, "is_structured": bool, "is_hybrid":
bool, "is_unstructured": bool, "has_structured_fields": bool}`` or an
``{"error": ...}`` payload.
Args:
address: The postal address as a dict of snake_case fields.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | An ISO 20022 PostalAddress27 as a dict of snake_case fields, e.g. {'strt_nm': 'High St', 'bldg_nb': '1', 'pst_cd': 'AB1 2CD', 'twn_nm': 'London', 'ctry': 'GB'} and optional 'adr_line' (list of free-form lines). 'ctry' must be ISO 3166-1 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context beyond annotations by specifying the exact return payload structure and the error payload, plus the policy significance of the unstructured category. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, followed by usage guidance and return contract. The text is slightly longer than strictly necessary because the 'Args' line largely duplicates the schema, but every substantive sentence earns its place by defining categories, giving policy context, or naming sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only classification tool with no output schema, the description is complete: it defines the classification categories, explains when to use it, names alternatives, and documents both success and error return shapes. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the `address` parameter with an example, field semantics, and the ISO 3166-1 alpha-2 requirement. The description's 'Args' line merely restates 'dict of snake_case fields' and adds little beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Classify a postal address as structured, hybrid, or unstructured.' It defines the three output categories and links them to the SWIFT structured-address rule, so an agent can immediately understand what the tool does and how it differs from nearby validation/repair tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('Use this to see where an address stands against the SWIFT structured-address rule') and explicitly names alternatives for other intents: 'To check acceptability under a policy use validate_address; to upgrade legacy lines use repair_address.' This is direct routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a legacy SWIFT MT103 into pacs.008-ready flat records.
This is the SWIFT MT-to-MX migration path (correspondent-banking MT103
coexistence with ISO 20022 ends November 2025): parse an MT103 text
payload and get back the flat pacs.008 record(s) that can be fed straight
into ``validate_records`` / ``generate_message``. An MT103 carries exactly
one transfer, so the ``records`` list always holds a single record. No
file is read or written.
Returns ``{"message_type": "pacs.008.001.08", "records": [{...}]}`` with
the parsed flat record, or an ``{"error": ...}`` payload if the MT103 is
missing a mandatory field (``:20:``, ``:32A:``, beneficiary) or malformed.
Args:
mt103_text: The MT103 payload as a string.
| Name | Required | Description | Default |
|---|---|---|---|
| mt103_text | Yes | A legacy SWIFT MT103 (single customer credit transfer) payload as text. A raw '{4:...-}' block-4 envelope, trailing whitespace and CRLF/LF differences are tolerated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool parses MT103 text, always returns a single record, no file I/O, and error cases when mandatory fields are missing. Annotations already indicated readOnly and idempotent, but the description adds specifics about return format and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, followed by context and details. Slightly long due to background info on coexistence deadline, but every sentence is relevant. Could be trimmed slightly but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a conversion tool with no output schema, the description fully covers return format, error scenarios, and integration with sibling tools. No gaps are identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter mt103_text is fully described in the schema (100% coverage). The description repeats the parameter name and type ('The MT103 payload as a string') but adds no new details beyond the schema's already thorough description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it converts MT103 to pacs.008 records, specifying verb and resource. Distinguishes from siblings like validate_records and generate_message by mentioning these as downstream tools. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: SWIFT MT-to-MX migration path with a deadline (Nov 2025), and states the output feeds into validate_records/generate_message. Does not explicitly state when not to use or name alternatives, but the usage scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a validated ISO 20022 pacs XML message from in-memory records.
This is the primary generation tool: pass payment records you already hold
in memory and receive an XSD-validated XML document; no file is written.
Run ``validate_records`` first to surface record-level errors, and
``list_message_types`` to confirm the ``message_type`` string.
Returns the validated XML document as a string, or an ``{"error": ...}``
payload (serialized) if generation fails.
Args:
message_type: A supported ISO 20022 pacs message type.
records: One or more flat payment records.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | One or more flat payment records, each a dict of field name -> value, from which the pacs XML is generated; run validate_records first to surface record-level errors. | |
| message_type | Yes | A supported ISO 20022 pacs message type, e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer. Must be exactly one of: 'pacs.002.001.12', 'pacs.003.001.09', 'pacs.004.001.11', 'pacs.007.001.11', 'pacs.008.001.01', 'pacs.008.001.02', 'pacs.008.001.03', 'pacs.008.001.04', 'pacs.008.001.05', 'pacs.008.001.06', 'pacs.008.001.07', 'pacs.008.001.08', 'pacs.008.001.09', 'pacs.008.001.10', 'pacs.008.001.11', 'pacs.008.001.12', 'pacs.008.001.13', 'pacs.009.001.10', 'pacs.010.001.05', 'pacs.028.001.05' (see list_message_types). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns validated XML as a string or error payload, and that no file is written, providing further behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, bullet-like usage guidelines, and an Args section. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers prerequisites (validate_records, list_message_types), behavior (no file written), output (XML string or error), and parameter usage. Output schema exists but description still clarifies return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by clarifying that records must be flat payment records and advising to run validate_records first, complementing the schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('validated ISO 20022 pacs XML message from in-memory records'), clearly distinguishing it from sibling tools like validate_records and list_message_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after running validate_records and list_message_types. Also clarifies that no file is written, guiding the agent on behavioral expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full JSON Schema for a message type's flat input record.
Use this to learn every field, its type, and its constraints before
assembling records, or to drive a form/UI. For just the required-field
names use ``get_required_fields``; to check records against this schema use
``validate_records``.
Args:
message_type: A supported ISO 20022 pacs message type.
| Name | Required | Description | Default |
|---|---|---|---|
| message_type | Yes | A supported ISO 20022 pacs message type, e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer. Must be exactly one of: 'pacs.002.001.12', 'pacs.003.001.09', 'pacs.004.001.11', 'pacs.007.001.11', 'pacs.008.001.01', 'pacs.008.001.02', 'pacs.008.001.03', 'pacs.008.001.04', 'pacs.008.001.05', 'pacs.008.001.06', 'pacs.008.001.07', 'pacs.008.001.08', 'pacs.008.001.09', 'pacs.008.001.10', 'pacs.008.001.11', 'pacs.008.001.12', 'pacs.008.001.13', 'pacs.009.001.10', 'pacs.010.001.05', 'pacs.028.001.05' (see list_message_types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds the 'flat' aspect of the input record and that it returns the full JSON Schema, but does not elaborate further on behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: three main sentences plus an Args section. Front-loaded with purpose. No extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (single parameter, rich annotations, no output schema), the description is complete. It covers what the tool does, when to use it, and how it relates to siblings. The return value is implied as a JSON Schema object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description provides a concrete example ('e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer') which adds some value beyond the enum list, but overall does not significantly enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Return the full JSON Schema for a message type's flat input record' with specific verb and resource. It distinguishes from siblings such as get_required_fields and validate_records, clearly differentiating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to learn every field... or to drive a form/UI') and when not to use ('For just the required-field names use get_required_fields; to check records against this schema use validate_records'). Provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List only the required input field names for a pacs message type.
Use this for a quick checklist of the mandatory columns before building
payment records. For full type/format constraints (not just which fields
are required), call ``get_input_schema`` instead.
Args:
message_type: A supported ISO 20022 pacs message type.
| Name | Required | Description | Default |
|---|---|---|---|
| message_type | Yes | A supported ISO 20022 pacs message type, e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer. Must be exactly one of: 'pacs.002.001.12', 'pacs.003.001.09', 'pacs.004.001.11', 'pacs.007.001.11', 'pacs.008.001.01', 'pacs.008.001.02', 'pacs.008.001.03', 'pacs.008.001.04', 'pacs.008.001.05', 'pacs.008.001.06', 'pacs.008.001.07', 'pacs.008.001.08', 'pacs.008.001.09', 'pacs.008.001.10', 'pacs.008.001.11', 'pacs.008.001.12', 'pacs.008.001.13', 'pacs.009.001.10', 'pacs.010.001.05', 'pacs.028.001.05' (see list_message_types). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds context that this tool is a safe, read-only operation that returns field names. No contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one line for purpose, clear usage guidance, and parameter explanation. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (indicated), the description adequately covers purpose, usage, and parameter. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum and description. The description adds value by explaining the message_type parameter's purpose, providing an example format, and referencing list_message_types for available types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List only the required input field names for a pacs message type', which clearly identifies the verb (list) and resource (required field names). It distinguishes from the sibling tool get_input_schema by specifying that this tool only provides required fields, not full type/format constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use: 'Use this for a quick checklist of the mandatory columns before building payment records.' Also tells when not to use and directs to an alternative: 'For full type/format constraints... call get_input_schema instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the rule attributes of a scheme / usage-guideline profile.
Use this to inspect a rail's constraints -- whether the UETR is mandatory,
the permitted charge bearers, remittance-info length cap, per-message
transaction cardinality, pinned message versions, and which parties must
carry an LEI -- before assembling or validating a batch.
Args:
scheme: A registered scheme profile name (see ``list_schemes``).
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | Yes | A registered scheme / usage-guideline profile name (case-insensitive), e.g. 'cbpr_plus', 'fedwire', 'chaps'. Must be one of: 'cbpr+', 'cbpr_plus', 'cbprplus', 'chaps', 'fedwire', 'generic', 'hvps+', 'hvps_plus', 'hvpsplus', 'sct-inst', 'sct_inst', 'sctinst', 't2_rtgs', 't2rtgs', 'target2' (see list_schemes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral detail by listing the specific rule attributes returned (e.g., UETR mandatory, charge bearers), which is valuable for an AI agent even though no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a detailed usage paragraph, and a parameter section. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects), the description is complete. It explains the return content (rule attributes), references a sibling (list_schemes) for getting scheme names, and provides sufficient context for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description in the tool adds a cross-reference to list_schemes and restates the parameter's purpose, providing slight extra value but not substantially beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'the rule attributes of a scheme / usage-guideline profile' and lists specific constraints (UETR mandatory, charge bearers, etc.). It distinguishes from siblings like list_schemes (which returns names) and validate_scheme (which validates) by specifying it inspects the rail's constraints before assembling or validating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use this to inspect a rail's constraints... before assembling or validating a batch.' It also provides an alternative by referencing 'list_schemes' for getting registered scheme names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every supported ISO 20022 pacs message type and its human name.
Use this first, before any generation or validation call, to discover the
exact ``message_type`` strings this server accepts (e.g.
``pacs.008.001.08`` FI-to-FI Customer Credit Transfer). To learn a type's
required fields or full schema, call ``get_required_fields`` or
``get_input_schema`` instead.
Returns a list of ``{"message_type": ..., "name": ...}`` dictionaries, one
per supported message type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by specifying the return format a list of dictionaries with message_type and name, and implies no side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: main action, usage guidance, alternate tool references, and return structure. No extraneous content, properly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only listing) and the existence of an output schema, the description is complete. It summarizes the return structure and how to use the tool in a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivial. Schema description coverage is 100% (no parameters). Baseline for 0 parameters is 4, and no additional param information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every supported ISO 20022 pacs message type and its human name,' using a specific verb ('List') and resource ('pacs message types'). It distinguishes from sibling tools by noting that for required fields or schema, one should use other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool first before generation or validation to discover accepted message_type strings. It also directs to get_required_fields or get_input_schema for further details, providing clear 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.
List every registered scheme / usage-guideline profile.
Scheme profiles (CBPR+, HVPS+, Fedwire, CHAPS, T2 RTGS, SCT Inst, generic)
layer rail-specific rules on top of base ISO 20022. Use this to discover
the ``scheme`` names accepted by ``get_scheme`` and ``validate_scheme``.
Registry aliases (e.g. ``cbpr+``, ``cbprplus``) collapse to their canonical
profile, so each profile appears exactly once. Returns a list of
``{"scheme": ..., "name": ...}`` dictionaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes alias collapsing behavior and uniqueness of profiles, adding context beyond annotations (readOnlyHint, idempotentHint). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with front-loaded purpose, efficient use of examples, and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of output schema, the description fully covers tool behavior, return format, and purpose without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%). Description adds value by explaining return format and behavior, meeting the baseline for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'List every registered scheme / usage-guideline profile' and elaborates with examples of scheme profiles. Clearly distinguishes from sibling tools by noting it discovers scheme names used by get_scheme and validate_scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly advises to use this tool to discover scheme names accepted by get_scheme and validate_scheme. Implicitly distinguishes from other siblings like validate_scheme itself, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse and classify an inbound ISO 20022 XML message.
Use this on the receiving side to identify what a message is -- its
``msg_def_idr`` (e.g. ``pacs.002.001.10``), family, version, and any
Business Application Header -- before processing it. Handles both bare
``Document`` messages and BAH-wrapped envelopes.
Returns a dict with ``msg_def_idr``, ``msg_family``, ``version``,
``root_local_name``, ``namespace_uri``, ``envelope_wrapped`` and ``bah``.
Args:
xml: The raw inbound XML message.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | A raw inbound ISO 20022 XML message (pacs.008 / pacs.002 / pacs.004, optionally BAH-envelope-wrapped) to classify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which align with the description's parse/classify nature. The description adds behavioral details such as handling both bare Document and BAH-wrapped envelopes, and lists return fields, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (approx 100 words), front-loaded with the purpose, and well-structured with an intro and argument section. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists all return fields. It covers handling of both bare and BAH-wrapped messages. For a single-parameter parse tool with good annotations, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the 'xml' parameter. The description's Args section repeats this information without adding significant new details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Parse and classify' and the resource 'inbound ISO 20022 XML message'. It lists specific output fields and distinguishes from siblings like generate_message and validate_xml by focusing on identification before processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this on the receiving side to identify what a message is... before processing it.' This gives clear context. It implies not to use for generation or validation, but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upgrade legacy unstructured address lines toward hybrid/structured form.
Experimental country-aware repair (``GB``, ``US``, ``DE``, ``FR``, ``JP``
have dedicated heuristics; other countries get a best-effort pass promoting
the last line to a town). Use this to lift pre-cliff data over the
November 14, 2026 bar; audit the output before submitting, and keep both
the original and derived address in your audit trail.
Returns ``{"address": {...}, "classification": str, "is_structured":
bool, "is_hybrid": bool}`` (so you can see the unstructured -> hybrid /
structured upgrade) or an ``{"error": ...}`` payload.
Args:
lines: Legacy unstructured address lines.
country: ISO 3166-1 alpha-2 country code driving the heuristics.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | Legacy unstructured address lines (free-form). Empty or whitespace-only lines are skipped. | |
| country | Yes | ISO 3166-1 alpha-2 country code (e.g. 'GB', 'US', 'DE', 'FR', 'JP') used to drive country-aware repair heuristics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior. The description adds transparency about experimental status, country-specific heuristics, return structure (address/classification/is_structured/is_hybrid/error), and the need for auditing. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a title, usage note, return information, and args list. It is informative but not overly verbose. Slightly longer than necessary, but front-loaded with key purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with full schema coverage and no output schema, the description comprehensively covers the return value, usage context, and behavioral notes. It is complete for an AI agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description's parameter explanations largely mirror the schema, adding minimal extra meaning. Baseline 3 is appropriate as the schema already carries the descriptive burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it upgrades legacy unstructured address lines to hybrid/structured form, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like classify_address, though the transformation focus is different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use for pre-cliff data upgrade, audit output, and keep both versions. It also notes the experimental nature and country-specific heuristics. No explicit when-not-to-use or alternative tools mentioned, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate one postal address against an address policy.
Use this to decide whether an address will clear a rail. The default
``hybrid_or_structured`` policy is the November 14, 2026 cliff rule
(SWIFT CBPR+, HVPS+, T2 RTGS, CHAPS, Fedwire, Lynx): it rejects fully
unstructured addresses. Findings mirror the library's pipeline severity
(a policy rejection is a blocking finding).
Returns ``{"policy": str, "classification": str, "is_acceptable": bool,
"findings": [{"severity": str, "message": str}, ...]}`` or an
``{"error": ...}`` payload.
Args:
address: The postal address as a dict of snake_case fields.
policy: The validation policy to enforce (see the enum values).
| Name | Required | Description | Default |
|---|---|---|---|
| policy | No | Postal-address validation policy. 'unstructured_ok' permits any form (pre-cutover / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default; its 14 November 2026 start was deferred on 27 August 2026 and Swift confirms new timing by December); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'. | hybrid_or_structured |
| address | Yes | An ISO 20022 PostalAddress27 as a dict of snake_case fields, e.g. {'strt_nm': 'High St', 'bldg_nb': '1', 'pst_cd': 'AB1 2CD', 'twn_nm': 'London', 'ctry': 'GB'} and optional 'adr_line' (list of free-form lines). 'ctry' must be ISO 3166-1 alpha-2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive behavior. The description adds value beyond that by describing the exact return JSON, the error payload, and the finding-severity semantics (policy rejection is blocking). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is well-organized and front-loaded with the core purpose and return contract. However, the final Args section duplicates detailed parameter descriptions already present in the schema, making the description longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because no output schema is provided, the description appropriately supplies an explicit return format and error payload, which is essential for the agent. It also covers the default policy and its effective-date context. It does not mention routing multi-address cases to validate_addresses, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are thoroughly explained in the input schema, including the policy enum meanings and the address object shape. The description's Args section only restates this information, so it adds no meaningful semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line, 'Validate one postal address against an address policy,' uses a specific verb and resource and clarifies that this operates on a single address. This distinguishes it from siblings like validate_addresses (plural), classify_address, and repair_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to decide whether an address will clear a rail' provides a clear intended-use context, and the default policy explanation gives concrete decision criteria. However, it does not explicitly state when to use a sibling tool instead, such as validate_addresses for batch validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch-validate every party address across a list of payment rows.
Use this before ``generate_message`` to catch addresses that will be
rejected at the rail. The default ``hybrid_or_structured`` policy enforces
the November 14, 2026 cliff. Each finding is reported per offending
``(row, party)`` pair.
Returns ``{"policy": str, "is_valid": bool, "total": int, "errors":
[{"row": int, "party": str, "severity": str, "message": str,
"classification": str}, ...]}`` or an ``{"error": ...}`` payload.
Args:
addresses: One or more payment-row dicts (see the field description).
policy: The validation policy to enforce (see the enum values).
| Name | Required | Description | Default |
|---|---|---|---|
| policy | No | Postal-address validation policy. 'unstructured_ok' permits any form (pre-cutover / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default; its 14 November 2026 start was deferred on 27 August 2026 and Swift confirms new timing by December); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'. | hybrid_or_structured |
| addresses | Yes | Payment-row dicts. The pipeline scans each row for columns of the form '{party}_address_{field}' (party in debtor, creditor, debtor_agent, creditor_agent, ultimate_debtor, ultimate_creditor; field a snake_case PostalAddress field such as twn_nm/ctry/strt_nm or adr_line_0..adr_line_6) and validates each party's address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the default policy, the November 14, 2026 cliff, per-(row, party) error reporting, and the exact return payload, all of which align with the readOnly/idempotent annotations. However, the policy description in the schema notes the cliff was deferred, while the tool description says the policy 'enforces' that cliff, introducing a subtle inconsistency in behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core batch behavior and usage guidance, and the return contract is valuable because there is no output schema. The Args section is largely redundant with the schema, but it is brief and does not seriously bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description compensates by spelling out the return shape and error payload. It also gives invocation context and policy defaults. Gaps include no explicit relationship to validate_address and the cliff-deferral nuance noted above, but the definition is still largely complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description's Args section merely points to the field description and enum values, adding no meaningful semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-object pair: 'Batch-validate every party address across a list of payment rows.' This clearly distinguishes it from the singular validate_address sibling and from nearby validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before generate_message to catch addresses that will be rejected at the rail,' giving a clear when-to-use signal. It does not explicitly contrast with validate_address or provide when-not-to-use guidance, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate flat payment records against a message type's JSON Schema.
Use this before ``generate_message`` to catch structural/type errors per
record and get a row-by-row error report. This checks JSON-Schema shape
only; to check a batch against a rail's usage guidelines use
``validate_scheme``.
Returns a report ``{"is_valid": bool, "total": int, "valid": int,
"errors": [...]}``.
Args:
message_type: A supported ISO 20022 pacs message type.
records: One or more flat payment records to validate.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | One or more flat payment records, each a dict of field name -> value; validated against the message type's input JSON Schema (see get_input_schema / get_required_fields). | |
| message_type | Yes | A supported ISO 20022 pacs message type, e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer. Must be exactly one of: 'pacs.002.001.12', 'pacs.003.001.09', 'pacs.004.001.11', 'pacs.007.001.11', 'pacs.008.001.01', 'pacs.008.001.02', 'pacs.008.001.03', 'pacs.008.001.04', 'pacs.008.001.05', 'pacs.008.001.06', 'pacs.008.001.07', 'pacs.008.001.08', 'pacs.008.001.09', 'pacs.008.001.10', 'pacs.008.001.11', 'pacs.008.001.12', 'pacs.008.001.13', 'pacs.009.001.10', 'pacs.010.001.05', 'pacs.028.001.05' (see list_message_types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds row-by-row error report and scope (JSON-Schema shape only) beyond annotations (readOnly, idempotent). No contradiction; transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-paragraph structure with front-loaded purpose and bullet for return format. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, annotations, and clear return format description, the tool is fully specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description repeats parameter info from schema but adds no significant new meaning; minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it validates flat payment records against a message type's JSON Schema. The verb 'validate' and resource 'records' are specific. It distinguishes from siblings like generate_message and validate_scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before generate_message and mentions validate_scheme as alternative for rail-level checks. Provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate payment records against a scheme's usage-guideline rules.
Use this to check a batch against a rail's rulebook (CBPR+, HVPS+,
Fedwire, CHAPS, T2 RTGS, SCT Inst) -- charge-bearer restrictions, UETR
presence, remittance-info length, and per-message transaction cardinality.
This is complementary to ``validate_records`` (JSON-Schema shape).
Returns ``{"scheme": str, "is_valid": bool, "total": int,
"violations": [...]}``.
Args:
scheme: A registered scheme profile name (see ``list_schemes``).
records: One or more flat payment records to check.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | Yes | A registered scheme / usage-guideline profile name (case-insensitive), e.g. 'cbpr_plus', 'fedwire', 'chaps'. Must be one of: 'cbpr+', 'cbpr_plus', 'cbprplus', 'chaps', 'fedwire', 'generic', 'hvps+', 'hvps_plus', 'hvpsplus', 'sct-inst', 'sct_inst', 'sctinst', 't2_rtgs', 't2rtgs', 'target2' (see list_schemes). | |
| records | Yes | One or more flat payment records, each a dict of field name -> value; checked against the scheme's usage-guideline business rules (charge bearer, UETR, remittance length, per-message cardinality). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds behavioral context by detailing the specific rules checked (charge bearer, UETR, remittance length, cardinality) and the return format including 'is_valid', 'total', and 'violations'. This adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear introductory sentence, usage guidance, a bullet-like list of rule types, and an Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, high schema coverage, no output schema, good annotations), the description is nearly complete: it covers purpose, usage, return format, and parameter details. Minor gaps exist (e.g., error conditions, violation structure), but overall it adequately prepares the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The description goes further by explaining the 'records' parameter as 'one or more flat payment records' and the 'scheme' parameter as a registered profile name from 'list_schemes'. It also lists example rule types, adding context beyond the schema enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Validate payment records against a scheme's usage-guideline rules.' It distinguishes from the sibling tool 'validate_records' by noting it is complementary. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'Use this to check a batch against a rail's rulebook' and lists example schemes. It also mentions it is complementary to 'validate_records', providing context for when to use this tool over alternatives. However, it stops short of explicitly stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a raw XML string against a message type's bundled XSD.
Use this to check an externally produced XML document against the official
ISO 20022 schema. To generate a document that is already XSD-validated,
use ``generate_message`` instead.
Returns ``{"message_type": str, "is_valid": bool}``.
Args:
message_type: A supported ISO 20022 pacs message type.
xml: The raw XML document to validate.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | A raw ISO 20022 XML document to validate against the bundled XSD schema for the given message type. | |
| message_type | Yes | A supported ISO 20022 pacs message type, e.g. 'pacs.008.001.08' FI-to-FI Customer Credit Transfer. Must be exactly one of: 'pacs.002.001.12', 'pacs.003.001.09', 'pacs.004.001.11', 'pacs.007.001.11', 'pacs.008.001.01', 'pacs.008.001.02', 'pacs.008.001.03', 'pacs.008.001.04', 'pacs.008.001.05', 'pacs.008.001.06', 'pacs.008.001.07', 'pacs.008.001.08', 'pacs.008.001.09', 'pacs.008.001.10', 'pacs.008.001.11', 'pacs.008.001.12', 'pacs.008.001.13', 'pacs.009.001.10', 'pacs.010.001.05', 'pacs.028.001.05' (see list_message_types). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is clear. The description adds valuable behavioral context: that validation is against a bundled XSD, and it specifies the return format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs that front-load the purpose and usage guidelines, followed by return format and args. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter validation tool with full schema coverage and safety annotations, the description is quite complete. It specifies the return format, which is helpful given no output schema. Minor omission: no mention of error behavior (e.g., if XML is malformed), but this is not critical for a validation tool returning a boolean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are well-described in the schema with detailed enum and description. The description's Args section essentially repeats the schema information without adding new meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Validate' and the resource 'raw XML string against a message type's bundled XSD'. It differentiates itself from the sibling tool 'generate_message' by explicitly contrasting validation with generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('check an externally produced XML document against the official ISO 20022 schema') and when not to ('To generate a document that is already XSD-validated, use generate_message instead'). This provides clear guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a BIC structurally, optionally enriched by a directory lookup.
Two-stage verification. First an OFFLINE ISO 9362 structural check (via the
pacs008 library): confirms the 8- or 11-character shape and that the
country code (chars 5-6) is a valid ISO 3166-1 alpha-2 code. A malformed
BIC returns ``{"bic": ..., "is_structurally_valid": False, "error": ...}``
and stops there.
Then, only if a directory endpoint is configured (the ``directory_url``
argument or the ``PACS008_BIC_DIRECTORY_URL`` environment variable), the
tool performs a read-only HTTP GET against that endpoint and folds whatever
institution ``name``/``city``/``country``/``status`` it returns into a
``directory`` sub-dict. There is no free authoritative SWIFT BIC directory,
so with NO endpoint configured the tool returns the structural result plus
a ``note`` and ``directory: null`` -- it never fabricates a bank name.
Online lookups require the optional ``online`` extra (``pip install
'pacs008-mcp[online]'``, which pulls in ``httpx``); without it the tool
still returns the structural result plus an ``error`` explaining the
missing extra. Endpoint 4xx/5xx responses and transport failures are
likewise reported as a graceful ``error`` alongside the structural result.
Returns a dict with ``bic``, ``is_structurally_valid``, ``bank_code``,
``country_code``, ``location_code``, ``branch_code``, ``length`` and either
``directory`` (a dict of institution details, or ``null``) plus, when
applicable, ``note`` / ``error``.
Args:
bic: The BIC / SWIFT code to verify.
directory_url: Optional directory endpoint for online enrichment.
| Name | Required | Description | Default |
|---|---|---|---|
| bic | Yes | A BIC / SWIFT code to verify (ISO 9362), 8 or 11 characters, e.g. 'DEUTDEFF' or 'DEUTDEFF500'. Spaces and hyphens are stripped and the value is upper-cased before checking. | |
| directory_url | No | Optional base URL of a BIC directory / reference-data endpoint to enrich the result with institution details. The tool issues a read-only HTTP GET with a '?bic=<BIC>' query parameter and parses the JSON object it returns (name/city/country/status). If omitted, the PACS008_BIC_DIRECTORY_URL environment variable is used; if neither is set, only the offline structural result is returned and NO institution name is inferred. No default/public directory ships with this server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavioral context beyond annotations: two-stage process, offline check details, directory lookup being read-only HTTP GET, no free authoritative directory, never fabricates bank name, graceful error handling, and pip install requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is longer but well-structured with clear sections. Front-loaded with purpose. Each sentence adds necessary detail; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all operational aspects: malformed input, offline-only mode, missing online extra, endpoint errors, return value structure. No output schema needed given the detailed description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant value: bic stripping/uppercasing, directory_url usage with query parameter and env var fallback, and clear note about no default/public directory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and first sentence clearly state it verifies a BIC structurally and optionally with directory lookup. Distinct from sibling tools (no other BIC verification tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes two-stage verification, conditions for online lookup, dependency on optional extra and environment variable, and fallback behavior. Lacks explicit exclusion statements or named alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.12validate_address1 field changedInput schema / properties / policy / descriptionPrevious value: -"Postal-address validation policy. 'unstructured_ok' permits any form (pre-cliff / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default in force from 14 November 2026); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'."New value: +"Postal-address validation policy. 'unstructured_ok' permits any form (pre-cutover / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default; its 14 November 2026 start was deferred on 27 August 2026 and Swift confirms new timing by December); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'."validate_addresses1 field changedInput schema / properties / policy / descriptionPrevious value: -"Postal-address validation policy. 'unstructured_ok' permits any form (pre-cliff / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default in force from 14 November 2026); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'."New value: +"Postal-address validation policy. 'unstructured_ok' permits any form (pre-cutover / generic); 'hybrid_or_structured' rejects fully unstructured addresses (the SWIFT CBPR+ UG2026 default; its 14 November 2026 start was deferred on 27 August 2026 and Swift confirms new timing by December); 'structured_only' requires full structured form. Must be one of: 'unstructured_ok', 'hybrid_or_structured', 'structured_only'."v0.0.7verify_bic_onlinev0.0.4classify_addressconvert_mt103repair_addressvalidate_addressvalidate_addressesv0.1.0generate_messageget_input_schemaget_required_fieldsget_schemelist_message_typeslist_schemesparse_messagevalidate_recordsvalidate_schemevalidate_xmlScored across 16 tools
Every tool targets a clearly distinct resource or action: address classification/validation/repair, schema discovery, record/scheme/XML validation, generation, parsing, and MT103 conversion are all cleanly separated. Even the multiple validate_* tools are disambiguated by their arguments and stated complementary purposes.
All tool names follow a consistent snake_case verb_noun pattern (validate_address, list_schemes, generate_message, parse_message, etc.). The few compound names like verify_bic_online and convert_mt103 still read predictably and do not break the overall convention.
At 16 tools, the server sits just above the typical well-scoped 3-15 range, but the count is justified by the breadth of the pacs.008 domain: discovery, schema, address, BIC, record, scheme, XML, and migration concerns. It is slightly heavy but each tool appears to earn its place.
The surface covers the full payment-message lifecycle: schema discovery, required-field lookup, record and scheme validation, address and BIC checks, message generation, XSD validation, inbound parsing, and MT103 migration. There are no obvious dead ends or missing core operations for the stated purpose.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
