Validates XML instance documents against XSD schemas, checks SDC4 schema compliance, and classifies validation errors into structural and semantic tiers.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sdcvalidator Validate my SDC4 XML instance against the schema and show errors."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SDC4 structural validator — a thin wrapper over xmlschema with two-tier error classification.
Validates XML instances against SDC4 XSD schemas
Classifies errors into structural (Tier 1: reject) vs semantic (Tier 2: report)
Checks SDC4 schema compliance (no xsd:extension — only xsd:restriction)
Strict validation by default — catches invalid restriction derivations (wrong element names, type mismatches) at schema load time
Converts between XML and JSON using schema-aware conversion
Related MCP server: Validator Ai MCP
pip install sdcvalidatorOr from source:
git clone https://github.com/SemanticDataCharter/sdcvalidator.git
cd sdcvalidator
pip install -e .from sdcvalidator import SDC4Validator, ErrorTier
# Validate an XML instance (strict mode by default)
validator = SDC4Validator("my_schema.xsd")
result = validator.validate("my_instance.xml")
if result.is_valid:
print("Valid!")
else:
for err in result.structural_errors:
print(f"STRUCTURAL: {err.reason}")
for err in result.semantic_errors:
print(f"SEMANTIC: {err.reason}")The validation parameter controls how strictly the XSD schema itself is checked when loaded:
'strict' (default) — Raises XMLSchemaParseError if the schema contains invalid restriction derivations (e.g., element names that don't match the base type). This is the recommended mode.
'lax' — Silently collects schema derivation errors without raising. Use only for pre-existing schemas known to have issues.
'skip' — Skips schema-level validation entirely.
# Explicit lax mode for legacy schemas
validator = SDC4Validator("legacy_schema.xsd", validation='lax')from sdcvalidator import validate_sdc4_schema_compliance, assert_sdc4_schema_compliance
# Check if a schema uses xsd:extension (not allowed in SDC4)
is_valid, errors = validate_sdc4_schema_compliance("schema.xsd")
# Or raise an exception
assert_sdc4_schema_compliance("schema.xsd")from sdcvalidator import ErrorClassifier, ErrorTier
classifier = ErrorClassifier()
tier = classifier.classify(some_xmlschema_error)
# ErrorTier.STRUCTURAL or ErrorTier.SEMANTICA semantic (Tier 2) error does not have to reject a record. Recovery keeps the value and inserts an ISO 21090 ExceptionalValue beside it (Invalid, for a value that fails its type, pattern, range or enumeration), so the record says which value is unusable and why, and the rest of it stays usable.
from sdcvalidator import SDC4Validator, SDC4UnrecoverableError
v = SDC4Validator("dm-xxxx.xsd", validation="lax")
result = v.recover("record.xml") # RecoveryResult; the source is never mutated
for r in result.recoveries: # Recovery: path, code ("INV"), name, reason, inserted
print(r.code, r.reason, r.path)
if not result.ok: # an error no ExceptionalValue covers
print(result.unrecoverable)
tree = v.validate_with_recovery("record.xml", save=False) # raises SDC4UnrecoverableError insteadAn ExceptionalValue the record already carries (a refusal, a masked field, written where the record was made) is
kept, and covers its value; recovery never inserts a second one. remove_existing_ev=True removes them first.
An error recovery cannot cover is returned in unrecoverable by recover(), and raised as
SDC4UnrecoverableError by validate_with_recovery(); it is never skipped.
Structural (Tier 1) errors raise SDC4StructuralValidationError.
Pass an XMLResource when the record carries prefixed QNames in content (xsi:type="sdc4:...").
from sdcvalidator.converters import xml_to_json, json_to_xml
# XML -> JSON (schema-aware)
data = xml_to_json("instance.xml", schema_path="schema.xsd")
# JSON -> XML
json_to_xml(data, "schema.xsd", "output.xml")sdcvalidate — Validate XML against schema# Basic validation
sdcvalidate schema.xsd instance.xml
# JSON output
sdcvalidate schema.xsd instance.xml --json
# Skip SDC4 compliance check
sdcvalidate --no-compliance-check schema.xsd instance.xmlExit codes: 0 valid, 1 semantic errors only, 2 structural errors.
sdcvalidator-xml2json — Convert XML to JSONsdcvalidator-xml2json instance.xml --schema schema.xsd
sdcvalidator-xml2json instance.xml -o output.jsonsdcvalidator-json2xml — Convert JSON to XMLsdcvalidator-json2xml data.json schema.xsd -o output.xmlsdcvalidator ships a stdio MCP (Model Context Protocol) server so any MCP-capable agent can validate SDC4 data without importing the Python library. It implements JSON-RPC 2.0 directly over stdio — no external MCP SDK dependency.
sdcvalidator # what an MCP registry client runs (uvx sdcvalidator)
sdcvalidator mcp # the same, spelled like the other Semantic Data Charter servers
sdcvalidator-mcp serve --mcp # still works for existing client configurationsA client configuration needs only "command": "uvx", "args": ["sdcvalidator"].
Tool | Purpose |
| Validate an XML instance against its SDC4 XSD schema. Returns pass/fail with error count and classified errors. |
| Validate an instance and return a detailed report with two-tier (structural vs semantic) error classification. |
| Check whether an XSD schema follows SDC4 principles (restriction only, no |
validate_instance and validate_and_report take schema_path and instance_path, plus an optional check_compliance boolean (default true). check_schema_compliance takes schema_path only.
Tier | Type | Examples | Action |
1 | Structural | Unknown elements, cardinality violations, wrong nesting | Reject |
2 | Semantic | Type errors, pattern violations, enumeration mismatches | Report, or recover with an ExceptionalValue |
SDC4 data models must use xsd:restriction only — never xsd:extension. This enforces separation of structure (reference model) and semantics (data models), guaranteeing global interoperability.
The validator checks this by default and rejects schemas that violate this principle.
Production-ready. Available on PyPI under Apache 2.0.
Apache License 2.0 — see LICENSE.
Check if an XSD schema follows SDC4 principles (no xsd:extension, restriction only). Does not validate instances.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_path | Yes | Path to the XSD schema file to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It discloses the compliance rules ('no xsd:extension, restriction only') and the scope limit, but does not describe the result format, read-only behavior, or expected failure modes.
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?
Two short sentences, front-loaded with purpose, and the exclusion is included without waste. Every sentence contributes useful information.
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?
For a simple one-parameter checker, the description adequately conveys what is checked and what is not. The main remaining gap is that no output schema exists and the description does not explain what the check returns.
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 single parameter has 100% schema description coverage, so the schema already explains schema_path. The description adds no further parameter meaning, which is acceptable given the schema coverage baseline.
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 states a specific verb and resource ('Check if an XSD schema follows SDC4 principles') and immediately distinguishes it from instance validation with 'Does not validate instances.' This makes the tool's scope clear relative to validate_instance.
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 explicitly excludes instance validation, which implicitly points an agent to validate_instance for that case. However, it does not mention validate_and_report or give more complete when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an XML instance and return a detailed report with two-tier error classification (structural vs semantic).
| Name | Required | Description | Default |
|---|---|---|---|
| schema_path | Yes | Path to the SDC4 data model XSD file. | |
| instance_path | Yes | Path to the XML instance file to validate. | |
| check_compliance | No | Check schema follows SDC4 principles. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one behavioral trait beyond the name: the report uses two-tier classification (structural vs semantic). It does not say whether failures raise errors or are reported in the payload, whether the tool is read-only, or what permissions/inputs are required.
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?
A single efficient sentence with the resource and the return value front-loaded. It is arguably too terse for a tool with two competing siblings, but nothing in it is wasted.
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 schema is simple and fully documented, and there is no output schema, so the description needn't explain return values. However, for a tool sitting beside validate_instance and check_schema_compliance, the definition omits the comparison that an agent most needs to choose correctly.
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?
Schema coverage is 100%, so all three parameters are already fully documented in the schema. The description adds no parameter-level detail (for example, what check_compliance=false actually changes in the output), so baseline 3 applies.
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?
States a specific verb (validate) and resource (XML instance) plus the report it returns. It does not differentiate itself from the sibling validate_instance, which sounds functionally identical, so an agent cannot tell them apart from the description alone.
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?
There is no indication of when to use this versus validate_instance or check_schema_compliance, nor any prerequisites. The description gives no routing signal at all despite two overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an XML instance against its SDC4 XSD schema. Returns pass/fail with error count and classified errors.
| Name | Required | Description | Default |
|---|---|---|---|
| schema_path | Yes | Path to the SDC4 data model XSD file. | |
| instance_path | Yes | Path to the XML instance file to validate. | |
| check_compliance | No | Check schema follows SDC4 principles (no xsd:extension). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden; it usefully discloses the return shape (pass/fail, error count, classified errors). It does not say whether the check is read-only, what happens if check_compliance fails, or whether any files are written, leaving meaningful behavioral gaps.
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?
Two tight sentences with the core action front-loaded and the output summarised second. No filler, though it is brief enough to leave gaps.
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?
It covers the action and the return value, which is good given there is no output schema. However, with no annotations and two sibling tools doing similar-sounding things, the definition lacks the routing and safety context an agent needs.
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?
Schema description coverage is 100% and each parameter (schema_path, instance_path, check_compliance) is documented there. The description adds nothing about parameter meaning or format, so the baseline 3 applies.
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?
States a specific verb and resource ('Validate an XML instance against its SDC4 XSD schema') and adds a return summary. Clear on its own, but it does not distinguish itself from the siblings validate_and_report and check_schema_compliance, which sound closely related.
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?
No indication of when to pick this over validate_and_report or check_schema_compliance, and no prerequisites or exclusions. The agent must infer the difference from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v4.6.1check_schema_compliancevalidate_and_reportvalidate_instanceScored across 3 tools
validate_instance and validate_and_report both validate XML instances and differ mainly in output detail, creating likely selection ambiguity. check_schema_compliance is clearly distinct, and the descriptions partially clarify the overlap, but the boundary between the two validators is not crisp.
All names use snake_case and are reasonably predictable. The pattern is mostly action-oriented, though check_schema_compliance is a bit longer and less parallel with the validate_* tools.
Three tools is appropriate for a focused SDC validator, but validate_instance and validate_and_report could likely be consolidated or differentiated more clearly. The count is not excessive, though the overlap suggests slight over-partitioning.
The surface covers instance validation, detailed reporting, and schema-principle checking, which are the core operations for this domain. Minor gaps may exist around explicit schema validity checking or reporting options, but no major workflow appears missing.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Physics-based validation of simulation results: receipts with per-check verdicts, via MCP.
MCP compatibility and transport verification server.
MCP compatibility and transport verification server.