Drei Moonshots
für den MZP

Seiten, die sich bedienen lassen

WebMCP macht eine Webseite selbst zu einem MCP-Server im Browser. Der MZP hat bereits den Weg in den Chat gebaut. Das hier wäre die Gegenrichtung.

Wie es aussähe

// /lib/webmcp-bridge@1.0.0/bridge.js – vom Server in jede Diagramm-Seite gehängt
const mc = document.modelContext ?? navigator.modelContext;   // Umbenennung Chrome 150
if (mc?.registerTool) {
  mc.registerTool({
    name: 'diagram.findPath',
    description: 'Kürzester Weg zwischen zwei Knoten dieses Diagramms, mit Hervorhebung.',
    inputSchema: { type: 'object', properties: { from: {type:'string'}, to: {type:'string'} },
                   required: ['from','to'] },
    async execute({ from, to }) {
      const path = graph.shortestPath(from, to);          // aus dem eingebetteten Modell
      document.dispatchEvent(new CustomEvent('dv:mark', { detail: path.nodes }));
      return { content: [{ type: 'text', text: path.describe() }] };
    }
  });
}

Der eigentliche Moonshot ist ein Tutor-Modus. Jemand öffnet einen Architektur-Report und fragt den Agenten seines Browsers: „Was passiert, wenn der Cache ausfällt?“ Der Agent ruft diagram.findPath und diagram.step auf. Der Leser sieht, wie der Viewer den Pfad Knoten für Knoten hervorhebt. Ein selbst geschriebener Erklärtext ist dafür nicht nötig. Die Seite erklärt sich mit dem Modell, das gerade im Browser läuft.

Erster Schritt

1. Spike, eine Woche: bridge.js von Hand geschrieben wie chat-bridge.js, ohne npm-Abhängigkeit. Vier Werkzeuge nur im Diagramm-Viewer.
2. Gegen Chrome Canary mit Flag und gegen ein Test-Harness prüfen, das getTools() und executeTool() aufruft. Das Harness kommt als Testfall in die Suite.
3. getCapabilities() nennt die angebotenen Werkzeuge je Seitentyp. Damit weiß ein MCP-Agent, was ein Browser-Agent später auf der Seite vorfindet.

Diagramme für alle Sinne

Barrierefreie Visualisierung ist bisher für Balken und Punkte gelöst, nicht für Graphen. Der MZP besitzt den Graphen und muss nicht vom Pixel ausgehen.

Warum es mehr ist als eine Pflichtübung

Der heutige Viewer setzt einige aria-expanded und aria-pressed, ist aber nicht strukturell navigierbar. Mit dem axe-Lauf (a11y: true, E9) misst der MZP die Zugänglichkeit bereits. Das wäre der Schritt vom Messen zur Fähigkeit. Daraus ergibt sich ein Ziel, das man ehrlich prüfen kann: Eine blinde Person erschließt ein Architekturdiagramm in derselben Zeit wie eine sehende. Der Klang verbindet das Thema außerdem mit den Wettbewerbswerken (niemand-stimmt, wer-a-sagt), in denen der MZP schon mit Klang arbeitet.

Erster Schritt

1. DiagramAccessTree in application/support/diagram/ erzeugen: ein Record-Baum aus dem Layout-Modell, als <ul role="tree"> neben dem SVG ausgeliefert. Kein neues Paket. MAIDR und Olli dienen als Vorbild für die Bedienung, nicht als Abhängigkeit.
2. Tastaturpfad im Viewer und dv:mark als Fokusanzeige wiederverwenden. Eine neue Ratsche hält fest, dass jeder Knoten im Baum vorkommt.
3. Hörgraph als Opt-in-Schalter mit Web Audio. Danach eine Probe mit zwei Screenreader-Nutzern. Ohne diese Probe bleibt es eine Vermutung.

Der Herkunftspass

Jede Seite auf dem MZP wurde von einem Agenten gebaut. Der Publisher hält fest, wer, wann, womit und auf welchem Stand, und kann das signieren.

Wie es aussähe

• Beim Publish erzeugt der Server ein Manifest je Bundle (Hash aller Dateien, Zutaten, Handlungen, Prüfungen) und signiert es mit einem maierzone-Schlüssel samt Zeitstempel. Ausgeliefert wird es als manifest.c2pa neben index.html und per <link rel="c2pa-manifest"> verknüpft.
• Sichtbar wird es als kleiner „Werkstattpass“ in der Ecke: Wer hat die Seite gebaut, aus welchen Zutaten, wie oft wurde sie geändert, was wurde geprüft. Das ist zugleich die sichtbare Kennzeichnung, die der Code als zweite Säule neben der maschinenlesbaren vorsieht.
• Prüfbar wird es über ein neues Tool verifyArtifact(slug) und über jeden C2PA-Verifier.

Der eigentliche Moonshot ist reproduzierbares Publizieren. Weil die Diagramm-Quelle als Zutat signiert ist, kann jeder nachprüfen, dass das SVG wirklich aus genau dieser Quelle mit genau dieser Engine-Version entstanden ist. Der Publisher bestätigt also nicht nur, dass ein Agent die Seite gemacht hat, sondern auch, wie sie entstanden ist.

Erster Schritt

1. Spike: Kann ein Java-Dienst C2PA-Manifeste schreiben? Kandidaten sind die Rust-Referenz c2pa-rs über deren C-Bindung oder c2patool als Sidecar im Container. Das ist offen und muss zuerst geprüft werden.
2. Wichtige Stolperstelle: Der MZP ergänzt index.html beim Ausliefern um canonical- und og:-Tags. Eine harte Bindung über Bytes erfordert, dass das ausgelieferte Dokument signiert wird. Die Kopf-Injektion muss also vor dem Signieren passieren, nicht beim Abruf.
3. Ohne C2PA-Bibliothek vorziehbar: ein JSON-Herkunftsprotokoll je Version (Zutaten, Handlungen, Prüfungen) als eigene Spalte und ein Werkstattpass-Overlay. Die Signatur kommt dann darauf.