What can you do with this server?

This MCP server helps diagnose why the FSE 2.0 gateway rejects CDA2 documents by validating locally, explaining errors, looking up codes, and generating synthetic samples. * Validate a CDA2 XML document locally with pre-flight safety checks, XSD validation, and schematron validation where available, reporting status, which checks ran, and issues. * Explain FSE gateway XSD or schematron errors/rule IDs in plain language with suggested fixes, using a limited sample of rules. * Look up or search FSE terminology codes in LOINC, ICD9-CM, ATC, AIC, and AdministrativeGender, returning the code system OID for @codeSystem, from sample dictionaries. * Generate synthetic CDA2 skeletons for laboratory report, discharge letter, radiology report, and ER report; the lab report skeleton passes XSD and schematron. * Run over stdio by default or token-protected loopback HTTP, with read-only, idempotent tools and no outbound network calls. * Caveat: it does not perform national terminology dictionary checks, so local validation does not guarantee gateway acceptance.

How do I use fse-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fse-mcp The gateway rejected my lab report with ERRORE-28. What does it want?" 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.

fse-mcp

by massimiliano-dev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

fse-mcp

An MCP server that helps developers find out why the FSE 2.0 gateway rejects a CDA2 document.

License: MIT

Unofficial. Not affiliated with, endorsed by or connected to the Italian Ministry of Health, Sogei, AgID, the regions or any FSE operator. FSE rules change: the official specifications and it-fse-catalogs are the reference.

Passing XSD and schematron locally does not guarantee that the gateway accepts a document: the gateway also checks codes against the national terminology dictionaries, and this server does not.

Integrating with the Fascicolo Sanitario Elettronico 2.0 gateway means sending HL7 CDA R2 documents that are checked against XSD schemas, a schematron per document type and the national dictionaries. When a document is refused, the response is an Italian rule message such as ERRORE-4| Almeno un elemento 'templateId' DEVE ... and the fix is buried in an implementation guide. This server puts that knowledge next to your MCP client (Claude Desktop, Claude Code, an IDE) so you can ask "why was this rejected and what do I change?".

It is not another generic open-data wrapper: it does not proxy any public API and makes no network calls. It targets one pain point, rejected documents, and runs entirely on your machine.

Status: early (0.x). See what is real today before relying on it.

Tools

Tool	What it does	Example prompt
`validate_cda`	Checks a CDA2 document locally (max 2 MiB): refuses DTDs, entities and XInclude, then validates against the CDA XSD and, when the XSD passes, the schematron of the document type, in the gateway's order. The `checks` field says which levels ran. See validation setup.	"Validate this synthetic lab report and tell me what the gateway will reject."
`explain_schematron_error`	Explains a gateway XSD/schematron error in plain language, with the official message and a fix.	"The gateway answered `ERRORE-28` for my referto di laboratorio. What does it want?"
`lookup_code`	Looks up a code or searches display names in LOINC, ICD9-CM, ATC, AIC and HL7 AdministrativeGender, returning the `@codeSystem` OID.	"What is the LOINC code and code system OID for a laboratory report?"
`generate_sample_cda`	Returns a synthetic CDA2 skeleton (lab report, discharge letter, radiology report, ER report) with fictional patient and doctor data. The lab report skeleton passes XSD and schematron.	"Give me a synthetic referto di laboratorio skeleton I can use as a test fixture."

All tools are annotated read-only, idempotent and closed-world, have JSON input and output schemas, and size-limit every input.

Status

Part	State
Transports (stdio, Streamable HTTP)	Real, with token auth and DNS rebinding protection.
Pre-flight XML guard	Real: refuses DOCTYPE, ENTITY, XInclude; checks the `ClinicalDocument` root and HL7 v3 namespace; ignores stylesheets and schemaLocation.
`validate_cda` XSD	Real: CDA XSD from it-fse-catalogs at the pinned commit, with libxml2 compiled to WebAssembly (`@massimiliano-dev/fse-validator`, optional). Without the package or the catalogs the result is `validator_unavailable`.
`validate_cda` schematron	Real, but only where it can run: needs the optional `saxon-js` and a compiled schematron for the document type. Compiled today: referto di laboratorio only (`schematronFSE_LAB_v27.1`). Elsewhere `checks.schematron` says why it was skipped.
Terminology checks	Not done. The gateway checks codes against the national dictionaries; this server does not.
`explain_schematron_error` rules	Examples: five hand-written entries (laboratory report schematron v27.1 plus one XSD error).
`lookup_code` dictionaries	Sample: a few dozen codes copied from it-fse-catalogs. A missing code does not mean it is invalid.
`generate_sample_cda`	Referto di laboratorio: passes XSD and `schematronFSE_LAB_v27.1` as generated (asserted by the tests). Other types: national templateId roots and LOINC codes verified, the documents themselves unverified (no compiled schematron). `templateId/@extension` values still to verify.
Agensi skill	A packaged triage workflow with reference tables generated from it-fse-catalogs; not part of the npm package.

Related MCP server: HL7-Bridge MCP

Install

Requires Node.js 22.19 or later. Without the optional packages below, validate_cda only runs the pre-flight checks and says so: see validation setup.

Claude Code

claude mcp add fse -- npx -y @massimiliano-dev/fse-mcp

or commit a project-scoped .mcp.json like examples/claude-code.mcp.json:

{
  "mcpServers": {
    "fse": { "type": "stdio", "command": "npx", "args": ["-y", "@massimiliano-dev/fse-mcp"] }
  }
}

Claude Desktop

Add to claude_desktop_config.json (see examples/claude-desktop.json):

{
  "mcpServers": {
    "fse": { "command": "npx", "args": ["-y", "@massimiliano-dev/fse-mcp"] }
  }
}

Pin a version (@massimiliano-dev/fse-mcp@0.1.0) if you want upgrades to be deliberate.

Validation setup

validate_cda validates offline against local copies of the official rules. Each piece is optional; whatever is missing is reported in the result (status: "validator_unavailable", or a checks level other than run) instead of failing.

Piece	What it enables	How
`@massimiliano-dev/fse-validator`	XSD (and the schematron engine wrapper)	Optional peer dependency, `^0.1.0`: `npm i @massimiliano-dev/fse-validator`. It ships the official catalogs, so nothing else is needed for XSD.
it-fse-catalogs files	XSD	Bundled in the validator package at the pinned commit (`d8c766a…`; another commit is refused). Override with `FSE_MCP_CATALOGS_DIR` to use your own checkout.
Compiled schematrons	Schematron	Bundled in the validator package; only `schematronFSE_LAB_v27.1` is compiled today. Override the folder with `FSE_MCP_SCHEMATRON_DIR`.
`saxon-js`	Schematron	Optional peer dependency, `^2.7.0`. It has a proprietary licence from Saxonica (SaxonJS License), so it is never installed by default: read the licence, then add it yourself.

Environment variables:

FSE_MCP_CATALOGS_DIR: an it-fse-catalogs checkout (the folder with the .fse-catalogs-commit marker), to use instead of the files bundled in the validator package.
FSE_MCP_SCHEMATRON_DIR: a folder of compiled schematrons (<name>.sef.json), same idea.

Neither is needed in a normal install: without them the validator uses the catalogs it ships with. They are there for a development clone next to fse-client, or to pin a different catalogs commit yourself.

How a result reads:

Levels run in the gateway's order: XSD, then schematron only if the XSD passes (not_run_xsd_failed otherwise).
The schematron is chosen from the LOINC code in ClinicalDocument/code for the four document types of generate_sample_cda; any other code gives skipped_unknown_document_type, never a guess.
skipped_saxon_missing, skipped_schematron_missing and skipped_catalogs_missing mean the level did not run, so the absence of issues says nothing about it. status: "valid" is about the levels that ran.

HTTP mode

stdio is the default and the safest choice: only the client that started the process can talk to it. For clients that need HTTP:

export FSE_MCP_TOKEN="$(openssl rand -hex 32)"
npx -y @massimiliano-dev/fse-mcp --http            # http://127.0.0.1:3333/mcp

Clients send Authorization: Bearer $FSE_MCP_TOKEN. Security properties:

Loopback only by default. Binding elsewhere (--host 0.0.0.0) is refused unless you also pass --allowed-host <name>; put a TLS-terminating reverse proxy in front, never expose plain HTTP.
Token required. The server refuses to start without FSE_MCP_TOKEN (32+ characters). It is compared in constant time, removed from the process environment after start-up and redacted from logs.
DNS rebinding protection. Host and Origin must be an allowed hostname (localhost, 127.0.0.1, [::1] by default), checked before authentication, plus the SDK's own host check.
No CORS. No Access-Control-* headers are sent, so web pages on other origins cannot read responses.
Bounded requests. 5 MiB body limit (413), header and request timeouts, stateless mode with POST only.

Options: --host, --port (default 3333), --allowed-host (repeatable), --log-level. Run fse-mcp --help.

Data protection

Never paste real patient documents into a hosted LLM. A CDA2 document is health data under GDPR art. 9. The MCP server runs locally, but whatever the model reads is sent to the model provider. Use the output of generate_sample_cda or documents you anonymised yourself.
The server makes no outbound network calls and stores nothing. Logs go to stderr only, never include tool inputs, and redact codici fiscali, STP/ENI codes, JWTs and bearer tokens as a safety net.
Text returned from a submitted document is labelled as untrusted data. A document can contain prompt injection ("ignore previous instructions..."); your client should treat tool output as data.

See SECURITY.md for the threat model.

Development

pnpm install
pnpm test            # unit tests, including the HTTP security checks
pnpm lint && pnpm typecheck && pnpm format:check
pnpm build
pnpm inspect         # opens the MCP Inspector against the built server

Agensi skill

skill/fse-cda-triage/ is a skill package for Agensi: a SKILL.md that teaches an agent how to triage a gateway rejection, plus reference tables generated from it-fse-catalogs (the laboratory report rules, the document types, the code systems). It ships no code and makes no network calls; full validation is left to this server. It is not part of the npm package. skill/LISTING.md is the draft for the submission form.

pnpm skill:references            # regenerate skill/fse-cda-triage/references/ from FSE_MCP_CATALOGS_DIR
pnpm skill:references --check    # exit 1 if the committed references differ from the catalogs
pnpm skill:zip                   # check the SKILL.md frontmatter, write skill/dist/fse-cda-triage.zip

Regenerate the references whenever the catalogs commit changes; the tests fail if they are out of date (and are skipped when no catalogs checkout is available).

Roadmap

What is still missing, in order of impact:

Schematrons for the other 21 document types: compile them, test them against synthetic documents, and verify the matching generate_sample_cda skeletons. Only the laboratory report is covered today.
Terminology checks: the gateway validates codes against the national dictionaries; this server does not, so a document that passes locally can still be rejected.
Complete dictionaries for lookup_code, generated from a pinned it-fse-catalogs commit instead of the current samples.
Explanations for the most common rejections of every document type, not only the laboratory report.
Resources with the official schematron text per document type.

Licence and third-party content

MIT, see LICENSE. Sample codes and schematron messages are taken from it-fse-catalogs. saxon-js is not bundled or redistributed: if you install it, you accept Saxonica's licence.

This material contains content from LOINC (http://loinc.org). LOINC is copyright © 1995-2023, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license at http://loinc.org/license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.

Available Tools

4 tools

explain_schematron_errorExplain an FSE validation errorA

Read-onlyIdempotent

Explains in plain language an XSD or schematron error returned by the FSE 2.0 gateway for a CDA2 document, and suggests how to fix it. Input is the error message or rule id, not the document.

Name	Required	Description	Default
`error`	Yes	The error message or rule id returned by the FSE gateway or a validator, for example "ERRORE-4\| Almeno un elemento 'templateId' ..." or "cvc-complex-type.2.4.a". Do not include patient data.

Output Schema

Name	Required	Description
`note`	Yes
`matched`	Yes
`matches`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds relevant behavioral context: it interprets errors in plain language and proposes fixes, and it constrains the input to error text or rule id rather than documents. It does not need to describe return values because an output schema exists.

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?

Two compact sentences, front-loaded with the tool's purpose and followed by the key input constraint. Every sentence adds relevant information with no waste.

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?

Given a single-parameter, read-only, idempotent tool with full schema coverage, annotations, and an output schema, the description is complete enough for correct invocation. It states what the tool does, what the input is, and what value it provides.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single error parameter with examples and a privacy warning. The description adds useful semantic clarification that the input is the error message or rule id, not the CDA document itself.

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 uses a specific verb and resource: it explains XSD or schematron validation errors from the FSE 2.0 gateway for CDA2 documents and suggests fixes. It also clarifies the input is an error message or rule id, not the document, which distinguishes it from sibling tools like validate_cda.

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?

It clearly implies when to use the tool: after receiving an error from the FSE gateway or validator, to get a plain-language explanation and fix. It explicitly says the input is not the document, which helps avoid confusion with validate_cda, but it does not name alternatives or state exclusions explicitly.

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

generate_sample_cdaGenerate a synthetic CDA2 skeletonA

Read-onlyIdempotent

Returns a SYNTHETIC CDA2 document skeleton for the chosen FSE 2.0 document type, with fictional patient, doctor and organisation data, to use as a starting point or as a test fixture.

Name	Required	Description	Default
`documentType`	Yes	Document type: referto_laboratorio = Referto di Laboratorio (LAB); lettera_dimissione = Lettera di Dimissione Ospedaliera (LDO); referto_radiologia = Referto di Radiologia (RAD); verbale_pronto_soccorso = Verbale di Pronto Soccorso (VPS).

Output Schema

Name	Required	Description
`xml`	Yes
`note`	Yes
`label`	Yes
`loincCode`	Yes
`synthetic`	Yes
`schematron`	Yes
`templateId`	Yes
`documentType`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description's added value is the content disclosure: fictional patient, doctor and organisation data, and a 'skeleton' rather than a complete document. The one meaningful omission is whether the output is schema-valid or must be validated separately.

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?

One sentence, front-loaded with the return value and the 'SYNTHETIC' qualifier, then the data composition, then the intended use. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full parameter documentation, the description only needs to convey purpose and constraints, which it does. The missing piece is the workflow link to validate_cda, which would tell an agent whether the generated skeleton is usable as-is or needs validation.

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?

There is a single parameter with 100% schema description coverage, including a per-enum-value explanation of all four document types. The description only adds the phrase 'chosen FSE 2.0 document type,' which restates the schema rather than extending it. 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 ('Returns'), a precise resource ('SYNTHETIC CDA2 document skeleton'), and the scoping qualifier ('for the chosen FSE 2.0 document type'). This is unambiguous against the sibling set (validate_cda, explain_schematron_error, lookup_code), none of which generate documents.

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?

Explicitly frames the intended contexts: 'as a starting point or as a test fixture.' That is clear usage guidance, but it offers no exclusions or pointer to a sibling (e.g., that validate_cda should be run on the result), so it stops short of full when/when-not coverage.

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

lookup_codeLook up a code in the FSE dictionariesA

Read-onlyIdempotent

Looks up a code, or searches display names, in the terminologies used by FSE 2.0 CDA2 documents (LOINC, ICD9-CM, ATC, AIC, AdministrativeGender) and returns the code system OID to use in @codeSystem.

Name	Required	Description
`limit`	No	Maximum number of results.
`query`	Yes	An exact code (for example "11502-2") or words to search in the display name.
`system`	Yes	Code system to search.

Output Schema

Name	Required	Description
`note`	Yes
`system`	Yes
`results`	Yes
`sampleData`	Yes
`totalMatches`	Yes
`codeSystemOid`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that the result is the code-system OID usable in @codeSystem, but says nothing about empty-result behavior, ambiguity when multiple matches exist, or the effect of the limit cap.

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?

A single front-loaded sentence led by the verb, with the terminology enumeration confined to one parenthetical. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With full schema coverage, complete annotations, and an output schema that documents the return shape, the description supplies everything needed to invoke the tool correctly. Only edge-case behavior (no matches, ambiguous queries) is left unstated, which is a minor gap.

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 all three parameters are already documented, including the exact-code-vs-display-name dual mode of query and the maximum of 25 results. The description's restatement of the code-system list mirrors the schema enum and adds no new syntax or format guidance, 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?

The description names a specific verb (looks up / searches) and resource (codes and display names in FSE terminologies), enumerates the exact code systems, and states the concrete return value (the code system OID for @codeSystem). This clearly separates it from siblings like validate_cda, explain_schematron_error, and generate_sample_cda.

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?

It states the two usage modes - exact code lookup or display-name search - and the downstream purpose (obtaining the OID for @codeSystem), which tells an agent when the tool is relevant. It stops short of naming exclusions or pointing to an alternative tool when a lookup fails.

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

validate_cdaValidate a CDA2 documentA

Read-onlyIdempotent

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.

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

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.1.0Oct 29, 2026

Changedvalidate_cda8 fields changed

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"
+]

4 tool updatesv0.0.0Oct 26, 2026
- First observedexplain_schematron_error
- First observedgenerate_sample_cda
- First observedlookup_code
- First observedvalidate_cda

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored 2026-10-29 08:10 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: validation of a document, explanation of an error string, generation of a sample document, and terminology lookup. The possible overlap between validation and error explanation is resolved because explain_schematron_error takes an error message or rule id rather than a document.

Naming Consistency5/5

All tool names use consistent snake_case verb_noun phrasing: validate_cda, explain_schematron_error, generate_sample_cda, and lookup_code. The pattern is predictable and readable.

Tool Count5/5

The set is narrowly scoped to FSE 2.0 CDA2 validation and assistance, so four tools is reasonable. Each tool covers a distinct and useful part of the workflow without redundant operations.

Completeness4/5

The core local workflow is covered: validate a CDA, explain validation errors, generate a synthetic starting document, and look up terminology codes. Minor gaps remain, such as listing supported document types or catalog metadata and batch validation, but agents can generally work around these.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

E-invoice validator & repair check (XRechnung, Peppol BIS 3, EN 16931)A
io.github.nyo-agentti
Validate XRechnung, Peppol BIS 3 and EN 16931 invoices with KoSIT; explain rules; check auto-repair
Finance Legal & Compliance
21
https://einvoice-validator-k2qw.onrender.com/mcp
ZUGFeRD Validator A
de.zugferd-validator
Validiert E-Rechnungen (ZUGFeRD/Factur-X, XRechnung) gegen EN 16931 mit Korrekturvorschlägen.
Legal & Compliance Finance App Automation
52
https://api.zugferd-validator.de/mcp
K01 Synthetic Health Data
is.k01
Privacy-preserving synthetic health data generation. FHIR R4/R5 compliant.
Biology & Medicine Research & Data Health & Wellness
21
https://mcp.k01.is/mcp
Invoiceer e-invoicing tools A
io.invoiceer
Create and validate XRechnung, ZUGFeRD and Peppol e-invoices (KoSIT); Peppol lookup, rule help.
Finance Legal & Compliance Payments & Billing
61
https://invoiceer.io/mcp

Related MCP Servers

beliq-mcpofficial
Finance Legal & Compliance
beliq-eu
A
license
A
quality
C
maintenance
Validates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.
Updated 2 days ago (2026-10-28 00:46 UTC)
2
137 npm
MIT
HL7-Bridge MCP
Biology & Medicine Developer Tools Data Platforms
GlennRTC
A
license
A
quality
B
maintenance
Translates HL7 v2.x messages to FHIR R4, validates against profiles like US Core, and explains errors in natural language for AI agents.
Updated 3 days ago (2026-10-26 13:12 UTC)
4
0
Apache 2.0
FHIR Tools MCP Server
Biology & Medicine Testing & QA Tools Legal & Compliance
charan-pagolu
F
license
Not graded
quality
C
maintenance
Provides FHIR resource validation, synthetic test fixture generation, and HIPAA-safe logging review as MCP tools for AI agents.
Updated 3 months ago (2026-08-11 22:40 UTC)
-
HL7 v2.5.1 → FHIR R4 Mapping
Biology & Medicine Data Platforms
coffeemilktea
A
license
Not graded
quality
B
maintenance
Enables users to look up how specific v2 fields, datatypes, and table codes translate to R4, and to convert whole ORM, ADT, and ORU messages into transaction Bundles with explicit warnings for unmapped values.
Updated 10 days ago (2026-10-20 05:07 UTC)
MIT

fse-mcp

Tools

Status

Install

Claude Code

Claude Desktop

Validation setup

HTTP mode

Data protection

Development

Agensi skill

Roadmap

Licence and third-party content

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

beliq-mcpofficial