iso20022-bank-profile-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ISO20022_BANK_PROFILE_TOKEN | No | Static dev-mode token for HTTP transport (alternative to OAuth) | |
| ISO20022_BANK_PROFILE_ENTITLEMENTS | No | Comma- or space-separated list of premium profile IDs the operator is licensed for, or '*' for all | |
| ISO20022_BANK_PROFILE_OAUTH_ISSUER | No | OAuth 2.1 issuer URL for token validation (required when using OAuth with HTTP transport) | |
| ISO20022_BANK_PROFILE_OAUTH_SCOPES | No | Required OAuth scopes (optional) | |
| ISO20022_BANK_PROFILE_OAUTH_AUDIENCE | No | OAuth 2.1 audience for token validation (required when using OAuth with HTTP transport) | |
| ISO20022_BANK_PROFILE_OAUTH_JWKS_URL | No | JWKS URL for token validation (defaults to <issuer>/.well-known/jwks.json) | <issuer>/.well-known/jwks.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_profilesA | List the available clearing profiles as lightweight summaries. |
| get_profileA | Return one clearing profile in full, including its rule bodies. |
| lint_payloadA | Evaluate a payload against a clearing profile and return findings. |
| validate_profile_definitionA | Validate a bank-supplied profile / rule-pack definition (raw JSON). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| lint_bank_payload | Guide an agent through linting a payload against a clearing profile. Teaches the canonical three-step workflow: discover the available profiles with ``list_profiles``, inspect the chosen one with ``get_profile``, then evaluate a payload with ``lint_payload``. Args: profile_id: The clearing profile the guidance should target. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| profiles_resource | Expose the clearing-profile summaries as a static JSON resource. Mirrors the ``list_profiles`` tool for clients that prefer to read context as a resource rather than invoke a tool. |
TDQS
Scored across 4 tools
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.