Insurance Claims Assistant

MCP-сервер для автоматизированной обработки заявлений по автострахованию, созданный на TypeScript и Anthropic Claude API.

Я создал его после года работы над Guidewire ClaimCenter в AXA France, где я интегрировал EDI-потоки брокеров (506/508/509) для автоматического открытия и изменения заявлений. Бизнес-логика здесь повторяет то, с чем я там сталкивался — извлечение сущностей, сортировка по степени тяжести, уведомления брокеров — но реализована с помощью LLM вместо статических правил.

Ядро — это конвейер валидации из двух моделей: быстрая модель классифицирует, более сильная проверяет и может отменить её решение до того, как что-то будет отправлено.

Что он делает

Три инструмента, объединённых в цепочку:

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

Related MCP server: Claim Pilot MCP Server

Судья

Классификация проходит через две модели.

Claude Haiku получает структурированное заявление и возвращает степень тяжести, показатель уверенности и свои обоснования. Затем Claude Sonnet получает те же данные заявления вместе с ответом Haiku и возвращает вердикт:

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

Sonnet не просит Haiku повторить попытку. Он напрямую переопределяет решение, и finalSeverity используется конвейером дальше. Последнее слово всегда остаётся за судьёй.

Причина, по которой этот паттерн находится здесь, а не где-то подешевле: при обработке заявлений ошибочная классификация — это не косметическая ошибка. Заявление URGENT_ESCALATION с пострадавшими, направленное в AUTO_PROCESS, означает, что кто-то дольше ждёт помощи. Haiku достаточно дёшев, чтобы запускать его для каждого заявления; Sonnet стоит дороже, но запускается только один раз, в качестве шлюза.

analyze_claim_report

Принимает необработанный текст отчёта о происшествии и возвращает структурированный JSON: транспортные средства, стороны, ущерб, обстоятельства, свидетелей.

Использует паттерн Agent Skill — промпт для извлечения находится в отдельном модуле (skills/claim-extraction.skill.ts), а не встроен в инструмент.

classify_claim_severity

Классифицирует заявление как AUTO_PROCESS, REVIEW_NEEDED или URGENT_ESCALATION.

generate_broker_notification

Формирует официальное уведомительное письмо для брокера с необходимыми действиями на основе классификации степени тяжести.

Этот инструмент отправляет MCP-уведомления о ходе выполнения (1/3, 2/3, 3/3), чтобы клиент мог отображать статус в реальном времени.

Архитектура

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

Несколько решений, которые стоит пояснить

Логирование идёт в stderr, а не в stdout. MCP-серверы, использующие транспорт stdio, резервируют stdout для JSON-RPC-сообщений. Случайный console.log нарушает протокол, и клиент разрывает соединение. Всё логируется в stderr.

Haiku везде, кроме судьи. Извлечение, классификация и генерация уведомлений — всё работает на Haiku. Sonnet запускается только как валидатор. При реальных объёмах заявлений эта разница в стоимости имеет значение.

Уведомления о ходе выполнения необязательны. Параметр sendProgressFn необязателен, поэтому инструмент работает и с клиентами, не поддерживающими обновления хода выполнения. Ни один клиент не должен падать из-за того, что не отправил токен прогресса.

Zod для валидации входных данных. MCP SDK использует схемы Zod для проверки входных данных инструментов на границе сервера, до выполнения какой-либо бизнес-логики. Это также даёт типизированные аргументы обработчиков бесплатно.

Установка

Требуются Node.js 18+ и ключ API 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

Запустите сервер:

node dist/index.js

Протестируйте с помощью MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Скриншоты

Инструменты, предоставляемые сервером:

Извлечение сущностей из необработанного отчёта о происшествии:

Классификация с вердиктом судьи:

Уведомление брокера с обновлениями хода выполнения в правом нижнем углу:

Стек

Node.js, TypeScript, @modelcontextprotocol/sdk v4, Anthropic SDK (Haiku + Sonnet), Zod, транспорт stdio.

Идеи для V2

Что бы я добавил, если бы проект развивался дальше:

• Реальная доставка электронной почты — сейчас уведомление генерируется, но не отправляется. Подключение SendGrid или Nodemailer замкнуло бы цикл.

• Постоянное хранение — сейчас заявления не имеют состояния. База данных позволила бы отслеживать заявление на протяжении всего его жизненного цикла, а не обрабатывать каждый вызов изолированно.

• MCP-сэмплирование — позволить серверу запрашивать завершения у модели клиента, а не вызывать API напрямую.

• Удалённый транспорт — сейчас только stdio. Потоковый HTTP сделал бы его развёртываемым.

Автор

Youssef Mokhbi — github.com/youssefmkb · LinkedIn