Skip to main content
Glama
sebastienrousseau

iso20022-bank-profile-mcp

Validate a profile definition

validate_profile_definition
Read-onlyIdempotent

Validate bank-supplied profile or rule-pack JSON against schema, syntax, and semantic rules before registering custom profiles or importing external packs.

Instructions

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

Purpose:
    Verify that a candidate clearing profile or rule-pack JSON text meets
    all schema, syntactic, and semantic requirements.

When to use:
    Use before registering new custom bank profiles or importing external
    rule packs into the engine.

When NOT to use:
    Do not use to validate payment messages; use `lint_payload` instead.

Behavioral transparency:
    - Deterministic: Evaluates strictly according to the Pydantic profile
      schema.
    - External dependencies: None (standard JSON parsing).
    - Side effects: Pure read-only validation; does not register the profile.
    - Error states: Returns `is_valid: False` with descriptive error details
      if validation fails.

Args:
    definition_content: The candidate profile definition, as JSON text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
definition_contentYesA profile / rule-pack definition as JSON text.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.2

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses determinism, absence of external dependencies, that it does not register the profile, and the error-state shape (`is_valid: False` with descriptive details). These are substantive behavioral traits that the annotations alone do not cover.

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 content is front-loaded and organized into purpose, usage, behavior, and args sections. Each section carries distinct information with no redundant filler.

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, the description does not need to explain return values in detail, and it still covers error semantics and side effects. It is complete for a validation tool of this complexity.

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 description coverage is 100%, so the single parameter is already fully documented by the input schema. The description's Args section repeats the same JSON-text semantics without adding format, encoding, or example details beyond the schema.

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 gives a specific verb ('Validate') and resource ('bank-supplied profile / rule-pack definition'), and it explicitly distinguishes that resource from payment messages by naming `lint_payload` as the sibling for the latter case. An agent can identify the tool's domain without opening the 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?

It provides explicit 'When to use' and 'When NOT to use' sections, including the condition for registration/import workflows and the alternative sibling `lint_payload` for payment messages. This leaves no ambiguity about selection.

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