# MCP 最终提交稳定性改造要求

## 一、改造目标

在不改变现有业务规则和业务系统输出规范的前提下，确保 Agent 生成的业务结果可以稳定转换为 MCP 可接收的 payload。

我们不要求 Agent 自行理解或猜测 MCP transport 字段。`source_event_index`、`ai_task_results[]` 等字段的含义、类型和映射，必须由 MCP/Adapter 侧提供确定性实现。

目标链路必须是：

```text
booking-desk-event Skill
  → 业务结果
  → Result Adapter
  → MCP payload
  → Schema Validator
  → 冻结
  → MCP 提交一次
```

## 二、必须保持不变的内容

MCP 侧不得通过修改以下内容来解决字段接收问题：

- 现有公开业务 JSON 根结构；
- `message_events` 的业务事件类型和 subtype；
- Parent Group / Child Group 业务语义；
- Trace、Parent、linked/derived 事件关系；
- S10、S99 和基础设施错误规范；
- Skill 的业务裁决权；
- 一次冻结、一次提交、失败不重试的生命周期。

MCP 只负责接收和处理已经形成的业务结果，不负责重新解释业务含义。

## 三、必须由 MCP/Adapter 侧承担的职责

### 1. 提供确定性的 payload mapping

必须建立固定的：

```text
BusinessResult → MCP payload
```

映射层。

该层不能由 LLM 临时生成，也不能让 Agent 根据字段名称猜测。

至少需要明确：

| 字段 | 必须明确的内容 |
|---|---|
| `source_message_id` | 来源、类型、必填规则、透传方式 |
| `source_event_index` | 真实含义、类型、索引基准、对应数组 |
| `related_source_event_index` | 单事件关系如何映射 |
| `related_source_event_indices` | 多事件关系如何映射、顺序和唯一性 |
| `ai_task_results[]` | item 的完整结构和业务结果映射方式 |
| `extraction_warnings` | 是否必填、允许的结构和空值规则 |

`E1`、`E2` 只能作为 Agent/业务结果中的内部事件标识，不能默认当作 MCP 的 `source_event_index`。

### 2. 负责生成 `source_event_index`

Adapter 必须建立事件映射，例如：

```text
E_CHILD_1 → MCP index 0
E_CHILD_2 → MCP index 1
E_PARENT  → MCP index 2
E_TRACE   → MCP index 3
```

实际索引类型和起始值必须以真实 MCP schema 为准，不允许 Agent 猜测。

对于：

```json
"related_source_event_indices": ["E_CHILD_1", "E_CHILD_2"]
```

Adapter 必须将其转换成 MCP 真实要求的索引格式，并保持顺序、唯一性和关联正确。

### 3. 支持跨事件 Trace

当前业务要求：

- 一个补充请求覆盖完整 Parent split 的全部 Child；
- Trace 必须关联全部 Child；
- 不得绑定到第一个 Child E1；
- 必须保留完整跨事件关系。

因此 MCP/Adapter 必须能够接收和保持：

```text
Trace
  → related_source_event_indices[]
  → 全部 Child New Booking
```

不能把多目标 Trace 压缩成单一 `source_event_index`。

## 四、提交前必须有 Schema Validator

MCP 调用前必须校验：

- 必填字段；
- 字段类型；
- 允许值；
- 数组顺序；
- 索引是否存在；
- 关系是否悬空；
- 是否存在重复索引；
- 是否存在未知字段；
- `ai_task_results[]` item 是否符合完整 schema；
- `source_message_id` 是否正确传播。

校验失败时：

- 不让 Agent 猜字段；
- 不修改已经冻结的业务结果；
- 不重新调用 Skill；
- 不重试 MCP；
- 按既有 transport/基础设施错误通道结束；
- 保留原始错误和 mapping 诊断。

## 五、必须提供的 MCP 交付物

请提供以下内容：

1. 当前实际使用的完整 MCP tool schema；
2. `ai_task_results[]` 的完整 item schema；
3. `source_event_index` 和关联索引的正式定义；
4. BusinessResult → MCP payload mapping 文档；
5. 一个成功的完整 payload 示例；
6. 一个跨 Child Trace 的成功示例；
7. 一个错误字段被拒绝的示例；
8. Adapter 或 MCP wrapper 的实现位置；
9. Schema validation 和一次提交测试结果；
10. 失败不重试、payload 不被修改的测试证据。

## 六、验收条件

以下测试必须通过：

1. Agent 使用 `E1` 时，Adapter 不会盲目把它当成 MCP index；
2. 错误关系索引会在提交前被拒绝；
3. 缺失 `source_message_id` 会按既有基础设施错误处理；
4. MCP 失败时只提交一次，不重试；
5. 提交 payload 与冻结结果的 mapping 可追溯；
6. MCP 响应不会污染业务 JSON。


## 最终要求

请不要通过继续增加 Prompt 文字，让 Agent 学习 MCP 内部字段含义来解决问题。

我们要求的是：

> MCP/Adapter 提供稳定、确定性、可验证的业务结果到 MCP payload 的转换能力；Agent 负责业务结果，MCP 负责 transport 接收，两者之间不能依赖模型猜测。