AI & MCP

Note: The MCP integration is in early development. The tools are already fully functional and can be tried out in test environments with supported AI agents (Claude Desktop, Cursor, VS Code Copilot, AnythingLLM).

What is MCP?

The Model Context Protocol (MCP) is an open standard that allows AI systems to communicate with external tools. mjEdit implements a complete MCP server with two transport options:

• STDIO – Direct process communication (Claude Desktop, Cursor, VS Code Copilot)
• SSE – HTTP Server-Sent Events on localhost (AnythingLLM Docker, own integrations)

154 MCP tools – what does this mean in practice?

Instead of just talking to an editor, an AI can work with mjEdit: create files, rebuild content, generate OSCAL documents, passively scan networks, check CVE vulnerabilities, control entire compliance dashboards. The following examples show how this feels in everyday life.

“Create a catalog that complies with Grundschutz++”

You dictate to the AI:

“Create an empty OSCAL catalog with the title ‘BSI IT-Grundschutz++ Internal Basis 2026’, version 1.0.0, language de. Create the three practice groups ORP (organization and personnel), CON (concept and procedures) and OPS (operation), take them from the master catalog kataloge/grundschutzpp-master.json the controls ORP.4.A1, ORP.4.A8, CON.3.A1 and OPS.1.1.5.A1 including statements, and save the whole thing as kataloge/internal-baseline-2026.json."

A tool chain runs in the background that you would otherwise have to click together by hand:

1. oscal_create_catalog → empty catalog with metadata (title, version, last-modified, oscal-version: 1.2.2)
2. oscal_add_group (3×) → Groups ORP / CON / OPS with BSI-compliant titles
3. oscal_query_get_control (4×) → Read controls from the master catalog
4. oscal_add_control (4×) → Mount controls in the correct group
5. validate_oscal_document → Schema validation against OSCAL v1.2.2
6. file_save_as → Save under the desired path

Seconds later, the catalog is visible in the tree view, opened in the catalog tab and schema-validated. You only see the finished result - but every tool is clearly logged in the tool log.

“Update all metadata of our 12 SSPs to version 2.1”

A task that requires at least half an hour of error-prone clicking manually. With MCP, one sentence is enough:

“Open all SSP files in the 030-SSP/ directory, set the metadata version to 2.1 and last-modified to today.”

In the background: file_list with glob pattern, each SSP oscal_update_metadata, then file_save. The GUI updates automatically.

“Where does our SSP say anything about backup?”

Instead of scrolling through 4,000 lines of JSON:

“Search the current SSP for all mentions of ‘backup’ and ‘data backup’ and show me the associated control IDs.”

oscal_search with Regex delivers the hits with context in a fraction of a second, oscal_get_control adds the complete control text for each hit. The AI summarizes: “Backup is mentioned in AC-2, CP-9 and SI-12 — would you like to open any of them in Notepad?”

“Build me a test report as qFORM”

You describe what you need — the AI builds the form:

“Create a qFORM audit report with the fields auditor, date, system name, a dropdown ‘Status’ (Open / In Progress / Completed) and a checklist with 10 entries."

qform_create creates the structure, qform_add_field sets each field with correct widget type, qform_render immediately shows the form in the form tab. You can then embed an automatic maturity level calculation using qform_create_qc_script.

“Generate the complete document chain for our new server”

The classic — and the prime example of execute_steps:

“Create a profile for the server web-prod-04 from the BSI catalog, an SSP with our standard components, then assessment plan, assessment results and POA&M. Save everything under 040-Server/web-prod-04/.”

The AI bundles up to 20 tool calls into a single 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, followed by validate_oscal_document for each file. One statement — five validated, linked OSCAL documents.

“Validate what we have right now — and fix if possible”

Before an audit date or a commit:> “Validate all OSCAL files in the current project directory against the official schema and check all UUID references.”

file_list collects all candidates, validate_oscal_document and validate_oscal_references run over each file. The AI reports: “11 out of 12 files are valid. In ssp-db.json a component-uuid points to nothing - should I correct the reference to the most obvious component?”

“Get our report ready for export”

A typical reporting workflow without changing tools:

“Generate a table of contents for the current Markdown report, add a footer with the date and version number, and export the result as a PDF to berichte/.”

markdown_get_toc, markdown_replace_section, markdown_export_to_pdf — and the finished PDF appears in the file tree.

“Detect all devices on the network and automatically populate the SSP inventory”

Before an SSP can be populated with inventory, the asset inventory must be known. This usually takes hours: starting network tools, writing down IPs and MACs, typing JSON entries. In one sentence:

“Read the ARP cache of my computer, map all found devices to OSCAL inventory items and insert them directly into 030-SSP/ssp-main.json. Resolve hostnames via reverse DNS.”

The network_discover_passive tool passively queries the operating system ARP/ND cache - without active scans, without sending packets, without administrator rights:

1. network_discover_passive → reads OS ARP cache → provides IP, MAC, hostname per device
2. Each host is mapped as OSCAL-inventory-item with UUID, ip-address-Prop and mac-address-Prop
3. oscal_ssp_upsert_inventory_item (n×) → Items are inserted into the SSP (duplicates are automatically skipped)
4. file_save → SSP saved, GUI updates

Result: The SSP inventory immediately contains all currently accessible devices as schema-valid OSCAL v1.2.2 objects. What used to take half a day now takes seconds.

“Scan our components for CVEs and immediately generate a POA&M”

Before each audit appointment, checking your own systems against known vulnerabilities and documenting the findings in an OSCAL-compliant manner was previously a process that took several hours: manually querying NVD, formulating CPE strings, creating POA&M entries. With MCP it is enough:

“Scan all components in 030-SSP/ssp-main.json for known CVEs (severity level at least ‘high’), write the findings as POA&M items in 050-POAM/poam-main.json and store an action note in each affected inventory entry."

Process of the tool oscal_cve_scan:

1. Read in all system-components and inventory-items from the SSP
2. Extract the CPE string from the OSCAL properties for each component and compare it against the NVD CVE database
3. Filter findings by CVSS severity (severity_min: "high")
4. oscal_poam_upsert_item (n×) → For each finding a POA&M item with risk, description and CVE ID
5. Optional: annotate_ssp: true → CVE Props and Measures remarks directly in SSP components
6. Optional: ap_path → Check tasks for verifying the measures in the assessment plan

Result: A complete, OSCAL v1.2.2 compliant POA&M with CVE-linked risks - directly from your SSP inventory, in minutes not hours. An NVD API key (environment variable NVD_API_KEY) significantly speeds up scanning for large inventories.

“Show me the compliance status of all projects – and export a report”

Instead of manually opening each OSCAL file and checking the status:

“Scan all OSCAL documents in ~/mein-projekt/ for compliance status and export the report as Markdown to berichte/compliance-2026-06.md.”

1. oscal_compliance_scan → Recursive scan of the project path - automatically detects all OSCAL document types (catalog, profile, SSP, AP, AR, POA&M)
2. oscal_compliance_get_state → Full scan state: document count, type distribution, validation status, implementation coverage
3. oscal_compliance_set_filter → Optional filtering by type or full text (e.g. only show SSPs)
4. oscal_compliance_export_markdown → Markdown report with tables, progress bars and open points

The AI can comment directly on the report: “Of 47 controls, 38 are marked as ‘implemented’ - the 9 open ones are in the SC and SI categories. Should I list the details in the POA&M?”

“Set precise OSCAL values – without rebuilding the entire document”

If only a single implementation status needs to be updated or a new observation needs to be added, the AI does not need to replace the entire document. The 27 OSCAL Node CRUD tools enable surgical interventions:> “In ssp-main.json, set the implementation status to implemented for control AC-2 and add a new observation in ar-main.json: test method EXAMINE, title AC-2 Review, status satisfied.”

mjEdit translates this into two targeted operations:

• oscal_ssp_upsert_implemented_requirement → Updates only the implemented-requirement object for AC-2; all other controls remain untouched
• oscal_ar_upsert_observation → Appends the new observation to the observations array - with UUID, collected timestamp and schema-compliant relevant-evidence anchor

Other typical individual operations:

“Fill the SSP from our ISMS knowledge base (RAG with AnythingLLM)”

This is where the full potential of MCP + RAG comes into play: Your ISMS corpus is embedded in AnythingLLM - BSI IT-Grundschutz compendium, own security guidelines, operating manuals, previous risk analyses, network documentation, audit reports from previous years. mjEdit is connected as an MCP server. You say once:

“Fill the empty SSP ssp-web-prod-04.json for our new Linux web server from the profile profile-grundschutzpp-web.json. Research the implementation descriptions per control from our ISMS knowledge base - specifically from the documents ‘Operating Manual Web Server v3.2’, ‘Hardening Guideline Linux 2025’ and ‘Patch Management Guideline’. Support each description with a source and folder all responsible persons from the ‘Roles and Responsibilities Catalog’ to the responsible-roles of the implemented-requirement entries."

What happens in two worlds at the same time?

In AnythingLLM (RAG layer):

1. Per control from the resolved profile (e.g. ORP.4.A1, OPS.1.1.5.A1, SYS.1.3.A14), the AI performs a semantic vector search over the ISMS knowledge base.
2. The most relevant passages are returned with source (document name, page/section).
3. The AI ​​summarizes the relevant implementation statements for each control into an OSCAL-compatible sentence - no hallucinating because the context comes exclusively from your real ISMS documents.

In mjEdit (MCP layer):

• oscal_query_get_control (n×) fetches the target request from the profile for each control.
• oscal_add_control creates one implemented-requirement node per control.
• editor_stream_append with update_gui=true writes the description returned from the RAG live into the description field - you see the text appear sentence by sentence in the editor.
• oscal_add_property supplements the source information as prop (name="evidence-source", value="Betriebshandbuch Webserver v3.2 §4.2") - comprehensible for every auditor.
• oscal_update_implementation_status sets the status (implemented, partial, planned) based on the RAG findings.
• oscal_add_role + Role assignment fills responsible-roles from the role catalog.
• gui_show_tab and gui_show_progress keep you updated on progress.
• validate_oscal_document completes the run with a schema check.

Why this is so valuable

• No gut feeling, no hallucinations: Every statement in the SSP can be traced back to a specific location in a document you have via evidence-source properties - audit-proof.
• Data sovereignty: AnythingLLM runs on-premise, mjEdit runs locally, the MCP transport is STDIO or local SSE. No compliance content leaves your home.
• Reusable: For the next web server web-prod-05, call the same prompt - the AI uses the same knowledge base and delivers another consistent SSP in minutes.
• Manually that would be days: Open Pro Control ISMS documents, find suitable positions, formulate them, enter the source, assign the person responsible, type into the JSON - the AI ​​does exactly that, in parallel, in minutes.

In short: AnythingLLM provides the knowledge, mjEdit provides the tools - MCP is the bridge that brings the two together into an auditable OSCAL document.

Editor operations — as if the AI were a colleague at the keyboard

Undo, redo, search & replace, copy & paste — the AI can do exactly what you would do, only faster and reproducibly. Handy if you ask the AI: “Undo the last replace - that replaced too much.”

How these 154 tools group togetherDamit 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.