iso20022-bank-profile-mcp

Lint a payload against a profile

lint_payload

Read-onlyIdempotent

Validate ISO 20022 payment payloads against specific bank clearing profile rules to identify violations, missing elements, or format defects before clearing submission.

Instructions

Evaluate a payload against a clearing profile and return findings.

Purpose:
    Validate an ISO 20022 XML or JSON message payload against the
    market-practice rules and constraints of a specific bank clearing profile.

When to use:
    Use before submitting payment messages to clearing rails (CBPR+, SEPA,
    FedNow) to identify rule violations, missing elements, or format defects.

When NOT to use:
    Do not use for basic XSD schema validation; use structural XML
    validators. Do not use to validate rule pack schemas; use
    `validate_profile_definition`.

Behavioral transparency:
    - Deterministic: Identical payload and profile_id produce identical
      findings.
    - External dependencies: None (defusedxml parser only).
    - Side effects: Pure read-only operation; writes no data.
    - Error states: Returns an error object on XML syntax error,
      unknown profile_id, or entitlement failure.

Args:
    payload_content: The raw ISO 20022 message text.
    profile_id: The clearing profile to lint against.

Input Schema

TableJSON Schema

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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.2Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description goes further: determinism, no external dependencies (defusedxml), explicit purity statement, and three named error states (XML syntax error, unknown profile_id, entitlement failure). That error-state disclosure is genuinely beyond what the 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line summary, then labeled sections that make scanning easy. The Args block duplicates the schema and the section headers add slight length, but every section carries non-redundant content, so it 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?

With an output schema present, return values need not be described, and the description covers everything else an agent needs: scope, timing, exclusions, determinism, dependencies, and error states. Nothing required to invoke it correctly is missing.

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 both parameters are already documented in the schema, including the 'not a path' clarifier for payload_content. The description's Args section largely restates the schema, adding only 'raw ISO 20022 message text' which the schema already conveys. 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?

States a specific verb (lint/evaluate) and resource (ISO 20022 payload against a clearing profile), and explicitly names two sibling alternatives (structural XML validators, validate_profile_definition) that it is not. An agent can distinguish it from list_profiles, get_profile, and validate_profile_definition without opening any schema.

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

Usage Guidelines5/5

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

Explicit 'When to use' names concrete upstream scenarios (before submitting to CBPR+, SEPA, FedNow) and 'When NOT to use' names the alternative tools for adjacent tasks. This is textbook when/when-not/alternative guidance.

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

Deploy Server