fse-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FSE_MCP_TOKEN | No | Bearer token required only in HTTP mode (--http). The server refuses to start without it when HTTP mode is enabled; must be 32+ characters. Not needed for the default stdio transport. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_cdaA | 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. |
| explain_schematron_errorA | 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. |
| lookup_codeA | 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. |
| generate_sample_cdaA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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.
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.
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.
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.