Validate an ISO 20022 XML message (pacs.008, camt.053, pain.001, etc.) for schema compliance, required fields, and Nov 2026 structured address deadline. Provide 'xml' for full validation or 'message_type' for schema info.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | No | Raw ISO 20022 XML message to validate | |
| message_type | No | Message type for schema info (e.g. pacs.008, camt.053, pain.001) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a simple 'validate' by specifying what validation covers (schema compliance, required fields, Nov 2026 deadline) and describes two distinct behaviors depending on which parameter is provided. It does not mention side effects or return format, but it is a read-only validation tool.
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 two sentences, starts with the primary action and resource, and is front-loaded with the core purpose. It provides valuable detail without fluff, and every sentence contributes to understanding the tool.
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?
The description covers the main functionality and parameters, which is adequate for a simple validation tool. However, there is no output schema, and the description does not explain what the tool returns (e.g., pass/fail, error list, schema details). This is a clear gap, as the user would not know what to expect from the output.
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?
The input schema already describes both parameters, so baseline is 3. The description adds the relationship between the parameters: 'xml' is for full validation and 'message_type' is for schema info, clarifying that they serve different purposes. This adds operational meaning beyond the schema.
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 ISO 20022 XML messages with specific validation criteria (schema compliance, required fields, deadline). It lists common message types and distinguishes it from sibling tools like generate_pacs008 or message_convert_check by focusing on 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 gives clear usage context: use when you need to validate an ISO 20022 XML message. It also explains the two parameter modes ('xml' for full validation, 'message_type' for schema info), which is helpful. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct concern: address validation, DTI lookup, message generation, health monitoring, cataloging, conversion, MiCA decisions, sanctions screening, stablecoin profiles, deadlines, travel rule, and validation. Even similar tools like dti_lookup and stablecoin_iso_profile are clearly separated by scope (code lookup vs. full integration profile), with no overlapping purposes.
All names use lowercase snake_case and are descriptive, but the pattern is not uniformly verb_noun. Most start with a verb (check_, generate_, validate_, lookup, screen), while a few are noun phrases (message_catalog, stablecoin_iso_profile, swift_deadlines, health_check). This minor inconsistency prevents a perfect 5 but remains predictable and readable.
12 tools is well within the ideal 3-15 range for a domain-specific server. Each tool serves a distinct function without unnecessary duplication or bloat, covering generation, validation, compliance, and informational lookups.
The tool surface provides comprehensive coverage of the ISO 20022 stablecoin/payment domain: message generation, validation, cataloging, deadline tracking, MT/MX conversion, and multiple compliance checks (sanctions, travel rule, MiCA, structured address). No critical gaps are apparent; the set handles end-to-end workflows from generation to compliance validation.