AI & MCP

Note: The MCP integration is in an early development stage. 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 lets AI systems talk to 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, your own integrations)

88 MCP tools — what does that mean in practice?

Instead of just talking to an editor, an AI can actually work with mjEdit: create files, transform content, generate OSCAL documents, run validations, drive entire tabs. The following examples show how this feels in everyday work.

“Create me a Grundschutz++ compliant catalog”

You tell the AI:

“Create an empty OSCAL catalog with the title ‘BSI IT-Grundschutz++ Internal Baseline 2026’, version 1.0.0, language de. Add the three practice groups ORP (Organisation and Personnel), CON (Concepts and Procedures) and OPS (Operations), import the controls ORP.4.A1, ORP.4.A8, CON.3.A1 and OPS.1.1.5.A1 including their statements from the master catalog catalogs/grundschutzpp-master.json, and save the result as catalogs/internal-baseline-2026.json.”

Behind the scenes a tool chain runs 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.1)
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×) → attach controls to the correct group
5. validate_oscal_document → schema validation against OSCAL v1.2.1
6. file_save_as → save to the requested path

Seconds later the catalog appears in the tree view, opens in the catalog tab and is schema-validated. You only see the finished result – but every tool call is fully traceable in the tool log.

“Bump the metadata of all 12 SSPs to version 2.1”

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

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

Behind the scenes: file_list with a glob pattern, oscal_update_metadata per SSP, then file_save. The GUI refreshes automatically.

“Where in our SSP do we say something about backup?”

Instead of scrolling through 4,000 lines of JSON:

“Search the current SSP for any mention of ‘backup’ or ‘data backup’ and show me the related control IDs.”

oscal_search with regex returns the matches with context in milliseconds, oscal_get_control adds the full control text for every hit. The AI summarises: “Backup is mentioned in AC-2, CP-9 and SI-12 — would you like to open one of them?”

“Build me an audit form as qFORM”

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

“Create a qFORM audit protocol with the fields auditor, date, system name, a ‘status’ dropdown (open / in progress / completed) and a 10-item checklist.”

qform_create builds the structure, qform_add_field adds every field with the correct widget type, qform_render shows the form immediately in the form tab. Optionally you can have qform_create_qc_script embed an automatic maturity-score calculation.

“Generate the full document chain for our new server”

The classic — and the textbook example for execute_steps:

“For the server web-prod-04 create a profile from the BSI catalog, then an SSP with our standard components, followed by Assessment Plan, Assessment Results and POA&M. Save everything under 040-Servers/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 instruction — five validated, interlinked OSCAL documents.

“Validate what we have — and fix it where possible”

Before an audit appointment or a commit:

“Validate every OSCAL file in the current project directory against the official schema and check all UUID references.”

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

“Make our report ready for export”

A typical reporting workflow without switching tools:

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

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

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

This is where the full power of MCP + RAG shows: in AnythingLLM your ISMS corpus is embedded – BSI IT-Grundschutz compendium, your own security policies, operations manuals, prior risk analyses, network documentation, audit reports from previous years. mjEdit is connected as an MCP server. You say once:

“Populate 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 for each control from our ISMS knowledge base – specifically from the documents ‘Web Server Operations Manual v3.2’, ‘Linux Hardening Guideline 2025’ and ‘Patch Management Policy’. Cite the source for every description and map all responsible owners from the ‘Roles and Responsibilities Catalog’ to the responsible-roles of the implemented-requirement entries.”

Two worlds working in parallel

In AnythingLLM (RAG layer):

1. For every control from the resolved profile (e.g. ORP.4.A1, OPS.1.1.5.A1, SYS.1.3.A14) the AI runs a semantic vector search across the ISMS knowledge base.
2. The most relevant passages are returned with citations (document name, page/section).
3. Per control the AI condenses the matching implementation statements into an OSCAL-ready sentence – no hallucinations, because the context comes exclusively from your real ISMS documents.

In mjEdit (MCP layer):

• oscal_query_get_control (n×) fetches the target requirement for each control from the profile.
• oscal_add_control creates an 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 adds the citation as a prop (name="evidence-source", value="Operations Manual Web Server v3.2 §4.2") – traceable for any auditor.
• oscal_update_implementation_status sets the status (implemented, partial, planned) based on the RAG findings.
• oscal_add_role plus role assignment fills responsible-roles from the role catalog.
• gui_show_tab and gui_show_progress keep you informed about the progress.
• validate_oscal_document closes 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 via evidence-source properties to a concrete spot in a document on your premises – audit-proof.
• Data sovereignty: AnythingLLM runs on-premise, mjEdit runs locally, the MCP transport is STDIO or local SSE. No compliance content ever leaves your house.
• Reusable: for the next web server web-prod-05 you call the same prompt – the AI uses the same knowledge base and produces another consistent SSP in minutes.
• Manually this would take days: opening ISMS documents per control, finding the relevant passages, phrasing them, recording the source, assigning the responsible role, typing it all into 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 both together into an audit-ready OSCAL document.

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

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

How those 88 tools are grouped

So you know what’s under the hood: the tools are organised in 15 categories — from file and JSON operations through validation and every OSCAL lifecycle phase (creation, querying, editing, control management, generation, Pydantic model API), all the way to qFORM forms, Markdown and editor control, template management and GUI control. The AI picks the right tools itself — you describe what should happen.

22 MCP resources

AI agents can directly query contextual information, e.g.:

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

15 MCP prompts for guided workflows

AnythingLLM – AI agent with a RAG knowledge base

While Claude Desktop, Cursor and VS Code Copilot are powerful cloud-based AI agents with MCP integration, AnythingLLM plays a special role: as a self-hosted open-source platform it combines the abilities 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 control catalog
• Existing ISMS policies and procedures
• 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 a single 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 per server and generates the full chain profile → component definition → SSP → AP → AR → POA&M. Inventory data (hostname, FQDN, IPv4/IPv6, MAC) is passed in as inventory_items per target; everything is validated against OSCAL v1.2.1.

Result: 48 validated OSCAL documents in a single call.