Insurance Claims Assistant

Un servidor MCP para el procesamiento automatizado de reclamaciones de seguros de automóviles, construido con TypeScript y la API de Anthropic Claude.

Construí esto después de un año trabajando en Guidewire ClaimCenter en AXA France, donde integré los flujos de corredor EDI (506/508/509) para la apertura y modificación automatizada de reclamaciones. La lógica de negocio aquí refleja lo que traté allí — extracción de entidades, clasificación de gravedad, notificaciones al corredor — pero implementada con LLMs en lugar de reglas estáticas.

El núcleo es un pipeline de validación de dos modelos: un modelo rápido clasifica, un modelo más potente revisa y puede anularlo antes de que se envíe nada.

Qué hace

Tres herramientas, encadenadas:

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

Related MCP server: Claim Pilot MCP Server

El juez

La clasificación pasa por dos modelos.

Claude Haiku toma la reclamación estructurada y devuelve una gravedad, una puntuación de confianza y su razonamiento. Claude Sonnet recibe entonces los mismos datos de la reclamación junto con la respuesta de Haiku y devuelve un veredicto:

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

Sonnet no le pide a Haiku que lo intente de nuevo. Anula directamente, y finalSeverity es lo que el pipeline usa aguas abajo. El juez siempre tiene la última palabra.

La razón de que este patrón esté aquí y no en algo más barato: en el procesamiento de reclamaciones, una clasificación errónea no es un error cosmético. Una reclamación URGENT_ESCALATION con heridos enrutada a AUTO_PROCESS significa que alguien espera más tiempo por asistencia. Haiku es lo bastante barato como para ejecutarse en cada reclamación; Sonnet cuesta más pero solo se ejecuta una vez, como puerta de control.

analyze_claim_report

Toma el texto bruto del informe del accidente y devuelve JSON estructurado: vehículos, partes implicadas, daños, circunstancias, testigos.

Utiliza un patrón Agent Skill: el prompt de extracción vive en su propio módulo (skills/claim-extraction.skill.ts) en lugar de estar incrustado en la herramienta.

classify_claim_severity

Clasifica una reclamación como AUTO_PROCESS, REVIEW_NEEDED o URGENT_ESCALATION.

generate_broker_notification

Genera una carta de notificación formal para el corredor, con las acciones requeridas según la clasificación de gravedad.

Esta envía notificaciones de progreso de MCP (1/3, 2/3, 3/3) para que el cliente pueda mostrar el estado en tiempo real.

Arquitectura

├── 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

Algunas decisiones que merece la pena explicar

El registro va a stderr, no a stdout. Los servidores MCP que usan transporte stdio reservan stdout para los mensajes JSON-RPC. Un console.log suelto corrompe el protocolo y el cliente corta la conexión. Todo se registra en stderr en su lugar.

Haiku en todas partes excepto en el juez. La extracción, la clasificación y la generación de notificaciones se ejecutan en Haiku. Sonnet solo se ejecuta como validador. Con un volumen real de reclamaciones, esa diferencia de coste importa.

Las notificaciones de progreso son opcionales. El parámetro sendProgressFn es opcional para que la herramienta siga funcionando con clientes que no admiten actualizaciones de progreso. Ningún cliente debería fallar porque no envió un token de progreso.

Zod para la validación de entradas. El SDK de MCP usa esquemas de Zod para validar las entradas de las herramientas en el límite del servidor, antes de que se ejecute cualquier lógica de negocio. También proporciona argumentos de manejador tipados de forma gratuita.

Configuración

Requiere Node.js 18+ y una clave de API de Anthropic.

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

Ejecuta el servidor:

node dist/index.js

Pruébalo con MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Capturas de pantalla

Herramientas expuestas por el servidor:

Extracción de entidades de un informe de accidente bruto:

Clasificación con el veredicto del juez:

Notificación al corredor, con actualizaciones de progreso visibles abajo a la derecha:

Stack

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

Ideas para V2

Cosas que añadiría si esto fuera más allá:

• Envío de correo real — ahora mismo la notificación se genera pero no se envía. Conectar SendGrid o Nodemailer cerraría el círculo.

• Persistencia — las reclamaciones no tienen estado hoy en día. Una base de datos permitiría hacer seguimiento de una reclamación a lo largo de su ciclo de vida en lugar de procesar cada llamada de forma aislada.

• Muestreo MCP — permitir que el servidor solicite completaciones al modelo del cliente en lugar de llamar a la API directamente.

• Transporte remoto — actualmente solo stdio. Streamable HTTP lo haría desplegable.

Autor

Youssef Mokhbi — github.com/youssefmkb · LinkedIn