Insurance Claims Assistant

Ein MCP-Server für die automatisierte Verarbeitung von Kfz-Versicherungsansprüchen, gebaut mit TypeScript und der Anthropic Claude API.

Ich habe das nach einem Jahr Arbeit an Guidewire ClaimCenter bei AXA France entwickelt, wo ich die EDI-Broker-Flows (506/508/509) für die automatisierte Schadensöffnung und -änderung integriert habe. Die Geschäftslogik hier spiegelt wider, womit ich dort zu tun hatte – Entitätsextraktion, Schweregrad-Triage, Broker-Benachrichtigungen – aber implementiert mit LLMs statt statischer Regeln.

Der Kern ist eine Zwei-Modell-Validierungspipeline: Ein schnelles Modell klassifiziert, ein stärkeres Modell prüft und kann es überstimmen, bevor etwas versendet wird.

Was es tut

Drei Tools, die miteinander verkettet sind:

    ↓  analyze_claim_report
Structured ClaimData
    ↓  classify_claim_severity
Severity + judge verdict
    ↓  generate_broker_notification
Formal broker notification

Related MCP server: Claim Pilot MCP Server

Der Richter

Die Klassifizierung läuft über zwei Modelle.

Claude Haiku nimmt den strukturierten Anspruch und liefert einen Schweregrad plus einen Konfidenzwert und seine Begründung. Claude Sonnet erhält dann dieselben Anspruchsdaten zusammen mit Haikus Antwort und gibt ein Urteil zurück:

{
  "approved": false,
  "feedback": "Injuries confirmed in the report — AUTO_PROCESS is not applicable",
  "finalSeverity": "URGENT_ESCALATION"
}

Sonnet bittet Haiku nicht um einen erneuten Versuch. Es überschreibt direkt, und finalSeverity ist das, was die Pipeline nachgelagert verwendet. Der Richter hat immer das letzte Wort.

Der Grund, warum dieses Muster hier und nicht woanders billiger ist: Bei der Schadensbearbeitung ist eine Fehlklassifizierung kein kosmetischer Fehler. Ein URGENT_ESCALATION-Anspruch mit Verletzungen, der an AUTO_PROCESS weitergeleitet wird, bedeutet, dass jemand länger auf Hilfe wartet. Haiku ist billig genug, um bei jedem Anspruch zu laufen; Sonnet kostet mehr, läuft aber nur einmal, als Tor.

analyze_claim_report

Nimmt Rohtext eines Unfallberichts und liefert strukturiertes JSON: Fahrzeuge, Parteien, Schäden, Umstände, Zeugen.

Verwendet ein Agent-Skill-Muster – der Extraktions-Prompt lebt in einem eigenen Modul (skills/claim-extraction.skill.ts), anstatt im Tool inline zu sein.

classify_claim_severity

Klassifiziert einen Anspruch als AUTO_PROCESS, REVIEW_NEEDED oder URGENT_ESCALATION.

generate_broker_notification

Erzeugt ein formelles Benachrichtigungsschreiben für den Broker, mit den erforderlichen Maßnahmen basierend auf der Schweregrad-Klassifizierung.

Dieses sendet MCP-Fortschrittsbenachrichtigungen (1/3, 2/3, 3/3), damit der Client den Status in Echtzeit anzeigen kann.

Architektur

├── index.ts                       MCP server, tool registration
├── tools/
│   ├── analyze-claim.ts
│   ├── classify-claim.ts
│   └── generate-notification.ts
├── skills/
│   └── claim-extraction.skill.ts  Reusable prompt template
├── judge/
│   └── classification-judge.ts    Sonnet validates Haiku
├── utils/
│   ├── anthropic-client.ts        Shared SDK instance + model config
│   ├── logger.ts                  stderr logging
│   └── progress.ts                Progress notification helper
└── types/
    └── claim.types.ts

Ein paar Entscheidungen, die eine Erklärung wert sind

Logging geht an stderr, nicht an stdout. MCP-Server, die den stdio-Transport verwenden, reservieren stdout für JSON-RPC-Nachrichten. Ein versehentliches console.log korrumpiert das Protokoll und der Client bricht die Verbindung ab. Alles wird stattdessen an stderr geloggt.

Haiku überall außer beim Richter. Extraktion, Klassifizierung und Benachrichtigungserzeugung laufen alle auf Haiku. Sonnet läuft nur als Validator. Bei einem echten Schadensvolumen macht dieser Kostenunterschied etwas aus.

Fortschrittsbenachrichtigungen sind optional. Der Parameter sendProgressFn ist optional, damit das Tool auch mit Clients funktioniert, die keine Fortschrittsupdates unterstützen. Kein Client sollte abstürzen, nur weil er kein Fortschritts-Token gesendet hat.

Zod für Eingabevalidierung. Das MCP SDK verwendet Zod-Schemas, um Tool-Eingaben an der Servergrenze zu validieren, bevor irgendeine Geschäftslogik läuft. Es liefert auch typisierte Handler-Argumente gratis.

Einrichtung

Erfordert Node.js 18+ und einen Anthropic-API-Schlüssel.

git clone https://github.com/youssefmkb/insurance-claims-assistant
cd insurance-claims-assistant
npm install
cp .env.example .env    # add your API key
npm run build

Server starten:

node dist/index.js

Mit MCP Inspector testen:

npx @modelcontextprotocol/inspector node dist/index.js

Screenshots

Vom Server bereitgestellte Tools:

Entitätsextraktion aus einem rohen Unfallbericht:

Klassifizierung mit dem Richter-Urteil:

Broker-Benachrichtigung, mit Fortschrittsupdates unten rechts sichtbar:

Stack

Node.js, TypeScript, @modelcontextprotocol/sdk v4, Anthropic SDK (Haiku + Sonnet), Zod, stdio-Transport.

V2-Ideen

Dinge, die ich hinzufügen würde, wenn das weitergehen würde:

• Tatsächliche E-Mail-Zustellung – derzeit wird die Benachrichtigung erzeugt, aber nicht gesendet. Das Anbinden von SendGrid oder Nodemailer würde den Kreis schließen.

• Persistenz – Ansprüche sind heute zustandslos. Eine Datenbank würde es ermöglichen, einen Anspruch über seinen Lebenszyklus zu verfolgen, anstatt jeden Aufruf isoliert zu verarbeiten.

• MCP-Sampling – den Server bitten, Vervollständigungen vom Modell des Clients anzufordern, anstatt die API direkt aufzurufen.

• Remote-Transport – derzeit nur stdio. Streamable HTTP würde es bereitstellbar machen.

Autor

Youssef Mokhbi — github.com/youssefmkb · LinkedIn