Skip to main content
Glama
sebastienrousseau

iso20022-bank-profile-mcp

iso20022-bank-profile-mcp: The ISO 20022 Bank Clearing-Profile Server

PyPI Version Python Versions License Tests Quality OpenSSF Scorecard Documentation

A fully local, closed-world Model Context Protocol server that manages, validates, and serves bank-specific ISO 20022 clearing profiles / rule packs — the market-practice rules that sit beyond structural XSD validation. It is a foundational member of the ISO 20022 MCP Suite and a sibling of iso20022-readiness-suite-mcp, whose readiness gateway can consume the profiles this server serves.

The November 2026 milestones. As the major schemes (CBPR+, HVPS+, T2, FedNow) tighten their ISO 20022 requirements — structured postal addresses chief among them — a payment that was fine yesterday can be rejected tomorrow. iso20022-bank-profile-mcp turns those scheme rules into versioned, agent-callable clearing profiles: list_profiles and get_profile serve them, lint_payload evaluates a payload against one, and validate_profile_definition vets a bank-supplied rule pack. v0.0.2, stdio by default (plus an optional OAuth 2.1 HTTP transport), 4 read-only tools, premium rule-pack entitlement gating, Python 3.10+.

Contents

Related MCP server: camt053-mcp

Overview

The Model Context Protocol (MCP) is an open standard that lets AI agents and assistants discover and call external tools in a uniform way. iso20022-bank-profile-mcp owns the market-practice profile layer of the ISO 20022 MCP Suite: the scheme-specific and bank-specific rules a payment must satisfy to clear, which live above the XSD and vary by clearing system.

A clearing profile is pure data — a profile_id, its market_practice, the messages it supports, and a list of declarative custom_rules. The server ships open baseline profiles (Generic, CBPR+, SEPA_Instant, FedNow) and exposes four read-only tools to discover them, fetch them in full, lint a payload against one, and validate a candidate rule pack.

It is a fully local, closed-world server: no network surface, no sub-servers, no meta-client. Every tool computes from the bundled profile data and returns typed, JSON-serialisable output; on any failure — a bad input, an unparseable payload, an unknown profile — it returns an {"error": ...} payload rather than raising into the client transport. XML payloads are parsed with defusedxml only (no XXE / billion-laughs).

flowchart TD
    A["MCP client<br/>(Claude Desktop, IDE, agent)"] -->|stdio| B["iso20022-bank-profile-mcp<br/>(clearing-profile server)"]
    B --> C["ProfileEngine<br/>(bundled JSON + register() seam)"]
    C --> D["Generic"]
    C --> E["CBPR+"]
    C --> F["SEPA_Instant"]
    C --> G["FedNow"]
    H["iso20022-readiness-suite-mcp<br/>(readiness gateway)"] -.consumes profiles.-> B

The ISO 20022 MCP Suite

iso20022-bank-profile-mcp is one of a set of coordinated, vendor-neutral MCP servers for the ISO 20022 migration. Dependency ranges are kept aligned across the suite, so the servers co-install cleanly in a single Python environment.

Server

Scope

Install

iso20022-readiness-suite-mcp

Orchestration gateway: readiness scoring, remediation, clearing-profile linting, and bank-response simulation over the foundational servers

pip install iso20022-readiness-suite-mcp

iso20022-evidence-pack-mcp

Compiles readiness findings, remediation diffs and simulated responses into a sealed, Ed25519-signable audit evidence pack

pip install iso20022-evidence-pack-mcp

structured-address-fix-mcp

ISO 20022 postal-address classification, assessment, and remediation for the Nov 2026 structured-address cliff

pip install structured-address-fix-mcp

iso20022-mcp

Unified gateway meta-tools (search / describe / validate / generate / parse) across the ISO 20022 message catalogue

pip install iso20022-mcp

camt053-mcp

ISO 20022 camt.05x bank statements: parse, validate, filter, reverse; MT94x migration; CBPR+ readiness

pip install camt053-mcp

pain001-mcp

Generate & validate ISO 20022 pain.001 payment-initiation files (v03–v12, pain.008, SEPA) with rulebook checks

pip install pain001-mcp

reconcile-mcp

Reconcile ISO 20022 payments and statements; match initiations to their bank-side outcomes

pip install reconcile-mcp

bankstatementparser-mcp

Parse bank statements (MT940/MT942 and camt) into structured, agent-friendly data

pip install bankstatementparser-mcp

Where the foundational servers each do one message job well and the readiness gateway composes them, this server owns the clearing profiles: it manages, validates, and serves the market-practice rule packs the rest of the suite lints against.

Install

iso20022-bank-profile-mcp runs on macOS, Linux, and Windows and requires Python 3.10+ and pip. It pulls in the MCP SDK, pydantic, and defusedxml automatically — all published on PyPI.

python -m pip install iso20022-bank-profile-mcp

Or run it without installing, straight from PyPI, with uvx:

uvx iso20022-bank-profile-mcp
python -m venv venv
source venv/bin/activate        # macOS/Linux
venv\Scripts\activate           # Windows
python -m pip install -U iso20022-bank-profile-mcp

Quick Start

For the 10-minute install → MCP client config → first conversation tutorial, see docs/quickstart.md.

Launch the server over stdio (the FastMCP default transport):

iso20022-bank-profile-mcp

Register it with any MCP client (e.g. Claude Desktop) by adding it to the client's configuration:

{
  "mcpServers": {
    "iso20022-bank-profile": { "command": "iso20022-bank-profile-mcp" }
  }
}

The command speaks MCP on stdin/stdout — it is meant to be launched by an MCP client, not used interactively. The agent can then call the tools below.

You can also invoke the tools in-process — without a transport — straight through the FastMCP instance. This mirrors what an agent receives over stdio; everything is local, so no other servers are needed:

import asyncio

from iso20022_bank_profile_mcp import server


async def main() -> None:
    async def call(name, args):
        result = await server.server.call_tool(name, args)
        # mcp 2.x returns a CallToolResult (use .content); 1.x returns
        # the content list, or a (content, meta) tuple.
        content = getattr(result, "content", None)
        if content is None:
            content = result[0] if isinstance(result, tuple) else result
        return content[0].text if content else ""

    # Which clearing profiles can I target?
    print(await call("list_profiles", {}))
    # -> {"profile_id": "...", "market_practice": "...", "rule_count": ...}, ...

    # Lint a payload against a profile: a CBPR+ address missing its town.
    payload = "<Document><PstlAdr><Ctry>DE</Ctry></PstlAdr></Document>"
    print(await call("lint_payload",
                     {"payload_content": payload, "profile_id": "CBPR+"}))
    # -> {"profile_id": "CBPR+", "is_compliant": false,
    #     "findings": [{"code": "CBPR_MISSING_TOWN", "locator": "TwnNm", ...}]}


asyncio.run(main())

Tools

All tools return JSON-serialisable data; on a domain, validation, or value error they return an {"error": ...} payload rather than raising. Every tool is a pure, local, read-only, idempotent, closed-world lookup — no network, no sub-servers.

  • list_profiles — List the available clearing profiles as lightweight summaries (profile_id, market_practice, tier, entitled, supported_messages, rule_count). Use it to discover the profile_id values the other tools accept and see which ones the current caller is entitled to.

  • get_profile — Return one clearing profile in full, including its rule bodies. On a premium profile the caller must be entitled, otherwise it returns a BP_NOT_ENTITLED error (see Open-core vs premium).

  • lint_payload — Evaluate a raw ISO 20022 payload against a clearing profile and return the findings (a compliant payload yields none). Like get_profile, a premium profile requires an entitlement or it returns BP_NOT_ENTITLED.

  • validate_profile_definition — Validate a bank-supplied profile / rule-pack definition supplied as raw JSON, confirming its shape and that every rule uses a known assertion verb.

HTTP transport & authentication

stdio is the default and needs no authentication — one process per operator, launched by the client, no network surface. For shared, multi-tenant deployments the server also speaks an optional streamable-HTTP transport:

iso20022-bank-profile-mcp --transport=http --bind=127.0.0.1:8080

--bind defaults to 127.0.0.1:8080 (loopback-only), so exposing the server beyond the host is an explicit opt-in (e.g. --bind=0.0.0.0:8080). The HTTP transport refuses to start without authentication — it never serves an unauthenticated endpoint. Two auth modes apply, strongest first:

  • OAuth 2.1 resource server (RFC 9728) — set ISO20022_BANK_PROFILE_OAUTH_ISSUER and ISO20022_BANK_PROFILE_OAUTH_AUDIENCE (both required), with optional ISO20022_BANK_PROFILE_OAUTH_JWKS_URL (defaults to <issuer>/.well-known/jwks.json) and ISO20022_BANK_PROFILE_OAUTH_SCOPES. Every request must carry Authorization: Bearer <jwt>; the token is validated against the JWKS and its iss / aud / exp / nbf / required scopes. Failures are rejected 401 / 403 with an RFC 9728 WWW-Authenticate challenge, and protected-resource metadata is served at /.well-known/oauth-protected-resource. This server validates tokens from your existing authorization server (Okta, Auth0, Entra ID, …); running the authorization server is out of scope.

    ISO20022_BANK_PROFILE_OAUTH_ISSUER=https://auth.example.com \
    ISO20022_BANK_PROFILE_OAUTH_AUDIENCE=https://mcp.example.com/mcp \
      iso20022-bank-profile-mcp --transport=http --bind=0.0.0.0:8080
  • Static dev-mode token — set ISO20022_BANK_PROFILE_TOKEN to a shared secret; every request must then send Authorization: Bearer <secret>. This is a single shared secret with no expiry and no scopes — intended for local development, not production.

An optional X-MCP-Tenant request header is forwarded into the tool-visible request context for multi-tenant scoping. See docs/transport.md for the full setup.

How it fits the suite

This server is the profile authority for the ISO 20022 MCP Suite. The sibling iso20022-readiness-suite-mcp gateway scores and remediates payments against clearing profiles; those profiles are exactly what this server manages, validates, and serves. Aligning on one profile source keeps the readiness gateway and any bank's own tooling evaluating a payment against the same market-practice rules.

The profile catalogue is extensible at the seam the whole suite shares. The ProfileEngine loads the open baseline from bundled JSON with ProfileEngine.from_bundled(), and exposes ProfileEngine.register(profile) to add (or replace) a profile at runtime. A premium, bank-specific rule pack is the same shape as a bundled profile — a ClearingProfile with a profile_id, a market_practice, its supported_messages, and a list of custom_rules — so a deployment that embeds this server can register its licensed packs and serve them alongside the open baseline without changing the tool surface. See docs/profiles.md for the rule mini-language and the register() seam.

Open-core vs premium

The server is open core: the baseline scheme profiles and the profile engine are open source and always available. Higher-tier, institution-specific capabilities are commercial add-ons that plug into the same profile-engine seam (the engine already exposes a register() hook for runtime-loaded rule packs).

Capability

Tier

Profile engine + rule mini-language

Open Source

Baseline scheme profiles (Generic, CBPR+, SEPA_Instant, FedNow)

Open Source

Entitlement gate for premium profiles (tier, scopes, allowlist)

Open Source

Bank-specific / proprietary scheme rule packs

Paid

Stateful profile-version history & audit logs

Paid

Nothing in the open-source tier is time-limited or feature-gated.

How the entitlement gate works

Every clearing profile carries a tier: "open" (the baseline profiles — unrestricted and always accessible) or "premium" (a licensed rule pack). A bundled premium sample profile, ACME_Premium, ships so you can exercise the gate. list_profiles reports each profile's tier and a per-caller entitled boolean; get_profile and lint_payload on a premium profile return a BP_NOT_ENTITLED error unless the caller is entitled.

Entitlement is granted by either of two independent sources (ORed):

  • OAuth scope (HTTP transport) — a token bearing the profile:premium scope is entitled to every premium profile; a token bearing profile:<profile_id> is entitled to just that one.

  • Environment allowlist (stdio / dev) — ISO20022_BANK_PROFILE_ENTITLEMENTS lists the premium profile_id values (comma- or space-separated) the operator is licensed for; * grants all of them.

# stdio: license the ACME_Premium sample pack for this process
ISO20022_BANK_PROFILE_ENTITLEMENTS=ACME_Premium iso20022-bank-profile-mcp

The gate ships in this release; the premium rule packs themselves (and stateful version history / audit logs) remain a paid, out-of-tree concern. See docs/profiles.md for the full entitlement model.

When not to use iso20022-bank-profile-mcp

  • You have no MCP client. This server only makes sense paired with an MCP-aware host (Claude Desktop, the IDE plugins, an agent framework).

  • You need structural XSD validation or message generation. Those live in the foundational suite servers (iso20022-mcp, camt053-mcp, pain001-mcp). This server evaluates market-practice rules above the XSD; it does not parse, generate, or structurally validate messages.

  • You want an end-to-end readiness score and remediation. That is the job of iso20022-readiness-suite-mcp, which consumes these profiles. Use it if you want scoring, remediation, and bank-response simulation composed together.

  • You need a long-lived network service without auth. stdio is the default (one process per operator, no network surface); the optional HTTP transport exists for shared, multi-tenant deployments but always requires authentication (OAuth 2.1 or a static dev-mode token) — it will not serve an unauthenticated endpoint.

  • You need streaming responses. Tool calls return whole values, not streams.

Development

iso20022-bank-profile-mcp uses Poetry and mise.

git clone https://github.com/sebastienrousseau/iso20022-bank-profile-mcp.git && cd iso20022-bank-profile-mcp
mise install
poetry install
poetry shell

Note: the server is fully local and closed-world, so the test suite runs with nothing else installed. See CONTRIBUTING.md.

A Makefile orchestrates the quality gates (kept in lockstep with CI):

make check        # all gates (REQUIRED before commit): lint + type-check + test
make test         # pytest (100% line + branch coverage)
make lint         # ruff + black
make type-check   # mypy --strict
make security     # bandit

Security

iso20022-bank-profile-mcp returns errors as data — every tool catches the documented domain, validation, and value errors and returns an {"error": ...} envelope; it never propagates raw exceptions to the MCP client. Payloads reached through the clearing-profile engine are parsed with defusedxml only (no XXE / billion-laughs), and the server opens no network sockets. Reporting practice, supported versions, the attack surface, and the full supply-chain posture (SLSA L3 provenance, PEP 740 attestations, SBOMs, and the NIST SP 800-218 SSDF practice mapping) are documented in SECURITY.md. Vulnerabilities go via GitHub Private Vulnerability Reporting, not public issues.

Documentation


MCP Registry

mcp-name: io.github.sebastienrousseau/iso20022-bank-profile-mcp


License

Licensed under the Apache License, Version 2.0. Any contribution submitted for inclusion shall be licensed as above, without additional terms.

Contributing

Contributions are welcome — see the contributing instructions. Thanks to all contributors.

Acknowledgements

Built alongside the foundational servers of the ISO 20022 MCP Suite and the Model Context Protocol Python SDK.

Available Tools

4 tools
get_profileGet a clearing profileA
Read-onlyIdempotent

Return one clearing profile in full, including its rule bodies.

Args:
    profile_id: The clearing profile identifier.
ParametersJSON Schema
NameRequiredDescriptionDefault
profile_idYesThe profile to fetch (see list_profiles).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by specifying the return includes rule bodies, enhancing transparency beyond structured data.

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?

Two concise sentences with a front-loaded purpose and no wasted words. Structure is efficient and easy to parse.

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?

Given full schema coverage, output schema, and strong annotations, the description adequately explains what is returned. Missing error handling but sufficient for a read operation.

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 clear description of profile_id. The description adds minimal extra ('clearing profile identifier') over the schema, so baseline 3 is 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?

The description clearly states it returns one clearing profile in full including rule bodies, which distinguishes it from siblings like list_profiles (lists summaries) and validate_profile_definition (validates).

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

Usage Guidelines3/5

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

The description implies use when you need a full specific profile but does not explicitly state when to use it over siblings or provide exclusions.

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

lint_payloadLint a payload against a profileA
Read-onlyIdempotent

Evaluate a payload against a clearing profile and return findings.

Args:
    payload_content: The raw ISO 20022 message text.
    profile_id: The clearing profile to lint against.
ParametersJSON Schema
NameRequiredDescriptionDefault
profile_idYesThe clearing profile to lint against.
payload_contentYesRaw ISO 20022 payload text (not a path).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint true and destructiveHint false; the description adds that the tool 'return findings,' confirming it is a non-mutating validation operation.

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 short, front-loaded with the main purpose, and contains no extraneous information; every sentence serves a purpose.

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?

Given the low complexity (2 parameters, no nested objects) and the presence of an output schema, the description adequately covers what the tool does and its inputs, requiring no further elaboration.

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 descriptions for both parameters; the description repeats these without adding new meaning or format details, meeting the baseline.

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 uses a specific verb ('evaluate') and resources ('payload' and 'clearing profile'), and clearly distinguishes the tool from siblings (list_profiles, get_profile, validate_profile_definition) which serve different purposes.

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

Usage Guidelines3/5

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

The description implies usage for evaluating a payload against a profile, but does not explicitly state when to use this tool over siblings or provide exclusion criteria.

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

list_profilesList clearing profilesA
Read-onlyIdempotent

List the available clearing profiles as lightweight summaries.

Use this to discover the ``profile_id`` values the other tools accept.
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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, and destructiveHint, covering safety. The description adds that results are 'lightweight summaries,' providing more detail on the output nature beyond annotations. No further behavioral traits are needed given simplicity.

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?

Two sentences, no wasted words, front-loaded with the main action. Every sentence earns its place.

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?

Given no parameters, rich annotations, and an output schema, the description is fully sufficient. It explains the tool's purpose, output nature, and typical use case, leaving no gaps for a simple read-only list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description does not need to explain parameters, and it provides value by noting the output format. Schema coverage is 100%, so no deficit.

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 it lists clearing profiles as lightweight summaries, with a specific verb and resource. It also mentions the purpose of discovering profile_id values, distinguishing it from sibling tools like get_profile (single profile) and validate_profile_definition (validation).

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

Usage Guidelines4/5

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

The description explicitly advises using this tool to discover profile_id values for other tools, providing clear context. However, it does not specify when not to use it or mention alternatives, though the use case is well-defined.

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

validate_profile_definitionValidate a profile definitionA
Read-onlyIdempotent

Validate a bank-supplied profile / rule-pack definition (raw JSON).

Args:
    definition_content: The candidate profile definition, as JSON text.
ParametersJSON Schema
NameRequiredDescriptionDefault
definition_contentYesA profile / rule-pack definition as JSON text.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and no destructive actions. The description adds domain context ('bank-supplied profile') but beyond that adds little behavioral detail not already 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?

Extremely concise: two sentences plus an args list with no redundant information. Every part earns its place.

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?

Given the output schema exists and annotations thoroughly cover behavior, the description is nearly complete. It could hint at the validation outcome (errors/success) but is otherwise adequate.

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%, so the description adds minimal value. It rephrases the parameter description ('candidate profile definition' vs 'profile/rule-pack definition') but does not introduce new semantics.

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 validates a bank-supplied profile/rule-pack definition as raw JSON. It uses a specific verb-resource combination and distinguishes from sibling tools like list_profiles and lint_payload.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool over alternatives. It does not mention prerequisites, when to use vs lint_payload, or contextual triggers for validation.

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

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: listing profiles, retrieving full details, validating a profile definition, and linting a payload against a profile. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: list_profiles, get_profile, validate_profile_definition, lint_payload. Naming is predictable and clear.

Tool Count5/5

Four tools is well-scoped for the domain: discovery, retrieval, definition validation, and payload linting. Each tool earns its place without excess or deficiency.

Completeness4/5

The tool surface covers core workflows (discovery, retrieval, validation, linting). Missing explicit create/update/delete for profiles, but validation suggests profile definition submission. Minor gap but reasonable for a read-heavy MCP.

Maintenance

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    An MCP server that gives AI agents deterministic, verified access to ISO 8583 field specs, MTI decoding, jPOS packager XML generation, deploy descriptor validation, message building, and jPOS documentation search.
    7
    4
    MIT
  • F
    license
    A
    quality
    A
    maintenance
    MCP server that enables AI agents to parse, validate, and reverse ISO 20022 bank statements, with tools for discovering message types and return reasons.
    24
    1
  • F
    license
    A
    quality
    A
    maintenance
    An MCP server that exposes the pacs008 ISO 20022 FI-to-FI Customer Credit Transfer library as tools for AI agents and assistants, enabling generation, validation, and parsing of pacs.008 credit transfer XML messages.
    16
    1
  • F
    license
    A
    quality
    A
    maintenance
    Matches expected payments (pain.001) against observed booked entries (camt.053) for ISO 20022 cash reconciliation, providing explainable match results with scoring and classification.
    10
    1

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/iso20022-bank-profile-mcp'

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