Skip to main content
Glama

Validate XML string against XSD

validate_xml_against_schema
Read-onlyIdempotent

Check a pain.001 or pain.008 XML string against the official ISO 20022 XSD schema. Submitting the XML returns a validity flag and, if invalid, the schema error.

Instructions

Validate a raw pain.001 / pain.008 XML string against its official XSD.

Use this to check XML you already have as a string (e.g. received from
another system) without touching the filesystem. To validate records
*before* they become XML, use ``validate_records``; to parse a statement
or status-report file, use ``parse_camt053`` / ``parse_pain002``.

Wraps :func:`pain001.xml.validate_via_xsd.validate_xml_string_via_xsd`.

Args:
    xml_content: The XML document as a string.
    message_type: A supported ISO 20022 pain message type.

Returns:
    ``{"valid": bool, "message_type": str, "error": str?}`` -
    ``error`` is present only when ``valid`` is ``False``.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xml_contentYesThe full pain.001 / pain.008 XML document as a string, validated against the message type's official XSD.
message_typeYesA supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.001.001.13', 'pain.008.001.02', 'pain.008.001.08', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
validNo
message_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.71
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Verdict of an XML document against the official XSD.",
      +  "properties": {
      +    "error": {
      +      "title": "Error",
      +      "type": "string"
      +    },
      +    "message_type": {
      +      "title": "Message Type",
      +      "type": "string"
      +    },
      +    "valid": {
      +      "title": "Valid",
      +      "type": "boolean"
      +    }
      +  },
      +  "title": "XsdResult",
      +  "type": "object"
      +}
  2. Changed2 schema fields changedv0.0.67
    • changedInput schema / properties / message_type / description
      Previous value: -"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.001.001.13', 'pain.008.001.02', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'."New value: +"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.001.001.13', 'pain.008.001.02', 'pain.008.001.08', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'."
    • changedInput schema / properties / message_type / enum
      Previous value: -[
      -  "pain.001.001.03",
      -  "pain.001.001.04",
      -  "pain.001.001.05",
      -  "pain.001.001.06",
      -  "pain.001.001.07",
      -  "pain.001.001.08",
      -  "pain.001.001.09",
      -  "pain.001.001.10",
      -  "pain.001.001.11",
      -  "pain.001.001.12",
      -  "pain.001.001.13",
      -  "pain.008.001.02",
      -  "pain.001",
      -  "pain.008"
      -]New value: +[
      +  "pain.001.001.03",
      +  "pain.001.001.04",
      +  "pain.001.001.05",
      +  "pain.001.001.06",
      +  "pain.001.001.07",
      +  "pain.001.001.08",
      +  "pain.001.001.09",
      +  "pain.001.001.10",
      +  "pain.001.001.11",
      +  "pain.001.001.12",
      +  "pain.001.001.13",
      +  "pain.008.001.02",
      +  "pain.008.001.08",
      +  "pain.001",
      +  "pain.008"
      +]
  3. Changed2 schema fields changed
    • changedInput schema / properties / message_type / description
      Previous value: -"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.008.001.02', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'."New value: +"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.001.001.13', 'pain.008.001.02', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'."
    • changedInput schema / properties / message_type / enum
      Previous value: -[
      -  "pain.001.001.03",
      -  "pain.001.001.04",
      -  "pain.001.001.05",
      -  "pain.001.001.06",
      -  "pain.001.001.07",
      -  "pain.001.001.08",
      -  "pain.001.001.09",
      -  "pain.001.001.10",
      -  "pain.001.001.11",
      -  "pain.001.001.12",
      -  "pain.008.001.02",
      -  "pain.001",
      -  "pain.008"
      -]New value: +[
      +  "pain.001.001.03",
      +  "pain.001.001.04",
      +  "pain.001.001.05",
      +  "pain.001.001.06",
      +  "pain.001.001.07",
      +  "pain.001.001.08",
      +  "pain.001.001.09",
      +  "pain.001.001.10",
      +  "pain.001.001.11",
      +  "pain.001.001.12",
      +  "pain.001.001.13",
      +  "pain.008.001.02",
      +  "pain.001",
      +  "pain.008"
      +]
  4. Addedv0.0.60
  5. Removed
  6. Changed2 schema fields changed
    • changedInput schema / properties / message_type / description
      Previous value: -"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.008.001.02' (see list_message_types)."New value: +"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.008.001.02', 'pain.001', 'pain.008' (see list_message_types). The bare family names 'pain.001' and 'pain.008' are accepted as aliases for 'pain.001.001.09' and 'pain.008.001.02'."
    • changedInput schema / properties / message_type / enum
      Previous value: -[
      -  "pain.001.001.03",
      -  "pain.001.001.04",
      -  "pain.001.001.05",
      -  "pain.001.001.06",
      -  "pain.001.001.07",
      -  "pain.001.001.08",
      -  "pain.001.001.09",
      -  "pain.001.001.10",
      -  "pain.001.001.11",
      -  "pain.001.001.12",
      -  "pain.008.001.02"
      -]New value: +[
      +  "pain.001.001.03",
      +  "pain.001.001.04",
      +  "pain.001.001.05",
      +  "pain.001.001.06",
      +  "pain.001.001.07",
      +  "pain.001.001.08",
      +  "pain.001.001.09",
      +  "pain.001.001.10",
      +  "pain.001.001.11",
      +  "pain.001.001.12",
      +  "pain.008.001.02",
      +  "pain.001",
      +  "pain.008"
      +]
  7. Changed2 schema fields changedv0.0.57
    • changedInput schema / properties / message_type / description
      Previous value: -"The ISO 20022 pain message type whose XSD to validate against, e.g. 'pain.001.001.09' — see list_message_types."New value: +"A supported ISO 20022 pain message type. Must be exactly one of: 'pain.001.001.03', 'pain.001.001.04', 'pain.001.001.05', 'pain.001.001.06', 'pain.001.001.07', 'pain.001.001.08', 'pain.001.001.09', 'pain.001.001.10', 'pain.001.001.11', 'pain.001.001.12', 'pain.008.001.02' (see list_message_types)."
    • addedInput schema / properties / message_type / enum
      Added value: +[
      +  "pain.001.001.03",
      +  "pain.001.001.04",
      +  "pain.001.001.05",
      +  "pain.001.001.06",
      +  "pain.001.001.07",
      +  "pain.001.001.08",
      +  "pain.001.001.09",
      +  "pain.001.001.10",
      +  "pain.001.001.11",
      +  "pain.001.001.12",
      +  "pain.008.001.02"
      +]
  8. Changed2 schema fields changedv0.0.56
    • addedInput schema / properties / message_type / description
      Added value: +"The ISO 20022 pain message type whose XSD to validate against, e.g. 'pain.001.001.09' — see list_message_types."
    • addedInput schema / properties / xml_content / description
      Added value: +"The full pain.001 / pain.008 XML document as a string, validated against the message type's official XSD."
  9. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveness. The description adds useful behavioral context beyond annotations: it operates on an in-memory string without filesystem access, wraps a specific validation function, and specifies that the returned error field exists only when valid is false. No contradiction with annotations.

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?

The description is well-structured and front-loaded with the primary use case and alternative tools. The Args/Returns block is useful, though it partially duplicates the fully specified input schema, and the internal module path adds little for an agent. Still, every section serves a purpose and there is no 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?

For a two-parameter validation tool, the description covers when to use it, what it does, what its output shape is, and how it differs from the most relevant siblings. The schema covers the remaining enum details and aliases, and the annotations cover safety and idempotency, so nothing an agent needs 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%, and the schema itself fully documents xml_content and message_type, including the enum values and alias behavior. The description adds only a terse restatement of the two parameters, so it does not meaningfully exceed what the schema already provides. 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 (validate), a precise resource (raw pain.001/pain.008 XML string), and the referenced XSD. It also distinguishes itself from related siblings by naming validate_records, parse_camt053, and parse_pain002.

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?

Explicitly says when to use this tool: when the XML is already a string and you need to check it without touching the filesystem. It also gives clear alternatives and conditions: use validate_records before XML exists, and use parse_camt053/parse_pain002 for parsing statement or status-report files.

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