fse-mcp

Validate a CDA2 document

validate_cda

Read-onlyIdempotent

Validate HL7 CDA R2 FSE 2.0 documents locally and return XSD or schematron issues with locations, helping diagnose rejection causes before submission.

Instructions

Checks an HL7 CDA R2 document for the FSE 2.0 gateway locally, without sending it anywhere, and returns XSD issues with their line and, when the XSD passes, schematron issues with their rule id and location. Documents with a DOCTYPE, entity declarations or XInclude are refused. Needs the optional @massimiliano-dev/fse-validator package and an it-fse-catalogs checkout; schematron also needs the optional saxon-js package (proprietary Saxonica licence) and a compiled schematron for the document type. The checks field says which levels ran. Use only synthetic or anonymised documents.

Input Schema

Name	Required	Description	Default
`xml`	Yes	The CDA2 document as an XML string, at most 2097152 bytes (UTF-8).

Output Schema

Name	Required	Description
`valid`	Yes	null when no validation level ran: validity is unknown.
`checks`	Yes	Which levels ran. A level that did not run reports no issues, which says nothing about it.
`detail`	No
`issues`	Yes
`notice`	Yes
`status`	Yes
`validator`	Yes
`schematron`	No
`rootElement`	No
`documentType`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.1.0Oct 29, 2026

addedOutput schema / properties / checks

Added value: +{
+  "additionalProperties": false,
+  "description": "Which levels ran. A level that did not run reports no issues, which says nothing about it.",
+  "properties": {
+    "schematron": {
+      "enum": [
+        "run",
+        "not_run_preflight_rejected",
+        "not_run_xsd_failed",
+        "skipped_validator_missing",
+        "skipped_catalogs_missing",
+        "skipped_saxon_missing",
+        "skipped_schematron_missing",
+        "skipped_unknown_document_type"
+      ],
+      "type": "string"
+    },
+    "xsd": {
+      "enum": [
+        "run",
+        "not_run_preflight_rejected",
+        "not_run_xsd_failed",
+        "skipped_validator_missing",
+        "skipped_catalogs_missing",
+        "skipped_saxon_missing",
+        "skipped_schematron_missing",
+        "skipped_unknown_document_type"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "xsd",
+    "schematron"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / detail
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / issues / items / properties / line

Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

removedOutput schema / properties / note

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / schematron
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / status / enum

Previous value: -[
-  "valid",
-  "invalid",
-  "rejected_preflight",
-  "not_implemented"
-]New value: +[
+  "valid",
+  "invalid",
+  "rejected_preflight",
+  "validator_unavailable"
+]

addedOutput schema / properties / valid

Added value: +{
+  "description": "null when no validation level ran: validity is unknown.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "status",
-  "validator",
-  "issues",
-  "note",
-  "notice"
-]New value: +[
+  "status",
+  "valid",
+  "validator",
+  "checks",
+  "issues",
+  "notice"
+]

First observedv0.0.0Oct 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Adds far more than the annotations' safe-read profile: local-only execution, refusal cases, required optional packages (@massimiliano-dev/fse-validator, saxon-js with proprietary licence), a catalogs checkout, and the dependency of schematron on a compiled ruleset for the document type. The 'checks' field disclosure tells the agent results can be partial, which is important context not available in structured fields.

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-loads what the tool does and where it runs, then layers refusals and prerequisites; every sentence carries operational weight. It is dense and somewhat run-on, but no sentence is 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?

An output schema exists, yet the description still clarifies the return shape (XSD first, schematron only when XSD passes) and the meaning of the checks field. Combined with prerequisites and refusal conditions, an agent has everything needed to call it correctly.

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?

Only one parameter, and the schema already documents 'xml' fully at 100% coverage including the 2097152-byte cap. The description adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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+resource ('Checks an HL7 CDA R2 document') with scope qualifiers ('for the FSE 2.0 gateway locally, without sending it anywhere') and names the exact output artifacts (XSD issues with line, schematron issues with rule id). Clearly distinct from siblings like explain_schematron_error, which acts on errors rather than validating a document.

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

Usage Guidelines4/5

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

Gives concrete eligibility rules (documents with DOCTYPE, entity declarations or XInclude are refused) and a data-handling constraint ('Use only synthetic or anonymised documents'), which effectively excludes production data. It does not name a sibling tool as an alternative, so it stops short of a 5.

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

Deploy Server