snowstorm-mcp-server

Ein MCP-Server zum Abfragen der klinischen Terminologie SNOMED CT über die Backends Snowstorm und Snowstorm Lite.

SNOMED CT ist die umfassendste klinische Terminologie der Welt und wird in elektronischen Gesundheitsakten in über 80 Ländern eingesetzt. Dieser Server stellt SNOMED-CT-Nachschlagefunktionen, Suche, Validierung, Hierarchienavigation und Wertemengen-Expansion über das Model Context Protocol (MCP) bereit und ermöglicht es KI-Assistenten, direkt mit klinischer Terminologie zu arbeiten.

Unterstützt alle auf dem verbundenen Backend verfügbaren SNOMED-CT-Editionen (International, US, UK, AU usw.). Beim Verbinden mit einer öffentlichen Snowstorm-Instanz ist kein Benutzerkonto erforderlich.

Dieses Repository unterstützt zwei verwandte, aber unterschiedliche Nutzungsmodi:

1. Gehosteter Remote-Connector: Betreiben Sie einen öffentlichen HTTPS-MCP-Endpunkt und verbinden Sie Claude darüber über den benutzerdefinierten Connector-/Connector-Directory-Ablauf.

2. Selbst gehostete oder lokale Nutzung: Führen Sie den Server selbst gegen Ihre eigene Snowstorm- oder Snowstorm-Lite-Bereitstellung aus, einschließlich Claude Desktop und zukünftiger MCPB-Paketierungsszenarien.

Wenn Sie einen gehosteten Connector für Claude web/desktop/mobile vorbereiten, beginnen Sie mit Gehosteter Remote-Connector. Wenn Sie den Server selbst gegen Ihr eigenes Terminologie-Backend ausführen möchten, beginnen Sie mit Selbst gehostete und lokale Nutzung.

Gehosteter Remote-Connector

Verwenden Sie diesen Modus, wenn Sie einen öffentlichen MCP-Endpunkt betreiben, z. B. https://your-domain.example/mcp, und möchten, dass Claude sich aus der Infrastruktur von Anthropic damit verbindet.

Gehostete Bereitstellung (Docker)

Container bauen und ausführen:

docker build -t snowstorm-mcp-server .
docker run -p 8000:8000 --memory=512m --restart=unless-stopped snowstorm-mcp-server

Setzen Sie --memory. Ohne ein cgroup-Limit kann der Container wachsen, bis der globale OOM-Killer des Kernels zuschlägt, und der wählt den größten Prozess auf dem Host aus – ein Fehler in diesem Server bringt also die gesamte Maschine zu Fall statt nur den Container. Mit einem Limit wird nur der Container beendet und --restart bringt ihn sofort zurück.

Der Server startet im Streamable-HTTP-Modus auf Port 8000 und verwendet die mitgelieferte config.docker-snowstorm.yaml (erwartet ein lokales Snowstorm unter http://localhost:8080). Mounten Sie zur Laufzeit Ihre eigene Konfiguration:

docker run -p 8000:8000 \
  -v /path/to/your/config.yaml:/app/config.yaml \
  snowstorm-mcp-server

Für die Produktion stellen Sie den Dienst hinter einem HTTPS-Reverse-Proxy oder auf einer Plattform mit automatischem TLS bereit (Cloud Run, Fly.io, Railway usw.). Für öffentlich erreichbare Bereitstellungen konfigurieren Sie am Reverse-Proxy eine Ratenbegrenzung pro Client (IP-basiert). MCP 2026-07-28 hat Sitzungen auf Protokollebene entfernt, daher gilt die Begrenzung pro Sitzung auf Anwendungsebene nicht mehr für HTTP-Clients; die globale Grenze begrenzt weiterhin die Gesamtlast des Backends – siehe Performance-Guards unten.

Für Remote-MCP-Connector-Bereitstellungen für Claude web/desktop aktiviert der Server standardmäßig CORS für https://claude.ai und https://claude.com auf dem Streamable-HTTP-Endpunkt. Überschreiben Sie bei Bedarf die Liste der erlaubten Ursprünge mit der Umgebungsvariablen SNOWSTORM_MCP_CORS_ALLOW_ORIGINS mithilfe einer durch Kommas getrennten Liste.

Die Origin-Validierung ist standardmäßig aktiviert. Eine Anfrage an den MCP-Endpunkt, deren Origin-Header vorhanden, aber nicht in der Zulassungsliste ist, wird mit HTTP 403 abgelehnt. Das verhindert DNS-Rebinding: Eine umgebundene Seite sendet bei ihrem POST weiterhin ihren echten Ursprung, da Browser gemäß dem Fetch Standard bei jedem POST einen Origin-Header anhängen – auch bei gleichoriginären. Anfragen ganz ohne Origin, also alle Nicht-Browser-MCP-Clients, sind nicht betroffen.

Das gilt für alle aktuellen Browser-Engines. Firefox vor Version 103 (Juli 2022) konnte Origin vollständig weglassen, anstatt null zu senden, insbesondere wenn die Einstellung network.http.sendOriginHeader deaktiviert war; setzen Sie in diesem Fall auch SNOWSTORM_MCP_ALLOWED_HOSTS, falls solche Clients relevant sind.

Die Zulassungsliste entspricht standardmäßig den oben genannten CORS-Ursprüngen. Überschreiben Sie sie unabhängig mit SNOWSTORM_MCP_ALLOWED_ORIGINS (durch Kommas getrennt) für gleichoriginäre Bereitstellungen hinter einem Reverse-Proxy, bei denen CORS deaktiviert ist, Browser-POSTs aber weiterhin einen Origin-Header senden. Sie ersetzt die Liste, anstatt sie zu erweitern. Nehmen Sie also jeden Browser-Ursprung auf, den Sie bedienen – wenn Sie nur Ihre eigene Domain angeben, wird https://claude.ai ausgesperrt. Wenn Sie * setzen, wird die Prüfung auf Anwendungsebene deaktiviert. Beachten Sie: Wenn zusätzlich SNOWSTORM_MCP_ALLOWED_HOSTS gesetzt ist, validiert die SDK-Ebene Origin weiterhin anhand der CORS-Liste.

Upgrade-Hinweis: Browser-Clients, deren Seitenursprung nicht in der Zulassungsliste steht, erhalten jetzt 403, wo sie zuvor erfolgreich waren – unabhängig von den CORS-Einstellungen. CORS hat diese Anfragen nie abgelehnt; es hat lediglich Antwort-Header zurückgehalten, und gleichoriginäre Lesevorgänge unterlagen nie der CORS-Kontrolle. Eine selbst gehostete Bereitstellung, die eine eigene Web-UI ausliefert, muss SNOWSTORM_MCP_ALLOWED_ORIGINS auf diesen Ursprung setzen – oder auf *, um das bisherige Verhalten wiederherzustellen. Nicht-Browser-Clients senden kein Origin und sind nicht betroffen.

Setzen Sie SNOWSTORM_MCP_ALLOWED_HOSTS auf die Hostnamen, unter denen der Server erreichbar ist (durch Kommas getrennt, z. B. mcp.example.org,mcp.example.org:443), um zusätzlich einen nicht erkannten Host mit HTTP 421 abzulehnen. Diese Prüfung ist standardmäßig deaktiviert, da eine unvollständige Hostliste den gesamten Verkehr ablehnt; sie wird automatisch aktiviert, wenn an localhost gebunden wird. Es handelt sich um eine mehrschichtige Verteidigung – die oben beschriebene Origin-Validierung schließt den Rebinding-Vektor auf diesem Nur-POST-Endpunkt bereits.

MCP-Protokollversionen

Der Server unterstützt zwei Ären: Er bedient die zustandslose Revision MCP 2026-07-28 und die älteren handshake-basierten Revisionen (2025-11-25 und früher) über denselben Endpunkt, sodass bestehende Clients weiterhin funktionieren. Er läuft in beiden Fällen zustandslos und erzeugt niemals eine Mcp-Session-Id, was bedeutet, dass er ohne Sitzungsaffinität horizontal skaliert werden kann.

Hinweise zum Remote-Connector

• Anthropic verbindet sich aus seiner Cloud-Infrastruktur mit Ihrem gehosteten MCP-Endpunkt.

• Anthropic konfiguriert nicht Ihre internen Snowstorm-Backend-Einstellungen wie base_url, user_agent oder Ziel-Authentifizierung. Diese bleiben in Ihrer Serverkonfiguration.

• manifest.json in diesem Repository ist für lokale Paketierungsszenarien gedacht, nicht für den gehosteten Remote-Connector-Ablauf.

Related MCP server: Smart EHR MCP Server

Selbst gehostete und lokale Nutzung

Verwenden Sie diesen Modus, wenn Sie den MCP-Server selbst gegen Ihr eigenes Snowstorm- oder Snowstorm-Lite-Backend ausführen möchten – lokal, in privater Infrastruktur oder für Claude-Desktop-/MCPB-artige Paketierung.

Schnellstart für die Entwicklung

uv venv
uv pip install -e ".[dev]"
uv run pytest -q
./scripts/check.sh

Informationen zu Unit- und Integrationstest-Workflows (einschließlich Docker-Stack-Einrichtung und RF2-Import) finden Sie in docs/testing.md.

Docker-Integrationsstack (Snowstorm + Lite)

Lokale Container für Integrationstests starten:

docker compose -f docker-compose.integration.yml up -d

Ein lokales RF2-Archiv sowohl in Snowstorm als auch in Snowstorm Lite importieren:

dev/integration/import_snomed.sh \
  --rf2-zip ../SnomedCT_InternationalRF2_PRODUCTION_20251101T120000Z.zip

Führen Sie Integrationstests gegen jedes Backend aus. Setzen Sie SNOWSTORM_MCP_TEST_CONFIG in Ihrer .env-Datei, um auf die entsprechende Konfiguration zu verweisen, und führen Sie dann Folgendes aus:

uv run pytest -q tests/integration

Den Server lokal ausführen

Der Server liest seine Konfiguration aus einer YAML-Datei (siehe example-configs/config.local.yaml). Erstellen Sie im Projektstamm eine .env-Datei, um den Konfigurationspfad und alle Geheimnisse festzulegen (siehe .env.example):

cp .env.example .env
# edit .env to point at your config file

Der Server lädt beim Start automatisch .env aus dem aktuellen Arbeitsverzeichnis. Bereits vorhandene Shell-Umgebungsvariablen haben Vorrang vor .env-Werten.

stdio (für Claude Desktop und die meisten MCP-Clients):

uv run snowstorm-mcp-server --transport stdio

Verwenden Sie --log-level DEBUG|INFO|WARNING|ERROR, um die Ausführlichkeit zu steuern (Standard: INFO). Logs werden auf stderr ausgegeben und von Claude Desktop in mcp-server-snowstorm.log erfasst. Der Server gibt beim Start die aktive Guard-Konfiguration aus, damit Sie bestätigen können, dass die Einstellungen aus der richtigen Konfigurationsdatei geladen werden.

Protokollierung

Standardmäßig protokolliert der Server ein JSON-Objekt pro Zeile mit einem UTC-Zeitstempel, das Log-Aggregatoren direkt parsen können:

{"timestamp": "2026-07-13T10:29:04.929Z", "level": "ERROR", "logger": "snowstorm_mcp_server.mcp_app", "message": "Tool call failed [E_BACKEND_HTTP]: HTTP 502 ...", "error_code": "E_BACKEND_HTTP", "error_type": "HttpRequestError", "status_code": 502}

Tool-Fehler enthalten strukturierte Felder (error_code, error_type, status_code), sodass Sie eine Fehlerrate nach Ursache aufschlüsseln können. Guard-Auslösungen (Ratenbegrenzungen, blockierte ECL, Traversal-Erkennung) werden als Warnungen protokolliert. Verwenden Sie --log-format text für die traditionelle, menschenlesbare Ausgabe während der lokalen Entwicklung.

Streamable HTTP (für HTTP-basierte MCP-Clients):

uv run snowstorm-mcp-server --transport streamable-http

Der eigenständige sse-Transport wurde zugunsten von Streamable HTTP entfernt. Der HTTP+SSE-Transport ist seit MCP 2025-03-26 veraltet und wird gemäß der Feature-Lifecycle-Richtlinie ab 2026-07-28 offiziell als Deprecated eingestuft.

Claude-Desktop-Konfigurationsbeispiel (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "snowstorm": {
      "command": "uv",
      "args": [
        "run",
        "--project", "/path/to/snowstorm-mcp-server",
        "snowstorm-mcp-server",
        "--transport", "stdio"
      ]
    }
  }
}

Hinweis: Claude Desktop führt uv aus dem Projektverzeichnis aus und übernimmt die .env-Datei daher automatisch. Wenn Sie explizite Umgebungsvariablen bevorzugen, übergeben Sie sie über den Schlüssel "env" in der Claude-Desktop-Konfiguration.

Lokale Paketierung / MCPB-Installationen

Wenn Sie den Server über einen Connector-Directory-Eintrag installieren, fragt das Manifest nach einem Pfad zur Konfigurationsdatei und übergibt ihn beim Start als --config. Wählen Sie für die lokale Entwicklung eine der YAML-Dateien in example-configs/ oder geben Sie den Pfad zu Ihrer eigenen Snowstorm-/Snowstorm-Lite-Bereitstellungskonfiguration an.

Konfiguration

Siehe example-configs/config.local.yaml (Snowstorm unter http://localhost:8080).

Einschränkung des Backend-Typs

Eine einzelne Konfiguration muss entweder Snowstorm- oder Snowstorm-Lite-Ziele verwenden – eine Mischung beider in derselben Konfiguration wird nicht unterstützt. Das Feld server_mode muss dem Zieltyp entsprechen ("snowstorm" für Snowstorm-Ziele, "lite" für Lite-Ziele).

Mehrere Snowstorm-Lite-Instanzen werden unterstützt (eine pro SNOMED-Edition).

Konfigurationsbeispiel für mehrere Editionen (Lite)

server_mode: "lite"
default_terminology: snomedct
response_limits:
  max_expand_contains: 100
  max_search_hits: 50
  max_synonyms: 25

# Guards — all values shown are defaults. Omit the block to use defaults.
# For public-facing HTTP deployments, do per-client limiting at the reverse
# proxy: MCP 2026-07-28 removed sessions, so per_session_rate_limit_calls
# only has an effect on stdio.
# guards:
#   rate_limit_calls: 10
#   rate_limit_window_seconds: 60
#   max_concurrent_requests: 3
#   max_count_per_call: 500
#   large_result_threshold: 1000
#   max_children_calls_per_minute: 5
#   per_session_rate_limit_calls: null   # stdio only; no effect over HTTP
#   block_zero_cardinality_on_large_sets: false  # set true to block [0..0] on top-level roots
#   enable_expansion_size_guard: false   # preflight summary check for any non-summary expansion
#   expansion_count_threshold: 20000     # block if total concepts exceeds this value
#   size_cache_ttl_seconds: 86400

targets:
  lite-int:
    base_url: "http://localhost:8081"
    mode: "lite"
    terminology_name: "snomedct"
    fhir_path: "/fhir"
    auth:
      mode: "none"

  lite-us:
    base_url: "http://localhost:8082"
    mode: "lite"
    terminology_name: "snomedct-us"
    fhir_path: "/fhir"
    auth:
      mode: "bearer"
      token: "${SNOWSTORM_LITE_TOKEN}"

Terminologiebasiertes Routing

Dieser Server leitet Anfragen nach Terminologie (SNOMED-Edition) weiter, nicht nach Backend-Ziel.

• Snowstorm: Terminologien werden automatisch über GET /codesystems ermittelt. Der shortName (in Kleinbuchstaben) jedes Codesystems wird zum Terminologienamen (z. B. snomedct, snomedct-us). Der Branch-Pfad wird für native Snowstorm-Operationen automatisch verwendet.

• Snowstorm Lite: Jede Instanz bedient eine Terminologie. Konfigurieren Sie terminology_name in der Zielkonfiguration.

Standard-Terminologie

Setzen Sie default_terminology in der Konfiguration, damit Aufrufer den Parameter terminology weglassen können. Wenn nur eine Terminologie verfügbar ist, wird sie automatisch zur Standard-Terminologie.

Verfügbare MCP-Tools

Alle Tools akzeptieren einen optionalen Parameter terminology (z. B. "snomedct-us"). Die meisten Tools akzeptieren außerdem ein optionales target, um das Routing einzuschränken bzw. die Zielauswahl eindeutig zu machen. Wenn nichts angegeben wird, wird die Standard-Terminologie verwendet.

Überschreiben von Geheimnissen per Umgebungsvariablen

Geheimnisse können zur Laufzeit über Umgebungsvariablen injiziert werden, anstatt Werte fest einzucommitten:

• Platzhalter-Interpolation in der Konfiguration: ${ENV_VAR} oder ${ENV_VAR:-default}

• Variablen zum Überschreiben von Ziel-Auth-Geheimnissen:

  • SNOWSTORM_MCP_TARGETS__<TARGET_NAME_UPPER>__AUTH__PASSWORD

  • SNOWSTORM_MCP_TARGETS__<TARGET_NAME_UPPER>__AUTH__TOKEN

Beispielhafte MCP-Toolaufrufe

list_terminologies:

{}

Erwartete Antwortstruktur:

{
  "terminologies": [
    {"name": "snomedct", "backend_type": "snowstorm", "branch_path": "MAIN"},
    {"name": "snomedct-us", "backend_type": "lite", "branch_path": null}
  ],
  "default_terminology": "snomedct"
}

server_capabilities (Standard-Terminologie):

{}

Erwartete Antwortstruktur:

{
  "terminology": "snomedct",
  "backend_type": "snowstorm",
  "reachable": true,
  "fhir_base_url": "http://localhost:8080/fhir",
  "capabilities": {"has_fhir": true, "has_native_api": true, "has_lite_load_package": false},
  "fhir_metadata_summary": {"resourceType": "CapabilityStatement", "fhirVersion": "4.0.1"}
}

fhir_metadata im Nur-Zusammenfassungs-Modus (rohen CapabilityStatement-Body weglassen):

{"terminology": "snomedct", "include_raw": false}

Erwartete Antwortstruktur:

{
  "terminology": "snomedct",
  "fhir_base_url": "http://localhost:8080/fhir",
  "summary": {"resourceType": "CapabilityStatement", "fhirVersion": "4.0.1"}
}

snomed_lookup:

{"code": "404684003", "terminology": "snomedct"}

Erwartete Antwortstruktur:

{
  "terminology": "snomedct",
  "code": "404684003",
  "found": true,
  "display": "Clinical finding",
  "system": "http://snomed.info/sct"
}

Wenn der Code in der Edition nicht existiert, gibt das Tool ein strukturiertes Negativergebnis zurück statt eines Fehlers:

{
  "terminology": "snomedct",
  "code": "99999999999",
  "found": false,
  "message": "Code '99999999999' was not found in this SNOMED CT edition/version. Verify the concept ID or search for the concept by term."
}

snowstorm_search_concepts (nur Snowstorm):

{"terminology": "snomedct", "term": "myocardial infarction", "limit": 5}

Erwartete Antwortstruktur:

{
  "terminology": "snomedct",
  "term": "myocardial infarction",
  "branch": "MAIN",
  "returned": 5,
  "hits": [{"concept_id": "22298006", "pt": "Myocardial infarction"}]
}

Anwendungsbeispiele

Diese Beispiele zeigen, wie ein KI-Assistent die Tools des Servers als Antwort auf natürlichsprachliche Fragen verwendet.

Beispiel 1 – Klinisches Konzept nachschlagen

Benutzer: „Was ist das SNOMED-CT-Konzept 22298006?"

Der Assistent ruft snomed_lookup mit {"code": "22298006"} auf und erhält den bevorzugten Begriff des Konzepts („Myokardinfarkt"), seine SNOMED-CT-System-URI und alle zugehörigen Eigenschaften. Der Assistent kann das Konzept dem Benutzer dann in einfacher Sprache erklären, einschließlich seiner klinischen Bedeutung.

Beispiel 2 – Prüfen einer hierarchischen Beziehung

Benutzer: „Ist Typ-2-Diabetes mellitus eine Art endokrine Störung in SNOMED CT?"

Der Assistent ruft snomed_subsumes mit {"code_a": "362969004", "code_b": "44054006"} auf (endokrine Störung bzw. Typ-2-Diabetes mellitus). Die Antwort zeigt an, ob code_a code_b subsumiert, und bestätigt oder verneint damit die IS-A-Beziehung.

Beispiel 3 – Konzepte nach klinischem Begriff finden

Benutzer: „Finde SNOMED-CT-Konzepte, die mit ‚Vorhofflimmern' zu tun haben."

Der Assistent ruft snomed_expand mit {"filter": "atrial fibrillation", "count": 10} auf, um in der Terminologie zu suchen. Die Antwort liefert passende Konzepte mit ihren IDs, bevorzugten Begriffen und ob sie aktiv sind, sodass der Assistent eine prägnante Liste klinisch relevanter Treffer präsentieren kann.

FHIR-Operationen und Snowstorm mit mehreren Editionen

Für native Snowstorm-Operationen (Suche, Konzeptdetails) wird der Branch-Pfad der Terminologie automatisch verwendet, um die richtige Edition auszuwählen.

Für FHIR-Operationen ($lookup, $validate-code, $subsumes) leitet die Terminologie an den richtigen Backend-Server weiter. Bei einer Snowstorm-Instanz mit mehreren Editionen müssen Sie möglicherweise zusätzlich den FHIR-Parameter version angeben, um die Edition präzise auszuwählen, da die FHIR-Edition über die Parameter system/version gesteuert wird und nicht über Branch-Pfade.

Weitere Hinweise zu Backend-Fähigkeiten und die Grenzen des v0.1-Umfangs sind in docs/v0.1-capability-matrix.md dokumentiert. Schritte für Release-Tagging/Smoke-Tests finden Sie in docs/release-v0.1-checklist.md.

Performance-Schutzmechanismen

Alle Tools, die Backend-HTTP-Aufrufe durchführen, teilen sich eine gemeinsame Reihe von Schutzmechanismen, um die Snowstorm-Instanz vor Überlastung zu schützen. Diese gelten unabhängig davon, welches Tool aufgerufen wird — server_health, server_capabilities, fhir_metadata, snomed_expand, snomed_lookup, snomed_validate_code, snomed_subsumes, alle Hierarchie-Tools und alle nativen snowstorm_*-Tools.

Schutzmechanismen, die immer aktiv sind:

Nur pro Prozess. Die Schutzmechanismen verwenden In-Memory-Status. Wenn Sie mehrere Serverprozesse hinter einem Load Balancer betreiben, setzt jeder Prozess seine eigenen unabhängigen Grenzen durch. Für gemeinsame Grenzen über Prozesse hinweg ist eine Redis-gestützte Implementierung erforderlich.

Ratenbegrenzung pro Sitzung (nur stdio)

MCP 2026-07-28 hat Sitzungen auf Protokollebene entfernt. Über Streamable HTTP steht jede Anfrage für sich allein, daher hat per_session_rate_limit_calls nichts Stabiles, auf das es sich stützen könnte, und wird nie ausgelöst — jede Anfrage erhält ein frisches, leeres Fenster. Der Server protokolliert beim Start eine Warnung, wenn Sie es setzen. Es funktioniert weiterhin auf stdio, wo ein Prozess genau einen Client bedient. Verwenden Sie für HTTP-Bereitstellungen stattdessen eine Pro-Client-Begrenzung am Reverse-Proxy (Nginx limit_req, Caddy rate_limit, Cloudflare usw.), die auf der Netzwerkidentität basiert, die das Protokoll nicht mehr bereitstellt.

Die globale Ratenbegrenzung gilt für alle Aufrufer und bleibt unberührt — sie bleibt das Steuerelement, das die gesamte Backend-Last begrenzt:

guards:
  rate_limit_calls: 30            # global ceiling across all callers
  rate_limit_window_seconds: 60
  per_session_rate_limit_calls: 8 # stdio only; a no-op over HTTP

Wenn per_session_rate_limit_calls gesetzt ist, erhält jede Sitzung ihr eigenes unabhängiges rollierendes Fenster mit demselben rate_limit_window_seconds. Sitzungen werden über die Objektidentität verfolgt und automatisch verworfen, wenn das zugrunde liegende Sitzungsobjekt vom Garbage Collector entfernt wird.

Tools ohne Schutzmechanismen

In-Memory-Tools, die das Snowstorm-Backend nicht aufrufen, sind bewusst ohne Schutzmechanismen gelassen: list_terminologies.

Einschränkung der nativen Snowstorm-Suche (wichtig)

Das MCP-Tool snowstorm_search_concepts ruft den nativen Beschreibungssuch-Endpunkt von Snowstorm auf (GET /browser/{branch}/descriptions), der sehr kurze Suchanfragen (z. B. AD, B2) mit HTTP 400 ablehnen kann.

Praktische Hinweise:

• Verwenden Sie mindestens 3 durchsuchbare Zeichen (Buchstaben/Ziffern).

• Geben Sie bei kurzen Akronymen Kontext an (verwenden Sie zum Beispiel einen längeren Ausdruck statt AD).

Der MCP-Server validiert dies frühzeitig: Ein zu kurzer Begriff liefert eine erfolgreiche Antwort mit null Treffern und einem notice-Feld, das die Einschränkung erklärt, ohne Snowstorm aufzurufen. Erwartete negative Ergebnisse (ein zu kurzer Begriff oder ein snomed_lookup-Code, der nicht existiert) werden als strukturierte Daten zurückgegeben und nicht als Tool-Fehler, sodass MCP-Fehlermetriken nur echte Fehler widerspiegeln.

Datenschutzerklärung

Dieser Server fungiert als zustandsloser Proxy zwischen einem MCP-Client und einem konfigurierten SNOMED-CT-Backend (Snowstorm oder Snowstorm Lite). Er erhebt, speichert oder verarbeitet keine personenbezogenen Daten und sendet keine Daten an Dritte außer an das konfigurierte Backend. Der gesamte Abfrageinhalt wird an das Backend weitergeleitet und nach der Zustellung der Antwort verworfen. Wenn die Ratenbegrenzung pro Sitzung aktiviert ist, speichert der Server In-Memory-Aufrufzeitstempel pro Sitzung ausschließlich zur Durchsetzung der Ratenbegrenzung; dieser Zustand enthält keine personenbezogenen Daten (PII) und wird automatisch verworfen, wenn die Sitzung endet.

Antworten enthalten SNOMED-CT-Terminologieinhalte. Der Zugriff auf diese Inhalte über diesen Server unterliegt der SNOMED-CT-Browser-Lizenzvereinbarung (siehe Lizenz unten). Wenn der Server als gehosteter Dienst bereitgestellt wird, können von der Hosting-Infrastruktur zu Betriebszwecken standardmäßige Webserver-Zugriffsprotokolle (IP-Adresse, Zeitstempel, Anforderungspfad) aufbewahrt werden.

Die vollständige Datenschutzerklärung finden Sie in PRIVACY.md.

Support

• Probleme und Fehlerberichte: GitHub Issues

• SNOMED-CT-Lizenzierung und -Inhalte: SNOMED International

• Allgemeine Anfragen: info@snomed.org

Lizenz

Die Serversoftware ist unter Apache 2.0 lizenziert.

SNOMED-CT-Inhalte, die von diesem Server zurückgegeben werden, sind von dieser Lizenz nicht abgedeckt. Der Zugriff auf SNOMED CT über diesen Server unterliegt der SNOMED-CT-Browser-Lizenzvereinbarung, derselben Grundlage, auf der auch der öffentliche SNOMED-CT-Browser bereitgestellt wird. Zusammenfassend gilt: Endbenutzer, die keine SNOMED-International-Affiliate-Lizenz besitzen, dürfen diesen Server zum Erkunden und Bewerten der Terminologie verwenden, dürfen jedoch nicht:

• SNOMED-CT-Identifikatoren in ein Aufzeichnungssystem, eine Datenbank oder ein Dokument kopieren (Verwendung als „Data Creation System" oder „Data Analysis System");

• SNOMED-CT-Inhalte übersetzen oder verändern; oder

• SNOMED-CT-Inhalte weiterverbreiten oder teilen.

Wenn Sie diesen Server selbst hosten, SNOMED CT in ein Produkt oder eine Dienstleistung integrieren oder SNOMED CT über das Erkunden und Bewerten hinaus nutzen möchten, sollten Sie eine vollständige SNOMED-CT-Lizenz erwerben — siehe SNOMED CT erhalten. SNOMED-International-Affiliates dürfen diesen Server im Rahmen ihrer Affiliate-Lizenz verwenden. SNOMED CT ist © SNOMED International; „SNOMED" und „SNOMED CT" sind eingetragene Marken.