sdc-mapper-mcp
OfficialThis MCP server exposes sdc-mapper’s outbound Governed Data Record validation, mapping, fidelity comparison, and audit-log capabilities.
List installed target mappers, their target format/version, package, and Exceptional Value handling.
Map a GDR XML record to a chosen target using the record’s model or a supplied
ct_id/directoryand optional YAML mapping; return or write outputs, coverage report, target limitations, and log hash.Validate a mapping YAML and check that it is bound to a model’s current schema.
Run every installed mapper on one record and compare how each target handles each Exceptional Value.
Summarize log activity over a day window and verify the hash-chained log for alteration or removal.
Report outcomes as valid, valid with Exceptional Values, or refused, with refused records writing nothing and returning/logging reasons.
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., "@sdc-mapper-mcp map record.xml to UBL and report every value's fidelity"
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.
sdc-mapper
The shared core of the Semantic Data Charter's Governed Data Record mappers. It validates a record, reads the model the record names, resolves every value against what the model says about it, hands the result to a target mapper, and reports every value: how it reached the target, or that the target cannot hold it. Where the record says why a value is missing or unusable (an Exceptional Value, from the ISO 21090 null flavors), the report also says whether the target could say it too. Every call is appended to a hash-chained log that holds no values.
Each target format is its own package (sdc-gdr2ubl, sdc-gdr2edifact, sdc-gdr2omop, ...) registered under the
entry-point group sdc_mapper.targets. Outbound only. Apache 2.0.
Status: 4.3.2. Five target mappers are released: sdc-gdr2ubl (OASIS UBL 2.3), sdc-gdr2edifact (UN/EDIFACT
D.24A), sdc-gdr2omop (OMOP CDM 5.4), sdc-gdr2fhir (HL7 FHIR R4) and sdc-gdr2hl7v2 (HL7 v2.5.1).
Use
sdc-map targets
sdc-map map TARGET record.xml --package DIR [--mapping m.yaml] [-o out/]
sdc-map fidelity record.xml --package DIR # every installed target, side by side, per Exceptional Value
sdc-map check-mapping m.yaml --package DIR
sdc-map log summary --days 7 | sdc-map log verify
sdc-mapper [--log-dir DIR] [--host URL] # MCP stdio server (also sdc-mapper-mcp): the primary way agents use the mappersA model is a package directory (dm-<ct>.jsonld, dm-<ct>.xsd) or a published model's --ct-id, fetched from the
SDCStudio host; with neither, the record's own root names it. Exit status: 0 mapped, 1 refused, 2 error.
Also listed on mcprush.
Related MCP server: LogicMem MCP Server
The three outcomes
valid: mapped.
valid with Exceptional Values: a value that failed its constraint is covered by an Exceptional Value (Invalid, with the constraint kept), and the rest of the record is mapped. Exceptional Values written at the source (a refusal, a masked field) are kept as written.
refused: a broken structure, the wrong model, or an error no Exceptional Value covers. Nothing is written; the reasons are returned and logged.
Mapping files
YAML, validated against schemas/mapping.schema.json, bound to one model schema version and one target version.
mapping: {id: credit-note-to-ubl, version: 1}
model: {ct_id: jkuyr38hydqaiwlq5vhp2rjr, schema_sha256: "…"}
target: {name: OASIS UBL, version: "2.3 CreditNote"}
rules:
- cluster: <Accounting Supplier Party> # a cluster to a target element
to: cac:AccountingSupplierParty
- cluster: <Party> # relative to the enclosing mapped cluster
to: cac:Party
- component: <Party Identification Value>
to: cac:PartyIdentification/cbc:ID
transform: copy
- component: <Party Identification Scheme>
to: cac:PartyIdentification/cbc:ID/@schemeName # an attribute of the same element
transform: copy
- component: <Line Extension Amount>
to: cbc:LineExtensionAmount
transform: copy
units: {to: "@currencyID", transform: copy}
- cluster: <Party Contact>
to: "-"
transform: omit
reason: the target profile carries no contactTransforms: copy, code (a table), format, constant, binding (the code the model defines an enumerated value
by), link (the code of the concept the component links to), omit; clusters group or omit. binding and link
take a system (http://loinc.org, http://snomed.info/sct, a code list's IRI); their text is the model's, so a mapper
reports it as a lookup (LOOKUP_TRANSFORMS). Steps: .. up, . none, +name an element of the value's own, =name
the element of that name the parent already has. within: restricts a rule to a context. A value no rule reaches is
reported, never dropped. place(record, mapping) turns a record and its mapping into placements a mapper writes from.
Codes the model names
sdc_mapper.codes reads the IRIs the component libraries use for a concept as a code system and a code: LOINC codes
and answers, SNOMED CT, NCI Thesaurus, and any code list whose IRI ends in #code (UBL's, HL7's). A code system is
named by the IRI FHIR uses for it; a mapper turns that into its own name for the system (OMOP's vocabulary_id, HL7
v2's coding system). bound_code(value) is the code an enumerated value is defined by, linked_code(value) the code
of the concept its component links to (skos:exactMatch, then dcterms:subject), and model_codes(value) every code
the model names for it: a target code that is one of these came from the model.
Writing to a target
place() gives each value its target steps. Steps written =name join an element made by another value, so a writer
holds those writes back until every other value is written, then writes them shallowest first: sort them by
join_depth(steps). A row-oriented target (a set of tables, as OMOP's) can treat each step as a table or a column,
+TABLE as one new row per value, and keep the record's own row (its person, its document) under a name of its own;
sdc-gdr2omop does so with a RECORD table.
Writing a mapper
A mapper has name, target, target_version, package, version, an Exceptional Value table (ev_table: an
EVRule per ISO 21090 code: preserved, degraded, carried or lost) and map(record, mapping) -> MapResult. It returns
one ValueOutcome for every value it was given, never writes a rejected value as a value, and registers itself:
[project.entry-points."sdc_mapper.targets"]
ubl = "sdc_gdr2ubl:UBLMapper"Tests
python -m pytest tests -q (offline). The fixture is a HalvorsenDemo Credit Note record and its model's package;
the reference mapper in tests/refmapper.py is a flat CSV used only to exercise the contract.
License
Apache 2.0. See NOTICE for the shipped SDC4 reference model schema and the fixture.
Available Tools
6 toolscheck_mappingB
Validate a mapping file against the mapping schema, and, given a model, check it is bound to that model's current schema.
Inputs: mapping (required), ct_id, directory.
fidelityB
Run every installed mapper on one record and compare what each target did with each Exceptional Value: one row per Exceptional Value, one column per target. Shows which formats can say why a value is missing or unusable, and which can only leave it empty.
Inputs: record (required), ct_id, mappings, directory.
list_targetsA
The target mappers installed: each target format and version, its package, and how it writes each ISO 21090 Exceptional Value (preserved, degraded, carried or lost).
Inputs: no named parameters.
log_summaryB
Read the log back over a window: calls, outcomes, value classes and Exceptional Value classes per target, and the models and mapping files in use.
Inputs: days.
map_recordA
Map one Governed Data Record to one target format. The record is validated first: valid, valid with Exceptional Values (one bad value is marked, not fatal), or refused with the reasons. Returns the output (inline, or written to output_dir), the coverage report (how every value reached the target, and what happened to every Exceptional Value), one sentence of what the target could not say, and the hash of the log entry. The model is the one the record names unless ct_id or directory is given.
Inputs: record (required), target (required), ct_id, mapping, +2 more.
verify_logA
Walk the log's hash chain from the first entry and report whether any entry was altered or removed.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 6 tools
Each tool has a clearly distinct role: listing targets, mapping a record, validating a mapping file, comparing fidelity across mappers, summarizing the log, and verifying log integrity. Although map_record and fidelity both involve mapping a record, their scopes are clearly separated (single target vs. cross-target comparison) and descriptions make the boundary explicit.
Most tools follow a clear verb_noun pattern (list_targets, map_record, check_mapping, log_summary, verify_log), with 'fidelity' being the lone noun-only exception. The set remains readable and predictable overall, but the deviation prevents a perfect score.
Six tools is well-scoped for a mapping and logging server, and each tool appears to earn its place. There is no apparent bloat or missing essential operation at the count level.
The surface covers target listing, mapping, mapping validation, cross-target fidelity comparison, log summarization, and log integrity verification. Minor gaps exist around discovering available models or mapping files, but core workflows are covered and agents can work around these omissions.
Maintenance
Related MCP Connectors
Governance runtime for compliance: verified, human-approved writes to a tamper-evident record.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Live behavioral security verifier, schema auditor, and trust oracle for A2A, MCP & x402 agents.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Related MCP Servers
- AlicenseBqualityFmaintenanceProvides persistent memory, reasoning engine, agent-to-agent sharing, and immutable audit trail for AI agents via the Model Context Protocol.12MIT

LogicMem MCP Serverofficial
AlicenseBqualityCmaintenanceProvides persistent memory, reasoning, agent-to-agent sharing, and immutable audit trail for AI agents via the Model Context Protocol.121MIT- AlicenseNot gradedqualityDmaintenanceA governed context layer for internal data exposed over MCP, enabling agents to query governed definitions, retrieve grounded data, and execute scoped actions with citations and auditing.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceAn auditable memory, lifecycle, and governance server for AI agents, providing durable memories with provenance, lifecycle management, and guarded workflows through the Model Context Protocol.Apache 2.0