KI-Agenten (MCP)

Ein KI-Agent wie Claude bedient OMDS LD über das Model Context Protocol (MCP). Er bekommt die Operationen der OpenAPI-Datei als Werkzeuge und arbeitet einen Vorgang ab, indem er den Folgeschritten der Antworten folgt. Ein eigenes Zustandsmodell braucht er dafür nicht.

Umsetzungsstand: Der MCP-Server ist eine Referenzimplementierung. Der Beispielserver betreibt einen je Beispielversicherer.

Ein Server je Versicherer, dieselbe Software

Jeder Versicherer hat seinen eigenen MCP-Server, so wie seine eigene Schnittstelle. Alle sind dieselbe Software: der MCP-Server der Norm vor der Schnittstelle des jeweiligen Versicherers. Er enthält nichts, was nur für einen Versicherer gilt.

Was Woher

Werkzeuge, ihre Namen, Beschreibungen und Eingaben

aus der OpenAPI-Datei der Norm, gleich für alle Versicherer

ob es die Werkzeuge des Entwurfs gibt

aus dem Prozesswissen des Versicherers (readProcessKnowledge, pk:draftAtServer)

Produkte, Bausteine, Attribute, Prämien

aus den Antworten des Versicherers

Adresse der Schnittstelle, Anzeigename

aus der Konfiguration der Instanz

Für einen weiteren Versicherer genügt eine weitere Instanz mit der Adresse seiner Schnittstelle. Betreiben kann sie der Versicherer selbst, neben seiner Schnittstelle über HTTP. Ebenso kann ein Vermittler oder sein Softwarehaus sie lokal vor der Schnittstelle eines Versicherers betreiben.

Sind mehrere Server registriert, ruft der Agent dieselben Werkzeuge bei mehreren Versicherern auf, etwa für einen Vergleich. Der Client unterscheidet sie über den Namen des Servers.

Werkzeuge

  • Ein Werkzeug je Operation. Der Name ist die operationId, dieselbe, die die Antworten in den Folgeschritten (bc:operation) nennen. Die Beschreibung stammt aus der OpenAPI-Datei.

  • Eingaben.

    • die Pfad- und Query-Parameter der Operation, etwa caseId, product, date;

    • body: das Request-Schema der Operation in der kanonischen Form. @context und @type ergänzt der Server, wenn sie fehlen. Den Body prüft er vor dem Aufruf gegen das Schema.

    • idempotencyKey (optional) bei Operationen mit Idempotency-Key: Ein zweiter Aufruf mit demselben Schlüssel erhält die Antwort des ersten und ändert nichts.

    • full (optional): zusätzlich die vollständige JSON-LD-Antwort des Versicherers.

  • Entwurf am Server. Die Erzeugung, die Bearbeitungen und die Auskünfte am Geschäftsobjekt bietet der Server nur an, wenn der Versicherer den Entwurf am Server hält. Sonst rechnet der Agent über die Tarifauskunft (inquireTariff) mit einer vollständigen Instanz.

  • Verdichtete Antworten. Statt des vollständigen Graphen erhält das Modell:

    • den Geschäftsfall;

    • den Entwurf als Baum mit den IRIs seiner Knoten und den Bausteinen, die sich einschließen lassen;

    • die Attribute mit Wert und erlaubtem Bereich;

    • die Risikoobjekte und den Prüfbericht;

    • die Prämie;

    • die Folgeschritte als „Werkzeug · bc:target · erwartete Shapes“;

    • die Felder der Shapes, die ein Folgeschritt erwartet, etwa die eines Fahrzeugs.

  • Fehler sind Werkzeugfehler mit dem Problemtyp der Norm, der Erklärung und den Operationen, die noch zulässig sind. Eine abgelehnte Anfrage ändert nichts.

Einrichtung

Im Beispielserver hat jeder Beispielversicherer seinen MCP-Server unter https://kapdion.com/omds-ld/insurers/<name>/mcp, über Streamable HTTP. In Claude Code:

claude mcp add --transport http disrupto https://kapdion.com/omds-ld/insurers/disrupto/mcp
claude mcp add --transport http angloamerican https://kapdion.com/omds-ld/insurers/angloamerican/mcp
claude mcp add --transport http pfefferminzia https://kapdion.com/omds-ld/insurers/pfefferminzia/mcp

Ohne eigenen Client: Im Chatbot unter https://chatbot.kapdion.com sind die MCP-Server der drei Beispielversicherer eingebunden.

Lokal vor einer Schnittstelle startet der Server als Prozess über stdio:

claude mcp add pfefferminzia -- node reference/mcp-server/dist/index.js --stdio --api http://localhost:9092/omds-ld/api --name Pfefferminzia

In Claude Desktop steht derselbe Aufruf in der Konfigurationsdatei unter mcpServers, mit command (node) und args.

Beispiel

Auftrag an den Agenten: „Berechne bei Pfefferminzia die Kfz-Versicherung für einen Skoda, Baujahr 2021, 110 kW, Listenpreis 32 000 Euro, Kennzeichen W-12345A.“

  1. listProducts – das Produkt Kraftfahrt 2025.

  2. createCalculation mit p:hasRootProduct – der Geschäftsfall mit der Default-Instanz als Entwurf. Unter den Folgeschritten steht createRiskObject mit den Shapes des Fahrzeugs.

  3. createRiskObject mit dem Fahrzeug – das Risikoobjekt ist angelegt und der Instanz zugeordnet.

  4. calculatePremium – der Entwurf ist vollständig, die Antwort nennt die Prämie.

Der Agent hat dabei keinen Ablauf gekannt. Jeder Schritt stand in der Antwort davor.

Bei einem Versicherer ohne Entwurf am Server, etwa Disrupto, führen die Folgeschritte über die Tarifauskunft:

  1. listProducts – das Produkt Kraftfahrt 2022 mit dem Folgeschritt readDefaultInstance.

  2. readDefaultInstance – die Default-Instanz als fertiger Body der Tarifauskunft. Der Folgeschritt inquireTariff nennt die Shapes des Fahrzeugs.

  3. inquireTariff mit diesem Body und dem Fahrzeug als weiterem Knoten – die Antwort nennt die Prämie.

Prüfen mit Szenarien

Ob ein Agent einen Vorgang allein mit den Werkzeugen und den Folgeschritten abschließt, prüft ein Szenario. Es besteht aus einem Auftrag in natürlicher Sprache, dem MCP-Server eines Versicherers und festen Kriterien. Ein Lauf ergibt ein Protokoll aller Werkzeugaufrufe mit ihren Ergebnissen, Token und Kosten.

Ein Lauf ist bestanden, wenn

  • eine Antwort eine Prämie mit konformem Prüfbericht enthält,

  • der Agent nur Bearbeitungen aufgerufen hat, die eine vorige Antwort als Folgeschritt angeboten hat,

  • jede IRI seiner Eingaben vorher im Auftrag, in einer Werkzeugbeschreibung oder in einer Antwort stand,

  • die Schlussantwort jede Annahme nennt, die der Agent ohne Angabe im Auftrag getroffen hat, etwa den Zulassungsbezirk,

  • die Schlussantwort die Prämie richtig wiedergibt

  • und der Lauf ein festes Budget nicht überschreitet.

Die Bewertung braucht kein Modell; sie liest das Protokoll. Weil ein Modell nicht bei jedem Lauf wörtlich gleich antwortet, zählt die Quote der bestandenen Läufe über mehrere Läufe. Der Agent bekommt nur eine knappe Anweisung ohne Wissen über Ablauf, Produkte oder Vokabular. Ein Szenario prüft damit die Norm und nicht die Anweisung.