iso20022-bank-profile-mcp
This server manages, validates, and serves ISO 20022 bank clearing profiles—market-practice rules that go beyond structural XSD validation. It provides four read-only, idempotent, closed-world tools for AI agents:
list_profiles— Get lightweight summaries of all available clearing profiles, including profile ID, market practice, tier (open/premium), entitlement status, supported messages, and rule count.get_profile— Retrieve a complete clearing profile with all rule bodies by profile ID. Premium profiles require entitlement.lint_payload— Evaluate an ISO 20022 message payload against a chosen profile and return compliance findings. Non‑compliant messages return structured findings with codes and locators.validate_profile_definition— Validate a bank‑supplied or custom profile definition provided as JSON, ensuring correct structure and known rule verbs.
Key characteristics:
All tools return JSON and report errors as
{"error": ...}rather than exceptions.Premium profiles are gated via an entitlement system (OAuth scope or allowlist).
XML parsing is secured with
defusedxmlto prevent XXE/billion‑laughs attacks.Ships with four open baseline profiles:
Generic,CBPR+,SEPA_Instant, andFedNow.Can be extended with bank‑specific premium rule packs.
Provides clearing profiles, validation, and linting for SEPA (Single Euro Payments Area) payments, including SEPA Instant credit transfers.
Click on "Install 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., "@iso20022-bank-profile-mcpLint this pacs.008 against the CBPR+ profile"
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.
iso20022-bank-profile-mcp: The ISO 20022 Bank Clearing-Profile Server
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-mcpturns those scheme rules into versioned, agent-callable clearing profiles:list_profilesandget_profileserve them,lint_payloadevaluates a payload against one, andvalidate_profile_definitionvets 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).
Website: https://sebastienrousseau.github.io/iso20022-bank-profile-mcp/
Source code: https://github.com/sebastienrousseau/iso20022-bank-profile-mcp
Bug reports: https://github.com/sebastienrousseau/iso20022-bank-profile-mcp/issues
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.-> BThe 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 |
Orchestration gateway: readiness scoring, remediation, clearing-profile linting, and bank-response simulation over the foundational servers |
| |
Compiles readiness findings, remediation diffs and simulated responses into a sealed, Ed25519-signable audit evidence pack |
| |
ISO 20022 postal-address classification, assessment, and remediation for the Nov 2026 structured-address cliff |
| |
Unified gateway meta-tools ( |
| |
ISO 20022 camt.05x bank statements: parse, validate, filter, reverse; MT94x migration; CBPR+ readiness |
| |
Generate & validate ISO 20022 pain.001 payment-initiation files (v03–v12, pain.008, SEPA) with rulebook checks |
| |
Reconcile ISO 20022 payments and statements; match initiations to their bank-side outcomes |
| |
Parse bank statements (MT940/MT942 and camt) into structured, agent-friendly data |
|
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-mcpOr run it without installing, straight from PyPI, with
uvx:
uvx iso20022-bank-profile-mcppython -m venv venv
source venv/bin/activate # macOS/Linux
venv\Scripts\activate # Windows
python -m pip install -U iso20022-bank-profile-mcpQuick 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-mcpRegister 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 theprofile_idvalues 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 aBP_NOT_ENTITLEDerror (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). Likeget_profile, a premium profile requires an entitlement or it returnsBP_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_ISSUERandISO20022_BANK_PROFILE_OAUTH_AUDIENCE(both required), with optionalISO20022_BANK_PROFILE_OAUTH_JWKS_URL(defaults to<issuer>/.well-known/jwks.json) andISO20022_BANK_PROFILE_OAUTH_SCOPES. Every request must carryAuthorization: Bearer <jwt>; the token is validated against the JWKS and itsiss/aud/exp/nbf/ required scopes. Failures are rejected401/403with an RFC 9728WWW-Authenticatechallenge, 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:8080Static dev-mode token — set
ISO20022_BANK_PROFILE_TOKENto a shared secret; every request must then sendAuthorization: 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:premiumscope is entitled to every premium profile; a token bearingprofile:<profile_id>is entitled to just that one.Environment allowlist (stdio / dev) —
ISO20022_BANK_PROFILE_ENTITLEMENTSlists the premiumprofile_idvalues (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-mcpThe 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 shellNote: 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 # banditSecurity
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
README.md— this fileCHANGELOG.md— release notesSECURITY.md— disclosure + supported versionsSUPPORT.md— how to get helpROADMAP.md— what's shipped (HTTP transport, premium entitlement gating) and what's next (richer bank rule packs)MAINTAINERS.md— who can mergedocs/quickstart.md— 10-minute install → first conversationdocs/profiles.md— the clearing profiles, the rule mini-language, premium rule packs, and the entitlement gatedocs/transport.md— the optional HTTP transport and OAuth 2.1 setupglama.json— Glama directory manifest
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 toolsget_profileGet a clearing profileARead-onlyIdempotent
Return one clearing profile in full, including its rule bodies.
Args:
profile_id: The clearing profile identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The profile to fetch (see list_profiles). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 profileARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The clearing profile to lint against. | |
| payload_content | Yes | Raw ISO 20022 payload text (not a path). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 profilesARead-onlyIdempotent
List the available clearing profiles as lightweight summaries.
Use this to discover the ``profile_id`` values the other tools accept.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 definitionARead-onlyIdempotent
Validate a bank-supplied profile / rule-pack definition (raw JSON).
Args:
definition_content: The candidate profile definition, as JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| definition_content | Yes | A profile / rule-pack definition as JSON text. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
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.
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.
Four tools is well-scoped for the domain: discovery, retrieval, definition validation, and payload linting. Each tool earns its place without excess or deficiency.
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
Related MCP Connectors
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseAqualityCmaintenanceAn 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.74MIT
- FlicenseAqualityAmaintenanceMCP server that enables AI agents to parse, validate, and reverse ISO 20022 bank statements, with tools for discovering message types and return reasons.241
- FlicenseAqualityAmaintenanceAn 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.161
- FlicenseAqualityAmaintenanceMatches expected payments (pain.001) against observed booked entries (camt.053) for ISO 20022 cash reconciliation, providing explainable match results with scoring and classification.101
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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