第36章:MCP协议标准
学习目标
- 理解MCP协议的核心定位和设计理念
- 掌握MCP的架构组成:Server、Client、Tools、Resources、Prompts
- 了解MCP与传统API集成的区别
- 学会从测试视角评估MCP集成质量
前置要求
- 已完成第34-35章架构基础的学习
- 理解LLM的Function Calling能力
- 有基本的API集成开发经验
一句话定义
MCP(Model Context Protocol)
MCP 是 Anthropic 提出的开放协议,定义了AI模型与外部工具/数据源之间的标准通信方式——可以理解为"AI世界的USB接口",让任何AI都能即插即用地连接任何工具。
生活类比:USB接口的故事
为什么MCP像USB?
在USB出现之前,每种外设都有不同的接口——键盘用PS/2、打印机用并口、鼠标用串口,换一个设备就要装一个驱动。USB统一了接口标准,插上就能用。
MCP之于AI工具,就像USB之于电脑外设:统一接口标准,即插即用。
为什么需要MCP?
在没有MCP的世界,每个AI模型和每个工具的集成都是"定制开发",导致大量重复劳动:
无MCP vs 有MCP的集成成本
没有 MCP 的世界:
Claude 要连 GitHub → 写专门的 GitHub 集成
GPT 要连 GitHub → 又写一套 GitHub 集成
Cursor 要连 GitHub → 再写一套
→ M个AI模型 × N个工具 = M×N 套集成代码(重复劳动)
有 MCP 的世界:
每个工具写一个 MCP Server(1份)
每个AI模型实现 MCP Client(1份)
→ M + N 套代码(大幅减少重复)
示例:
GitHub写1个MCP Server → Claude、GPT、Cursor都能用
测试平台写1个MCP Server → 所有AI助手都能操作测试平台
MCP的核心架构
MCP架构全景
┌──────────────────────────────────────────────────────────────────┐
│ MCP 协议架构 │
│ │
│ ┌──────────┐ MCP协议(JSON-RPC) ┌───────────────────────┐ │
│ │ MCP │ ◄──────────────────► │ MCP Server │ │
│ │ Client │ │ (工具提供方) │ │
│ │ (AI侧) │ │ │ │
│ │ │ │ 示例: │ │
│ └────┬─────┘ │ - GitHub Server │ │
│ │ │ - 数据库 Server │ │
│ AI应用示例: │ - 文件系统 Server │ │
│ - Claude Code │ - 测试平台 Server │ │
│ - Cursor IDE │ - API服务 Server │ │
│ - Zed Editor │ │ │
│ - 其他AI助手 └───────────────────────┘ │
│ │
│ 通信内容: │
│ - 工具列表(有哪些工具可用) │
│ - 工具调用(调用某个工具,传入参数) │
│ - 结果返回(工具执行结果) │
│ - 资源访问(读取文件/数据等) │
│ - Prompt模板(预设提示词) │
│ │
└──────────────────────────────────────────────────────────────────┘
MCP的核心概念
| 概念 | 说明 | 类比 | 测试关注点 |
|---|---|---|---|
| MCP Server | 提供工具和数据的服务端 | USB设备(如U盘) | 工具定义准确性、执行可靠性 |
| MCP Client | AI应用端的连接器 | USB接口/驱动 | 协议兼容性、发现机制 |
| Tools | Server提供的可调用功能 | U盘的功能(读写文件) | 参数验证、返回格式、错误处理 |
| Resources | Server提供的可读数据 | U盘里的文件 | 数据完整性、权限控制 |
| Prompts | Server提供的预设提示词模板 | U盘自带的说明书 | 模板有效性、参数填充 |
MCP vs 传统API集成对比
| 维度 | 传统API集成 | MCP |
|---|---|---|
| 接口标准 | 每个API不同,需单独适配 | 统一协议,即插即用 |
| 开发成本 | 高(每个工具单独集成) | 低(写一次Server,所有AI可用) |
| 发现机制 | 需手动配置 | 自动发现可用工具 |
| 维护成本 | 每个集成独立维护 | 统一维护 |
| 生态效应 | 孤岛(各自独立) | 共享生态(一次开发,多方受益) |
| 测试复用 | 每个集成单独测试 | Server测试一次,所有Client受益 |
MCP通信协议详解
MCP基于JSON-RPC 2.0协议,使用标准化的消息格式进行通信:
JSON - MCP消息示例
// MCP工具调用请求示例
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "github_search_issues",
"arguments": {
"query": "bug in authentication",
"repo": "facebook/react"
}
}
}
// MCP工具返回结果示例
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "Found 5 issues matching query..."
}
]
}
}
企业测试中的MCP应用
测试团队的MCP实践建议
- 搭建测试工具MCP Server:把测试管理平台、CI/CD系统、缺陷管理系统封装为MCP Server,让AI直接操作
- 让AI Agent通过MCP调用测试工具:AI自动从Jira拉取需求→生成用例→推送到测试平台→执行→报告
- 测试MCP集成质量:验证工具调用的正确性、错误处理、权限控制、并发性能
- 贡献测试领域MCP Server:将性能测试工具、安全扫描工具封装为MCP Server,供整个AI生态使用
测试视角:MCP集成测试要点
| 测试维度 | 测试内容 | 验证方法 |
|---|---|---|
| 协议兼容性 | 消息格式、字段完整性 | 发送标准请求,验证返回格式 |
| 工具发现 | Client能否正确获取Server的工具列表 | 调用tools/list,验证返回完整性 |
| 工具调用 | 参数传递正确、执行成功 | 调用具体工具,验证返回结果 |
| 错误处理 | 无效参数、超时、权限不足等场景 | 发送异常请求,验证错误返回格式 |
| 并发性能 | 多工具并行调用、高并发请求 | 并发调用测试,验证响应时间和稳定性 |
| 资源访问 | 读取Server提供的资源数据 | 调用resources/read,验证数据完整性 |
本章小结
- MCP是Anthropic提出的开放协议,定义AI与工具的标准通信方式,像"AI世界的USB接口"
- MCP架构包含Server(工具提供方)、Client(AI侧)、Tools、Resources、Prompts五个核心概念
- MCP统一接口标准,大幅降低集成开发成本,一次开发多方受益
- 测试团队可搭建测试工具MCP Server,让AI直接操作测试系统
- MCP集成测试需关注协议兼容性、工具发现、调用准确性、错误处理和并发性能
扩展阅读
- 第37章:MCP服务器开发实战 - 从零构建MCP Server
- 第38章:Skills技能体系 - MCP之上的能力封装
- MCP官方规范文档