MCP（Model Context Protocol）测试核心：它不是测大模型本身，是测 MCP 服务对外暴露的全部工具、通信链路、权限、异常边界、业务可用性。 分 5 大模块：连通性、工具元数据、功能正确性、异常鲁棒性、业务场景集成，贴合你私有化部署（RAGFlow/FastGPT）实际验证。

一、基础连通性测试（必过，第一步）

目标：确认 MCP 服务能正常建立会话，客户端可以握手成功

1. 基础连接握手
   • 使用 MCP 客户端（mcp-cli、平台内置 MCP 调试器）填入服务地址，验证能否成功建立连接。
   • 测试：长连接稳定性，持续保持会话几分钟，看是否无故断开。
2. 鉴权 / 身份校验
   • 正确 token / 密钥：连接成功；
   • 错误 token、空密钥：拒绝连接，不能泄露内部数据；
   • 无权限账号：返回权限拒绝，不能调用受限工具。
3. 网络边界测试
   • 内网访问：内网环境可连通；
   • 外网（如果禁止外网访问）：外网访问应当拒绝；
   • Docker 容器环境：平台容器能否访问 MCP 服务地址（常见坑：127.0.0.1 容器内访问失败）。

二、工具元数据自动发现测试（MCP 核心特性）

MCP 最大特点：客户端自动获取工具列表，不需要手动写 schema

1. 获取工具列表list_tools
   • 是否返回全部预期工具名称，不能丢失工具；
   • 每个工具的描述、入参 JSON Schema 是否完整、准确；参数类型、必填标记不能错误。
2. 工具描述可读性

   大模型会读取这份 schema 做 function‑call，schema 写错，大模型就不会调用这个工具。

   • 参数说明清晰，枚举值完整；必填参数标记正确。
3. 排除多余工具：不应该暴露未开放、内部调试工具。

反例：MCP 服务实际提供 5 个工具，list_tools 只返回 2 个 → MCP 服务 bug，无法使用缺失的能力。

三、每个工具的功能正确性测试（最重要）

对 MCP 返回的每一个tool，逐个调用call_tool测试。

示例 MCP 工具举例：read_file、db_query、retrieve_knowledge、web_fetch

✅正向用例（正常输入）

1. 必填参数完整传入：调用工具，校验返回结果符合业务预期。
   • 文件读取：读取存在的文件，返回正确文本；
   • 知识库检索 MCP：输入问题，返回正确的文档片段；
   • DB 查询 MCP：传入 SQL，返回正确数据集。
2. 可选参数不传：不传可选参数，工具使用默认逻辑正常执行，不崩溃。
3. 参数合法边界值：长文本、大分页、大数量的查询，验证返回结果完整。

❌负向用例（异常输入）

1. 缺少必填参数：调用时不填必填项，MCP 返回标准化错误，而不是直接服务崩溃。
2. 参数类型错误：数字传字符串、传入非法枚举值；需要返回报错，不要内部抛出堆栈。
3. 访问不存在资源
   • 读取不存在文件；查询不存在数据表；检索不存在知识库 ID；
   • 返回业务错误，服务不宕机。
4. 越权访问校验（企业重点）
   • 文件 MCP：尝试访问目录外敏感文件（../../etc/passwd路径穿越）；必须拦截禁止访问。
   • 数据库 MCP：是否可以执行危险 SQL（drop、delete），MCP 服务应当做语句拦截。

四、异常、性能与稳定性测试

1. 错误返回格式标准化 业务报错、系统报错，遵循 MCP 协议错误结构，不要返回原始堆栈给客户端。客户端（大模型平台）要能解析错误信息，交给大模型做重试 / 提示。
2. 并发调用测试 同时并发调用同一个 / 不同工具，MCP 服务会不会卡死、内存泄漏；企业 Agent 场景会高频触发。
3. 超时场景
   • 慢查询场景（数据库大查询、大文件读取），验证超时逻辑，不会永久阻塞会话；
   • 客户端超时断开后，MCP 服务端是否可以正确释放资源。
4. 资源占用观测 多次调用后观察 MCP 服务进程 CPU、内存，是否存在内存泄漏。

五、端到端集成测试（模拟真实 AI Agent 使用，最贴近业务）

前面都是直接调用 MCP 接口；这一步交给大模型平台去使用 MCP，复现真实业务。

1. 将 MCP 接入 RAGFlow/FastGPT，大模型通过 Function Calling 自动调用 MCP 工具，而不是手动 call_tool。
   • 测试：大模型是否能看懂 MCP 下发的工具描述，自主选择合适工具。
   • 场景示例：提问 “查询某某业务数据”，模型自动调用 db_query 工具，而不是硬编答案。
2. 多轮工具调用：一个问题需要多次调用 MCP 工具（读文件→查数据库→检索知识库），验证多轮会话上下文状态是否正常。
3. 工具返回结果过大：MCP 返回大量数据，测试平台是否可以正常把结果交给大模型，不会截断、乱码。
4. 失败后的 Agent 行为：MCP 工具调用报错，大模型是否可以合理处理报错，而输出乱码 / 异常堆栈给用户。

六、附加专项测试（视 MCP 类型而定）

MCP 服务类型	重点专项测试项
知识库 MCP	检索召回准确率；过滤权限；知识库 ID 参数校验
文件操作 MCP	路径穿越防护；读写权限；大文件读取分片逻辑
数据库 MCP	SQL 注入防护；禁止高危 DDL/DML 语句；查询结果大小限制
网页抓取 MCP	异常网页、超时网页处理；反爬页面返回提示

七、常见 MCP 故障点（测试中高频踩坑）

1. list_tools 返回 schema 错误，大模型看不懂参数，完全不会触发工具调用。
2. Docker 部署 MCP，地址写 127.0.0.1，容器客户端访问不到 MCP 服务。
3. MCP 内部抛出原始异常堆栈，直接透传给大模型，泄露内部信息。
4. 缺少越权防护，出现路径穿越、SQL 注入风险。
5. 长会话内存泄漏，跑一段时间 MCP 服务卡死。
6. 工具返回数据量巨大，没有做截断，耗尽大模型上下文窗口。

极简测试流程总结（实操顺序）

1. 连接握手 + 鉴权测试
2. list_tools 获取全部工具元数据，校验 schema
3. 逐个工具：正向用例 → 异常入参 → 越权安全测试
4. 并发、超时、稳定性压测
5. 接入大模型平台，端到端 Agent 自动调用测试