Zurück zum Blog

WebMCP für Softwareprodukte: Websites für KI-Agenten vorbereiten

AIAPI DesignSoftware ArchitectureGovernance

KI-Agenten bedienen Webanwendungen heute oft wie Menschen: Sie lesen Seiten, interpretieren Formulare und simulieren Klicks. Das funktioniert bei einfachen Abläufen, wird aber bei dynamischen Oberflächen, mehrstufigen Prozessen und kritischen Aktionen unzuverlässig. WebMCP soll Websites deshalb strukturierte Werkzeuge bereitstellen lassen, die Browser-Agenten direkt verstehen und ausführen können.

Was WebMCP für Webanwendungen verändert

WebMCP ist ein vorgeschlagener Webstandard, kein fertiger Ersatz für APIs. Eine Seite registriert Aktionen mit Namen, Beschreibung und JSON Schema im Browser. Ein Agent kann diese Tools erkennen und im sichtbaren Seitenkontext aufrufen, statt sich durch DOM-Strukturen und wechselnde Buttons zu arbeiten.

Der Ansatz ergänzt klassische Backend-Integrationen:

  • Gemeinsamer Kontext: Nutzer, Agent und Anwendung arbeiten mit derselben angemeldeten Sitzung und demselben sichtbaren Zustand.
  • Explizite Aktionen: Ein Tool wie filter_orders oder prepare_refund beschreibt den fachlichen Zweck statt nur ein UI-Element.
  • Weniger fragile Automation: Strukturierte Eingaben ersetzen einen Teil der Screenshot-Auswertung und Klicksimulation.
  • Progressive Erweiterung: Die menschliche Oberfläche bleibt bestehen und erhält eine zusätzliche Interaktionsschicht für Agenten.

WebMCP befindet sich noch in einer frühen Phase. Der Entwurf wird in der W3C Web Machine Learning Community Group entwickelt und in Chrome experimentell erprobt. Teams sollten daher lernen und prototypisieren, aber noch keine kritische Produktstrategie von stabiler Browserunterstützung abhängig machen.

Wo Teams mit WebMCP anfangen sollten

Ein guter Pilot ist ein häufiger, klar begrenzter Ablauf mit sichtbarem Ergebnis, etwa Supportdaten erfassen, Suchfilter setzen oder einen Entwurf vorbereiten. Finanzielle Transaktionen, Rechteänderungen und unwiderrufliche Aktionen sind schlechte Startpunkte.

Ein einfaches Tool kann vorhandene Frontend-Logik wiederverwenden:

await document.modelContext.registerTool({
  name: "prepare_refund",
  description: "Prepare a refund for review without submitting it",
  inputSchema: {
    type: "object",
    properties: { orderId: { type: "string" } }, required: ["orderId"]
  },
  execute: ({ orderId }) => openRefundDraft(orderId)
})

Die Tool-Beschreibung ist aber keine Sicherheitsgrenze. Das Backend muss Autorisierung, Mandantentrennung, Eingabevalidierung, Idempotenz und Audit-Logs weiterhin selbst durchsetzen.

Vor einem Pilot sollten Teams konkret klären:

  • Tool-Schnitt: Kleine, fachlich eindeutige Aktionen sind besser prüfbar als ein allgemeines execute_task.
  • Freigaben: Entwurf, Vorschau und endgültige Ausführung brauchen getrennte Rechte und sichtbare Bestätigung.
  • Fehlerverhalten: Der Agent benötigt strukturierte, handlungsleitende Fehler statt nur Meldungen für Menschen.
  • Messung: Erfolgsquote, Abbrüche, falsche Tool-Aufrufe und manuelle Korrekturen zeigen, ob der Ablauf wirklich robuster wird.
  • Fallback: Die Webanwendung muss ohne WebMCP vollständig nutzbar bleiben, solange Browserunterstützung und Spezifikation nicht stabil sind.

Warum das wichtig ist

WebMCP macht die Agentenfähigkeit einer Website zu einer bewussten Produkt- und Architekturentscheidung. Wer strukturierte Aktionen anbietet, kann Supportaufwand und Bedienfehler senken. Wer lediglich bestehende Frontend-Funktionen ungeprüft als Tools freigibt, schafft neue Pfade zu sensiblen Geschäftsprozessen.

Für technische Entscheider liegt der wirtschaftliche Wert deshalb nicht im neuen Protokoll selbst. Er entsteht, wenn ein klarer Nutzerprozess mit weniger Schritten, weniger Fehlversuchen und nachvollziehbaren Freigaben abgeschlossen wird. Eine Architecture & AI Review kann klären, welche Abläufe sich für einen WebMCP-Pilot eignen und welche Backend-Grenzen vorher belastbar werden müssen.