KI & MCP

Hinweis: Die MCP-Integration befindet sich in einem frühen Entwicklungsstadium. Die Tools sind bereits voll funktionsfähig und können in Testumgebungen mit unterstützten KI-Agenten (Claude Desktop, Cursor, VS Code Copilot, AnythingLLM) ausprobiert werden.

Was ist MCP?

Das Model Context Protocol (MCP) ist ein offener Standard, der es KI-Systemen ermöglicht, mit externen Tools zu kommunizieren. mjEdit implementiert einen vollständigen MCP-Server mit zwei Transport-Optionen:

• STDIO – Direkte Prozess-Kommunikation (Claude Desktop, Cursor, VS Code Copilot)
• SSE – HTTP Server-Sent Events auf localhost (AnythingLLM Docker, eigene Integrationen)

154 MCP-Tools — was bedeutet das in der Praxis?

Statt nur mit einem Editor zu reden, kann eine KI mit mjEdit arbeiten: Dateien anlegen, Inhalte umbauen, OSCAL-Dokumente generieren, Netzwerke passiv scannen, CVE-Schwachstellen prüfen, ganze Compliance-Dashboards steuern. Die folgenden Beispiele zeigen, wie sich das im Alltag anfühlt.

„Lege mir einen Grundschutz++-konformen Katalog an"

Sie diktieren der KI:

„Erstelle einen leeren OSCAL-Katalog mit dem Titel ‚BSI IT-Grundschutz++ Interne Basis 2026’, Version 1.0.0, Sprache de. Lege die drei Praktik-Gruppen ORP (Organisation und Personal), CON (Konzeption und Vorgehensweisen) und OPS (Betrieb) an, übernimm aus dem Master-Katalog kataloge/grundschutzpp-master.json die Controls ORP.4.A1, ORP.4.A8, CON.3.A1 und OPS.1.1.5.A1 mitsamt Statements, und speichere das Ganze als kataloge/internal-baseline-2026.json."

Im Hintergrund läuft eine Werkzeugkette ab, die Sie sonst von Hand zusammenklicken müssten:

1. oscal_create_catalog → leerer Katalog mit Metadaten (Titel, Version, last-modified, oscal-version: 1.2.2)
2. oscal_add_group (3×) → Gruppen ORP / CON / OPS mit BSI-konformen Titeln
3. oscal_query_get_control (4×) → Controls aus dem Master-Katalog lesen
4. oscal_add_control (4×) → Controls in die korrekte Gruppe einhängen
5. validate_oscal_document → Schema-Validierung gegen OSCAL v1.2.2
6. file_save_as → Speichern unter dem Wunschpfad

Sekunden später ist der Katalog im Tree-View sichtbar, im Katalog-Tab geöffnet und schema-validiert. Sie sehen nur das fertige Ergebnis – aber jedes Werkzeug ist im Tool-Log nachvollziehbar protokolliert.

„Aktualisiere alle Metadaten unserer 12 SSPs auf Version 2.1"

Eine Aufgabe, die manuell mindestens eine halbe Stunde fehleranfälliges Klicken bedeutet. Mit MCP genügt ein Satz:

„Öffne alle SSP-Dateien im Verzeichnis 030-SSP/, setze in den Metadaten version auf 2.1 und last-modified auf heute."

Im Hintergrund: file_list mit Glob-Pattern, je SSP oscal_update_metadata, dann file_save. Die GUI aktualisiert sich automatisch.

„Wo steht in unserem SSP etwas zu Backup?"

Statt durch 4.000 JSON-Zeilen zu scrollen:

„Suche im aktuellen SSP nach allen Erwähnungen von ‚Backup’ und ‚Datensicherung’ und zeige mir die zugehörigen Control-IDs."

oscal_search mit Regex liefert in Sekundenbruchteilen die Treffer mit Kontext, oscal_get_control ergänzt für jeden Treffer den vollständigen Control-Text. Die KI fasst zusammen: „Backup wird in AC-2, CP-9 und SI-12 erwähnt — möchten Sie eines davon im Editor öffnen?"

„Bau mir ein Prüfprotokoll als qFORM"

Sie beschreiben, was Sie brauchen — die KI baut das Formular:

„Erstelle ein qFORM-Prüfprotokoll mit den Feldern Prüfer, Datum, System-Name, einem Dropdown ‚Status’ (Offen / In Bearbeitung / Abgeschlossen) und einer Checkliste mit 10 Einträgen."

qform_create erzeugt die Struktur, qform_add_field setzt jedes Feld mit korrektem Widget-Typ, qform_render zeigt das Formular sofort im Form-Tab. Anschließend können Sie per qform_create_qc_script eine automatische Reifegrad-Berechnung einbetten lassen.

„Generiere die komplette Dokumentenkette für unseren neuen Server"

Der Klassiker — und das Paradebeispiel für execute_steps:

„Erstelle für den Server web-prod-04 ein Profil aus dem BSI-Katalog, daraus einen SSP mit unseren Standard-Komponenten, dann Assessment Plan, Assessment Results und POA&M. Speichere alles unter 040-Server/web-prod-04/."

Die KI bündelt bis zu 20 Tool-Aufrufe in einem einzigen Request: dir_create, oscal_generate_profile_from_catalog, oscal_generate_ssp_from_profile, oscal_generate_ap_from_ssp, oscal_generate_ar_from_ap, oscal_generate_poam_from_ssp, gefolgt von validate_oscal_document für jede Datei. Eine Anweisung — fünf validierte, miteinander verknüpfte OSCAL-Dokumente.

„Validiere, was wir gerade haben — und repariere wenn möglich"

Vor einem Audit-Termin oder einem Commit:

„Validiere alle OSCAL-Dateien im aktuellen Projektverzeichnis gegen das offizielle Schema und prüfe alle UUID-Referenzen."

file_list sammelt alle Kandidaten, validate_oscal_document und validate_oscal_references laufen über jede Datei. Die KI berichtet: „11 von 12 Dateien sind valide. In ssp-db.json verweist eine component-uuid ins Leere — soll ich die Referenz auf die naheliegendste Komponente korrigieren?"

„Mach unseren Bericht export-fertig"

Ein typischer Berichts-Workflow ohne Tool-Wechsel:

„Generiere ein Inhaltsverzeichnis für den aktuellen Markdown-Bericht, ergänze einen Footer mit Datum und Versionsnummer, und exportiere das Ergebnis als PDF nach berichte/."

markdown_get_toc, markdown_replace_section, markdown_export_to_pdf — und die fertige PDF erscheint im Datei-Tree.

„Erkenne alle Geräte im Netz und befülle das SSP-Inventar automatisch"

Bevor ein SSP mit Inventar befüllt werden kann, muss das Asset-Inventar bekannt sein. Das kostet normalerweise Stunden: Netzwerk-Tools starten, IPs und MACs notieren, JSON-Einträge tippen. Mit einem Satz:

„Lies den ARP-Cache meines Rechners aus, mappe alle gefundenen Geräte auf OSCAL-Inventar-Items und füge sie direkt in 030-SSP/ssp-main.json ein. Löse Hostnamen per Reverse-DNS auf."

Das Tool network_discover_passive fragt passiv den Betriebssystem-ARP/ND-Cache ab – ohne aktive Scans, ohne Pakete zu senden, ohne Administrator-Rechte:

1. network_discover_passive → liest OS-ARP-Cache → liefert IP, MAC, Hostname pro Gerät
2. Jeder Host wird als OSCAL-inventory-item mit UUID, ip-address-Prop und mac-address-Prop gemappt
3. oscal_ssp_upsert_inventory_item (n×) → Items werden in den SSP eingefügt (Duplikate werden automatisch übersprungen)
4. file_save → SSP gespeichert, GUI aktualisiert sich

Ergebnis: Das SSP-Inventar enthält sofort alle aktuell erreichbaren Geräte als schemavalide OSCAL-v1.2.2-Objekte. Was früher einen halben Tag kostete, dauert jetzt Sekunden.

„Scanne unsere Komponenten auf CVEs und erzeuge sofort eine POA&M"

Vor jedem Audit-Termin die eigenen Systeme gegen bekannte Schwachstellen zu prüfen und Befunde OSCAL-konform zu dokumentieren, war bisher ein mehrstündiger Prozess: NVD manuell abfragen, CPE-Strings formulieren, POA&M-Einträge anlegen. Mit MCP genügt:

„Scanne alle Komponenten in 030-SSP/ssp-main.json auf bekannte CVEs (Schweregrad mind. ‘high’), schreib die Befunde als POA&M-Items in 050-POAM/poam-main.json und hinterlege in jedem betroffenen Inventar-Eintrag eine Maßnahmen-Anmerkung."

Ablauf des Tools oscal_cve_scan:

1. Alle system-components und inventory-items aus dem SSP einlesen
2. Pro Komponente den CPE-String aus den OSCAL-Properties extrahieren und gegen die NVD-CVE-Datenbank abgleichen
3. Befunde nach CVSS-Schweregrad filtern (severity_min: "high")
4. oscal_poam_upsert_item (n×) → Für jeden Befund ein POA&M-Item mit Risk, Beschreibung und CVE-ID
5. Optional: annotate_ssp: true → CVE-Props und Maßnahmen-remarks direkt in SSP-Komponenten
6. Optional: ap_path → Prüf-Tasks zur Verifikation der Maßnahmen in den Assessment Plan

Ergebnis: Eine vollständige, OSCAL v1.2.2-konforme POA&M mit CVE-verknüpften Risiken – direkt aus Ihrem SSP-Inventar, in Minuten statt Stunden. Ein NVD-API-Schlüssel (Umgebungsvariable NVD_API_KEY) beschleunigt den Scan für große Inventare deutlich.

„Zeig mir den Compliance-Status aller Projekte – und exportiere einen Bericht"

Statt manuell jede OSCAL-Datei zu öffnen und den Status zu prüfen:

„Scanne alle OSCAL-Dokumente in ~/mein-projekt/ auf Compliance-Status und exportiere den Bericht als Markdown nach berichte/compliance-2026-06.md."

1. oscal_compliance_scan → Rekursiver Scan des Projektpfades – erkennt automatisch alle OSCAL-Dokumenttypen (Katalog, Profil, SSP, AP, AR, POA&M)
2. oscal_compliance_get_state → Vollständiger Scan-State: Dokumentanzahl, Typ-Verteilung, Validierungsstatus, Implementierungs-Coverage
3. oscal_compliance_set_filter → Optionale Filterung nach Typ oder Volltext (z. B. nur SSPs anzeigen)
4. oscal_compliance_export_markdown → Markdown-Bericht mit Tabellen, Fortschrittsbalken und offenen Punkten

Die KI kann den Bericht direkt kommentieren: „Von 47 Controls sind 38 als ‘implemented’ markiert — die 9 offenen liegen in den Kategorien SC und SI. Soll ich die Details im POA&M aufführen?"

„Setze präzise OSCAL-Werte – ohne das ganze Dokument neu aufzubauen"

Wenn nur ein einziger Implementierungsstatus aktualisiert oder eine neue Observation hinzugefügt werden soll, braucht die KI nicht das gesamte Dokument zu ersetzen. Die 27 OSCAL-Node-CRUD-Tools ermöglichen chirurgische Eingriffe:

„Setze in ssp-main.json für Control AC-2 den Implementierungsstatus auf implemented und füge in ar-main.json eine neue Observation hinzu: Prüfmethode EXAMINE, Titel AC-2 Review, Status satisfied."

mjEdit übersetzt das in zwei gezielte Operationen:

• oscal_ssp_upsert_implemented_requirement → Aktualisiert nur das implemented-requirement-Objekt für AC-2; alle anderen Controls bleiben unberührt
• oscal_ar_upsert_observation → Hängt die neue Observation ans observations-Array an – mit UUID, collected-Zeitstempel und schemakonformem relevant-evidence-Anker

Weitere typische Einzel-Operationen:

„Befülle den SSP aus unserer ISMS-Wissensbasis (RAG mit AnythingLLM)"

Hier kommt das volle Potenzial von MCP + RAG zum Tragen: In AnythingLLM ist Ihr ISMS-Korpus eingebettet – BSI IT-Grundschutz-Kompendium, eigene Sicherheitsleitlinien, Betriebshandbücher, frühere Risikoanalysen, Netzwerkdokumentation, Audit-Berichte aus den Vorjahren. mjEdit ist als MCP-Server angebunden. Sie sagen einmal:

„Befülle den leeren SSP ssp-web-prod-04.json für unseren neuen Linux-Webserver aus dem Profil profile-grundschutzpp-web.json. Recherchiere die Implementierungs-Beschreibungen pro Control aus unserer ISMS-Wissensbasis – speziell aus den Dokumenten ‚Betriebshandbuch Webserver v3.2’, ‚Härtungsleitlinie Linux 2025’ und ‚Patch-Management-Richtlinie’. Belege jede description mit Quellenangabe und mappe alle Verantwortlichen aus dem ‚Rollen-und-Verantwortlichkeiten-Katalog’ auf die responsible-roles der implemented-requirement-Einträge."

Was passiert dabei in zwei Welten gleichzeitig?

In AnythingLLM (RAG-Schicht):

1. Pro Control aus dem aufgelösten Profil (z. B. ORP.4.A1, OPS.1.1.5.A1, SYS.1.3.A14) führt die KI eine semantische Vektorsuche über die ISMS-Wissensbasis durch.
2. Die relevantesten Passagen werden mit Quellenangabe (Dokumentname, Seite/Abschnitt) zurückgegeben.
3. Die KI fasst pro Control die zutreffenden Implementierungs-Aussagen in einen OSCAL-tauglichen Satz zusammen – kein Halluzinieren, weil der Kontext ausschließlich aus Ihren echten ISMS-Dokumenten kommt.

In mjEdit (MCP-Schicht):

• oscal_query_get_control (n×) holt für jeden Control die Soll-Anforderung aus dem Profil.
• oscal_add_control legt pro Control einen implemented-requirement-Knoten an.
• editor_stream_append mit update_gui=true schreibt die aus dem RAG zurückgelieferte Beschreibung live in das description-Feld – Sie sehen den Text Satz für Satz im Editor erscheinen.
• oscal_add_property ergänzt die Quellenangabe als prop (name="evidence-source", value="Betriebshandbuch Webserver v3.2 §4.2") – nachvollziehbar für jeden Auditor.
• oscal_update_implementation_status setzt den Status (implemented, partial, planned) anhand der RAG-Befunde.
• oscal_add_role + Rollen-Zuweisung füllt responsible-roles aus dem Rollen-Katalog.
• gui_show_tab und gui_show_progress halten Sie über den Fortschritt auf dem Laufenden.
• validate_oscal_document schließt den Lauf mit einer Schema-Prüfung ab.

Warum das so wertvoll ist

• Kein Bauchgefühl, keine Halluzinationen: Jede Aussage im SSP ist über evidence-source-Properties auf eine konkrete Stelle in einem bei Ihnen liegenden Dokument zurückführbar – Audit-fest.
• Datensouveränität: AnythingLLM läuft on-premise, mjEdit läuft lokal, der MCP-Transport ist STDIO oder lokales SSE. Kein Compliance-Inhalt verlässt Ihr Haus.
• Wiederverwendbar: Für den nächsten Webserver web-prod-05 rufen Sie denselben Prompt auf – die KI nutzt dieselbe Wissensbasis und liefert in Minuten einen weiteren konsistenten SSP.
• Manuell wären das Tage: Pro Control ISMS-Dokumente aufschlagen, passende Stellen finden, formulieren, Quelle eintragen, Verantwortlichen zuweisen, ins JSON tippen – die KI macht genau das, parallel, in Minuten.

Kurz: AnythingLLM liefert das Wissen, mjEdit liefert die Werkzeuge – MCP ist die Brücke, die beides zu einem auditfähigen OSCAL-Dokument zusammenführt.

Editor-Operationen — als wäre die KI ein Kollege am Tastatur

Undo, Redo, Suchen & Ersetzen, Copy & Paste — die KI kann genau das tun, was Sie auch tun würden, nur schneller und reproduzierbar. Praktisch, wenn Sie die KI bitten: „Mach das letzte Replace rückgängig — das hat zu viel ersetzt."

Wie sich diese 154 Tools gruppieren

Damit klar ist, was unter der Haube steckt: Die Werkzeuge sind in 19 Kategorien organisiert — von Datei- und JSON-Operationen über Validierung und alle OSCAL-Lebenszyklus-Phasen (Erstellung, Abfrage, Bearbeitung, Control-Verwaltung, Generierung, Pydantic-Modell-API, Node-CRUD) bis hin zu Netzwerk-Discovery, CVE-Scan, Compliance-Dashboard, qFORM-Formularen, Markdown- und Editor-Steuerung, Template-Verwaltung und GUI-Kontrolle. Die KI wählt die richtigen Tools selbst — Sie beschreiben, was passieren soll.

22 MCP-Ressourcen

KI-Agenten können kontextuelle Informationen direkt abfragen, etwa:

• mjedit://schema/oscal/catalog – OSCAL Catalog Schema v1.2.2
• mjedit://schema/oscal/ssp – OSCAL SSP Schema v1.2.2
• mjedit://oscal/controls – Controls des aktuellen Dokuments
• mjedit://snippets/oscal – OSCAL-Snippets

15 MCP-Prompts für geführte Workflows

AnythingLLM – KI-Agent mit RAG-Wissensbasis

Während Claude Desktop, Cursor und VS Code Copilot als Cloud-basierte KI-Agenten leistungsfähige MCP-Integration bieten, nimmt AnythingLLM eine besondere Rolle ein: Als selbst gehostete Open-Source-Plattform kombiniert AnythingLLM die Fähigkeiten eines KI-Assistenten mit einer Retrieval-Augmented Generation (RAG)-Wissensbasis – vollständig unter Ihrer Kontrolle.

Was Sie als Wissensbasis einbetten können

• BSI IT-Grundschutz-Kompendium (PDF, 800+ Seiten)
• NIST SP 800-53 Kontrollen-Katalog
• Bestehende ISMS-Richtlinien und Verfahrensanweisungen
• Audit-Berichte vergangener Jahre
• OSCAL-Dokumente (JSON) aus mjEdit
• Technische Dokumentation Ihrer IT-Infrastruktur

MCP-Integration mit AnythingLLM

{
  "mcpServers": {
    "mjEdit": {
      "url": "http://localhost:8765/sse",
      "transport": "sse"
    }
  }
}

Vergleich: AnythingLLM vs. Cloud-KI-Agenten

Anwendungsfall: 8 Webserver in einem Aufruf

„Erstelle für meine 8 Webserver eine vollständige OSCAL-Dokumentkette auf Basis des BSI-IT-Grundschutz-Katalogs."

Die KI ruft oscal_generate_batch_tailored_chain auf, der MCP-Server erstellt für jeden Server ein Unterverzeichnis und generiert die vollständige Kette Profil → Component-Definition → SSP → AP → AR → POA&M. Die Inventardaten (Hostname, FQDN, IPv4/IPv6, MAC) werden als inventory_items pro Target übergeben; alles wird gegen OSCAL v1.2.2 validiert.

Ergebnis: 48 validierte OSCAL-Dokumente in einem Aufruf.