Insurance Claims Assistant

一个用于自动化车险理赔处理的 MCP 服务器，使用 TypeScript 和 Anthropic Claude API 构建。

我在 AXA France 从事 Guidewire ClaimCenter 工作一年后构建了这个项目，期间我集成了 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。 使用 stdio 传输的 MCP 服务器将 stdout 保留给 JSON-RPC 消息。一个多余的 console.log 会破坏协议，导致客户端断开连接。所有日志都改为输出到 stderr。

除裁判模型外全部使用 Haiku。 提取、分类和通知生成都在 Haiku 上运行。Sonnet 仅作为验证器运行。在真实的理赔量下，这种成本差异很重要。

进度通知是可选的。 sendProgressFn 参数是可选的，因此该工具仍然可以在不支持进度更新的客户端上工作。任何客户端都不应因为未发送进度令牌而崩溃。

使用 Zod 进行输入验证。 MCP SDK 使用 Zod 模式在服务器边界验证工具输入，在任何业务逻辑运行之前。它还免费提供了类型化的处理程序参数。

安装

需要 Node.js 18+ 和 Anthropic API 密钥。

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。Streamable HTTP 可以使其可部署。

作者

Youssef Mokhbi — github.com/youssefmkb · LinkedIn