Was der mzone-publisher als Naechstes bekommen koennte
Zwoelf neue Ideen aus dem 2026er Werkzeug-Oekosystem — jede auf die vorhandene Architektur zugeschnitten, keine aus Band 1
Datum
2026-09-04
Anlass
Addendum zu Band 1 — nur neue Quellen, Band 1 bleibt gueltig
Methode
Wie Band 1: keine Code-Uebernahme. Pro Quelle die tragende Idee, dann ein konkreter Zuschnitt mit Nennung der Klasse/Datei
Grundlage
Branch main, 39 MCP-Tools, Stand der Codebasis 2026-09-04
Was Band 1 abdeckt
Der erste Report (research-mzp-tool-integrationen)
hat 20 Ideen aus 18 fremden Projekten zugeschnitten — von Structurizr-Sichten ueber hybride Suche bis
MCP-resources. Diese bleiben gueltig; hier kommen keine Doppelungen. Zur Orientierung die Band-1-Landkarte:
Vier Bereiche, jede Idee im Band-1-Muster: Quelle → tragende Idee → Zuschnitt auf MZP.
Diagramm-Engine
Pikchr als weiterer Diagramm-Eingang
Pikchr Documentation · https://pikchr.org/
Pikchr als weitere textuelle Diagramm-DSL; die Implementierung ist eine einzelne abhaengigkeitsfreie C-Datei (0-clause BSD), laut Projekt sicher fuer internet-exponierte Anwendungen — passend zum serverseitigen Rendern von Agenten-Text.
Zugeschnitten auf MZP
Neuer Eingangs-Dialekt, der ein DiagramSpec erzeugt (Rolle analog DiagramSpecParser). Zwei Optionen: pikchr.c via JNI bzw. Foreign Function & Memory API (Java 21) einbetten und dessen eigenes SVG durchreichen, oder Java-Port mit voller MZP-Pipeline (Layout, Edge-Routing, SvgRenderer). Laut diagram/AGENTS.md wird ein neuer Typ an drei Stellen bekannt — TypeRendererRegistry, DiagramTypeSchemas (Capabilities-Ausgabe), DiagramBudgets (Limits) — fehlt eine, ist der Typ unsichtbar oder unbegrenzt.
Interaktive Perspektiven ueber einem einzigen Modell: benutzerdefinierte Views/Walkthroughs, zoombare Ebenen, interaktive Sequenzdarstellung — MZPs Viewer hat mit den gefuehrten Kapiteln (MZP-54) einen Ansatz davon.
Zugeschnitten auf MZP
DiagramSpec.views traegt heute maximal fuenf gefuehrte Kapitel mit focus-Knoten; das Ilograph-Muster erweitert das um benutzerdefinierte Perspektiven, Ebenen-Zoom (Uebersicht → Detail) und Walkthrough-Fluesse, die Kanten sequenziell hervorheben. Umsetzung im Viewer (DiagramPageRenderer) plus Schema-Erweiterung im DiagramSpec.
markwhen-artiger Text (Datumsformate, Bilder, Links, Orte) als Importformat fuer Timeline-/Gantt-artige Diagramme; der offene Parser liefert ein Textmodell, nur der Editor ist closed source.
Zugeschnitten auf MZP
Die Zieltypen existieren bereits — DiagramType.TIMELINE und GANTT samt Typ-Renderern. markwhen ist also kein Typ-Neubau, sondern ein Text-Import, der auf das kanonische DiagramSpec abbildet; danach laufen DiagramValidator und SvgRenderer unveraendert. Ehrlicher Aufwand: der Parser (TypeScript) muss portiert werden; der closed-source Editor bleibt aussen vor.
Der CLI-Modus des Inspectors ist ausdruecklich fuer Automation/CI gedacht; nach jedem Deploy smoke-testet er die MCP-Oberflaeche selbst — eine Luecke, die der Browser-Blick (publishArtifact-Render-Check) nicht abdeckt.
Zugeschnitten auf MZP
CI-Job nach jedem Deploy: Inspector-CLI gegen den MCP-Endpunkt (spring.ai.mcp.server in application.yml, Zugriff unter /mcp/**); tools/list gegen den erwarteten Katalog abgleichen (McpToolCatalog, 39 Tools — per @McpTool-Zaehlung verifiziert), dazu schreibfreie Probe-Calls (listPublishedPages, searchPages, backlogQuery, getCapabilities). Kein MZP-Code noetig — reine Pipeline-Ergaenzung.
Publizierte Wiki-Seiten und Report-Artefakte als docx/pdf/epub herunterladbar machen — Pandoc als Universalkonverter, Typst als schnelle PDF-Engine ohne LaTeX-Toolchain. (K3.2 + K3.1 zusammengezogen: Pandoc = Formatbreite, Typst = Satzqualitaet; Pandoc nutzt Typst nativ als PDF-Engine.)
Zugeschnitten auf MZP
Neuer Export-Endpunkt am WikiApiController: bodyMd aus KnowledgeQueryService holen, Pandoc serverseitig konvertieren (docx/epub), PDF ueber Pandoc mit Typst-Engine bzw. Typst direkt fuer hochwertige Layouts/Templates. Reiner Ausgangs-Pfad — Publish-/Serving-Pfade bleiben unberuehrt.
PDF/DOCX/PPTX u. a. in bodyMd verwandeln, damit Agenten vorhandene Dokumente als Wiki-Seiten publizieren koennen; Docling laeuft lokal (air-gapped) und bringt CLI, API-Server und MCP-Server mit.
Zugeschnitten auf MZP
docling-serve als lokales Import-Backend hinter einem neuen Import-Tool: Dokument → Markdown → neue Wiki-Seite ueber den bestehenden Publish-Pfad (ArtifactService fuer Bundles, WikiApiController fuers Ablegen). Die einheitliche DoclingDocument-Zwischenrepraesentation entspricht MZPs kanonischem-Modell-Denken.
Fehlende Pflicht-Metadaten per Formular nachfordern statt den Tool-Call mit Fehler abzubrechen; das flache Schema-Modell (String/Number/Boolean/Enum) deckt MZPs Metadatenfelder gut ab, das 3-Aktions-Modell (accept/decline/cancel) passt zu Freigaben.
Zugeschnitten auf MZP
In PublisherMcpTools/DiagramMcpTools vor dem Publish fehlende Pflichtfelder (Titel, Kategorie, Tags) per requestedSchema anfragen; decline/cancel bilden auf die bestehende strukturierte Fehler-/Notice-Kultur ab. Abhaengigkeit: Konsumenten-Clients muessen Elicitation unterstuetzen — deshalb nicht sofort.
MCP-Konfigurationen und Tool-Schemata generieren statt handpflegen: mcp-bridge-parser (MIT, laeuft lokal, loest $ref-Zyklen, Pre-Flight-Regeln) als Mechanismus-Muster, AnythingMCP als Governance-Muster (Audit-Log, Response-Shaping, RBAC). (K1.10 + K1.9 zusammengezogen: gleiche Stossrichtung REST/OpenAPI → MCP-Tools.)
Zugeschnitten auf MZP
Befund: MZP hat aktuell keine OpenAPI-Doku (kein springdoc im pom.xml, grep leer). Zwei Schritte: (1) springdoc ergaenzen ODER direkt aus dem McpToolCatalog generieren, der alle Tools samt inputSchemas kennt; (2) mcpServers-Konfigurationen fuer Fremdclients in der CI bauen, Muster sind die handgeschriebenen Tools (KnowledgeMcpTools). AnythingMCP nur als Muster, kein Code (AGPL-3.0).
Standardisierte Observability der Tool-Calls: Spans/Metriken mit mcp.*-Attributen (mcp.server.operation.duration, mcp.session.id, mcp.protocol.version) und Trace-Kopplung Agent ↔ Server ueber params._meta (SEP-414) statt HTTP-Headern.
Zugeschnitten auf MZP
Micrometer/OTel-Instrumentierung um die Tool-Aufrufe im McpToolCatalog bzw. in PublisherMcpTools; die _meta-Propagation verbindet den Agenten-Trace mit dem MZP-Span — Grundlage fuer Session-/Operations-Metriken der 39 Tools (per @McpTool-Zaehlung verifiziert). Die Konventionen stehen auf Development-Status, daher spaeter.
Der naechste Protokoll-Schritt (stateless Requests, per-Request-Capability-Negotiation, Extensions) kommt ueber die Spring-AI-Basis auf MZP zu; die Tasks-Extension (taskId, Polling, input_required, Mid-Flight-Input) passt auf MZPs langlaufende Publish-Pfade. (K1.1 + K1.8 zusammengezogen: Tasks ist eine der Extensions dieses Spec-Stands.)
Zugeschnitten auf MZP
PublishService/ArtifactService sind heute synchron langlaufend (Diagram-Rendering, Browser-Render-Checks, grosse Bundles) — als Tasks liefen sie mit Polling statt Client-Timeouts und input_required fuer Freigaben. Status „instabil/Extension" (Review-Vermerk F-1) und die Basis (Spring AI MCP via mzone-mcp-common) unterstuetzt die Extension noch nicht — deshalb beobachten, keine Umsetzungsplanung ableiten.
Strukturierte HTML-Qualitaets-Checks als Gate: Doctype, HTTPS, alt-Attribute sowie interne und externe Link-Checks — als Befundklassen statt als eigener Job.
Zugeschnitten auf MZP
Zwei Andockstellen: (1) im Browser-Blick nach validateArtifact/publishArtifact (ArtifactRenderChecker) als neue Befundklassen neben CONSOLE_ERROR/PAGE_EXCEPTION; (2) als lintWiki-Befundklasse fuer den Bestand — PublishService.lintWiki liefert heute Freshness, danglingLinks und unresolvedSuccessions. Sofort sind die lokalen Checks (Doctype, alt-Attribute, HTTPS-Erzwingung, interne Links) an beiden Stellen. Externe Link-Checks sind erst mittelfristig: sie brauchen Caching und Throttling (htmltest-Muster: refcache mit Ablaufzeit), sonst kosten sie Laufzeit und belasten die Zielhosts. Abgrenzung zu Band 1: dort war es ein reiner externer Link-Check-Job, hier ein mehrklassiges Qualitaets-Gate ueber alle publizierten Seiten.
Agent Skills Specification (agentskills.io) · https://agentskills.io/specification · Skills over MCP Working Group · https://modelcontextprotocol.io/community/working-groups/skills-over-mcp
MZP-Anleitungen („wie publiziere ich ein Diagramm", „wie lege ich ein Template an") als SKILL.md-Pakete neben den Wiki-Seiten veroeffentlichen — Progressive Disclosure (Metadaten → Anleitung → Referenzen) passt zu Konsumenten, die selbst Agenten sind. (K1.4 + K1.3 zusammengezogen: Format heute, Transport morgen.)
Zugeschnitten auf MZP
SKILL.md-Pakete (YAML-Frontmatter, optional scripts/references/assets) sind schlichte Datei-Bundles — ArtifactService/publishArtifact kann sie heute schon ausliefern; dazu ein Katalog-/Verlinkungsmuster ueber das Wiki (KnowledgeQueryService). Der Transport ueber das MCP-Protokoll bleibt offen und wird nur ueber die Working Group beobachtet.
Sortiert nach Wirkung geteilt durch Aufwand. „Sofort“ = eigenstaendig, wenige Tage. „Mittelfristig“ = einen Entwurf wert. „Spaeter“ = haengt an anderem oder an der MCP-Basis.
S1Sofort
P1 MCP-Inspector-CLI als CI-Smoke-Test und Q1 HTML-Qualitaets-Gate — beide eigenstaendig und ohne neue Abhaengigkeiten, wirksam in wenigen Tagen: ein CI-Job mit Probe-Calls gegen den bestehenden Katalog statt MZP-Code, dazu lokale Checks (Doctype, alt, HTTPS, interne Links) als neue Befundklassen.
M1Mittelfristig
D1 Pikchr als weiterer Diagramm-Eingang, D2 Perspektiven/Walkthroughs nach Ilograph-Muster, P2 Doku-Export ueber Pandoc mit Typst-Engine, M1 Elicitation Structured Forms fuer Publish-Tools, M2 Tool-Konfigurations-Generierung nach OpenAPI-Muster und Q2 Agent-Skills als Publishing-Format — sechs Zuschnitte auf vorhandene Pfade (Viewer, Wiki-Export, McpToolCatalog, ArtifactService), die einen Entwurf wert sind, aber mehr als wenige Tage kosten.
L1Spaeter
D3 markwhen als Importformat fuer Timeline/Gantt, P3 Docling als Import-Pfad fuer Fremddokumente und M3 OTel GenAI-SemConv fuer die MCP-Tools — haengen an Vorleistungen (Parser-Port, lokales Import-Backend) bzw. an Konventionen im Development-Status, deshalb erst nach den mittelfristigen Entwuerfen.
B1Beobachten
M4 Spec 2026-07-28: stateless + Tasks-Extension — die Spring-AI-Basis (mzone-mcp-common) traegt die Extension noch nicht und der Spec-Stand ist instabil, daher erst beobachten und keine Umsetzungsplanung ableiten.
Empfohlene Reihenfolge
Woche 1
P1, Q1 — zuerst, weil eigenstaendig: der CI-Smoke-Test schliesst die Testluecke um die MCP-Oberflaeche, das Qualitaets-Gate haertet jede weitere Veroeffentlichung.
Danach
D1, D2, P2, M1, M2, Q2 — sechs Entwuerfe auf vorhandene Pfade, sobald die Sofort-Gates stehen; M1 erst, wenn Konsumenten-Clients Elicitation unterstuetzen.
Spaeter
D3, P3, M3 — Vorleistungen zuerst (markwhen-Parser-Port, Docling-Import-Backend) bzw. SemConv im Development-Status; M4 bleibt Beobachtung, bis die MCP-Basis stateless + Tasks traegt.
Quellen
Idee
Projekt / Spec
Genutzte Idee
Fundort
D1
Pikchr Documentation
Pikchr-DSL als weiterer Diagramm-Eingang, einzelne sichere C-Datei
https://pikchr.org/
D2
Ilograph
Interaktive Perspektiven und Walkthroughs ueber einem Modell
https://www.ilograph.com/
D3
markwhen
markwhen-Text als Importformat fuer Timeline-/Gantt-Diagramme
https://github.com/mark-when/markwhen
P1
MCP Inspector
Inspector-CLI smoke-testet die MCP-Oberflaeche nach jedem Deploy
https://github.com/modelcontextprotocol/inspector
P2
Pandoc · Typst
Wiki-Seiten als docx/pdf/epub herunterladbar via Pandoc + Typst