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 enables 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, convert content, generate OSCAL documents, passively discover network assets, scan for 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 version to 2.1 and last-modified to today in the metadata.”

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.

“Discover all devices on the network and fill the SSP inventory automatically”

Before an SSP can be populated with inventory, the asset inventory must be known. This normally costs hours: starting network tools, noting down IPs and MACs, typing JSON entries. With one sentence:

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

The tool network_discover_passive queries the operating system’s ARP/ND cache passively – no active scans, no packets sent, no administrator rights required:

1. network_discover_passive → reads OS ARP cache → returns IP, MAC, hostname per device
2. Each host is mapped as an 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 automatically skipped)
4. file_save → SSP saved, GUI updates

Result: The SSP inventory immediately contains all currently reachable 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”

Checking your own systems against known vulnerabilities before every audit date and documenting the findings in OSCAL was previously a multi-hour process: querying NVD manually, formulating CPE strings, creating POA&M entries. With MCP, one sentence is enough:

“Scan all components in 030-SSP/ssp-main.json for known CVEs (severity at least ‘high’), write the findings as POA&M items to 050-POAM/poam-main.json and add a remediation remark to each affected inventory entry.”

Workflow of the oscal_cve_scan tool:

1. Read all system-components and inventory-items from the SSP
2. For each component, extract the CPE string from the OSCAL properties and compare 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 remediation remarks directly in SSP components
6. Optional: ap_path → verification tasks for remediation measures appended to the Assessment Plan

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

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

Instead of manually opening every OSCAL file to check status:

“Scan all OSCAL documents in ~/my-project/ for compliance status and export the report as Markdown to reports/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 items

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

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

When only a single implementation status needs updating or a new observation needs adding, the AI doesn’t need to replace the entire document. The 27 OSCAL Node CRUD tools enable surgical changes:

“Set the implementation status of control AC-2 to implemented in ssp-main.json and add a new observation to ar-main.json: 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

Further typical single 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 together

To make it clear what’s under the hood: The tools are organized into 19 categories — from file and JSON operations to validation and all OSCAL lifecycle phases (creation, query, editing, control management, generation, Pydantic model API, Node CRUD) to network discovery, CVE scanning, compliance dashboard, qFORM forms, Markdown and editor control, template management and GUI control. The AI chooses the right tools itself — you describe what should happen.

22 MCP resources

AI agents can directly query contextual information, such as:

• mjedit://schema/oscal/catalog – OSCAL Catalog Schema v1.2.2
• mjedit://schema/oscal/ssp – OSCAL SSP Schema v1.2.2
• mjedit://oscal/controls – Controls of the current document
• mjedit://snippets/oscal – OSCAL snippets

15 MCP prompts for guided workflows

AnythingLLM – AI agent with RAG knowledge base

While Claude Desktop, Cursor and VS Code Copilot offer powerful MCP integration as cloud-based AI agents, AnythingLLM takes on a special role: As a self-hosted open source platform, AnythingLLM combines the capabilities of an AI assistant with a Retrieval-Augmented Generation (RAG) knowledge base - completely under your control.

What you can embed as a knowledge base

• BSI IT-Grundschutz Compendium (PDF, 800+ pages)
• NIST SP 800-53 Controls Catalog
• Existing ISMS guidelines and procedural instructions
• Audit reports from previous years
• OSCAL documents (JSON) from mjEdit
• Technical documentation of your IT infrastructure

MCP integration with AnythingLLM

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

Comparison: AnythingLLM vs. Cloud AI Agents

Use case: 8 web servers in one call

“Create a complete OSCAL document chain for my 8 web servers based on the BSI-IT-Grundschutz catalog.”

The AI ​​calls oscal_generate_batch_tailored_chain, the MCP server creates a subdirectory for each server and generates the complete chain Profile → Component Definition → SSP → AP → AR → POA&M. The inventory data (hostname, FQDN, IPv4/IPv6, MAC) is passed as inventory_items per target; everything is validated against OSCAL v1.2.2.

Result: 48 validated OSCAL documents in one call.