一句话定位：MCP（Model Context Protocol，模型上下文协议）是AI应用与外部工具/数据源之间的"USB-C接口"——每个应用实现一次协议，每个工具实现一次协议，即可自动互通，将N×M的集成问题降维为N+M。

一、为什么需要MCP：M×N集成困境

1.1 问题本质

在MCP出现之前，要让一个AI应用连接N个外部工具，需要为每对（应用, 工具）开发定制集成。如果有M个AI应用和N个工具，集成数量是M × N。5个应用对接10个工具 = 50条集成链路，每条都需要单独开发、维护、测试。

应用A ──定制对接──> 工具1 应用A ──定制对接──> 工具2 应用B ──定制对接──> 工具1 → M × N 条链路 应用B ──定制对接──> 工具2 ...

1.2 MCP的解法

MCP将"应用↔工具"的直连改为"应用↔协议↔工具"的中间层模式。每个应用实现一次MCP客户端，每个工具实现一次MCP服务端，集成数量从M × N 降为 M + N。5个应用 + 10个工具 = 15次实现，而非50条链路。

应用A ─┐ 应用B ─┼─ MCP协议层 ─┬─ 工具1 应用C ─┘ ├─ 工具2 └─ 工具3 M + N 次实现

这正是HTTP标准当年解决的问题——浏览器和服务器各自实现HTTP一次，即可互通。

二、MCP核心架构：Host-Client-Server三层模型

MCP采用客户端-服务器架构，由三个核心角色组成：

2.1 MCP Host（宿主）

宿主是整个交互的调度中心，通常是AI客户端应用本身——Claude Desktop、Cursor、VS Code插件、自研Agent框架等。Host的职责：

• 创建和管理Client实例：每个Server连接对应一个Client实例

• 执行全局安全策略：决定哪些Server可以连接、哪些工具可以被调用

• 持有LLM推理状态：LLM的思考、决策、上下文都由Host管理

• 用户交互：将LLM的调用请求呈现给用户确认（人在回路）

2.2 MCP Client（客户端）

Client是Host内部的连接器，每个Client与一个Server保持1:1的会话连接。Client的职责：

• 协议握手：与Server协商版本号和能力（capabilities）

• 消息路由：将Host/LLM的请求转发给Server，将Server的响应返回给Host

• 能力协商：在握手阶段确认双方支持哪些功能（工具订阅、资源变更通知等）

2.3 MCP Server（服务端）

Server是能力提供方，每个Server封装一类外部能力。Server是无状态执行器（stateless executor）——接收请求、执行动作、返回结果，不维护推理状态。Server可以暴露三种原语：

2.4 传输层

MCP支持两种传输方式：

三、通信协议：JSON-RPC 2.0

MCP的消息格式基于JSON-RPC 2.0，这是一种轻量级的远程过程调用协议。所有消息都是JSON对象，通过method字段标识操作类型。

3.1 生命周期消息

客户端 服务端 │ │ │──── initialize ───────────────>│ (协议版本、能力声明) │<─── initialize result ────────│ (服务端能力、版本确认) │──── initialized ─────────────>│ (确认握手完成) │ │ │ ... 正常通信阶段 ... │ │ │ │──── shutdown ─────────────────>│ (优雅关闭) │<─── shutdown result ───────────│

3.2 三类核心操作

1. 工具发现（tools/list）

// Client → Server: 请求工具列表 {"jsonrpc": "2.0", "id": 1, "method": "tools/list"} ​ // Server → Client: 返回工具清单 {"jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "query_database", "description": "执行SQL查询并返回结果", "inputSchema": { "type": "object", "properties": { "sql": {"type": "string", "description": "SQL查询语句"} }, "required": ["sql"] } } ] }}

2. 工具调用（tools/call）

// Client → Server: 调用工具 {"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "query_database", "arguments": {"sql": "SELECT COUNT(*) FROM users WHERE status='active'"} }} ​ // Server → Client: 返回执行结果 {"jsonrpc": "2.0", "id": 2, "result": { "content": [ {"type": "text", "text": "活跃用户数: 12,847"} ] }}

3. 资源读取（resources/read）

// Client → Server: 读取资源 {"jsonrpc": "2.0", "id": 3, "method": "resources/read", "params": {"uri": "file:///app/config.yaml"}} ​ // Server → Client: 返回资源内容 {"jsonrpc": "2.0", "id": 3, "result": { "contents": [ {"uri": "file:///app/config.yaml", "mimeType": "text/yaml", "text": "database:\n host: localhost\n port: 5432"} ] }}

四、MCP与其他技术的关系

这是理解MCP最关键的对比——MCP不是替代品，而是标准化层。

4.1 MCP vs Function Calling

关键区别：Function Calling是"模型怎么表达要调用工具"，MCP是"应用怎么发现和连接工具"。两者协同工作——LLM用Function Calling表达调用意图，MCP客户端负责将这个意图路由到正确的Server并执行。

4.2 MCP vs RAG

4.3 MCP vs A2A（Agent-to-Agent）

4.4 四者协作全景

用户提出任务 │ ▼ ┌─────────┐ Function Calling ┌──────────┐ │ LLM │ ──── (生成调用意图) ────> │ MCP Client│ │ (推理) │ └────┬─────┘ └─────────┘ │ MCP协议 ▲ ▼ │ RAG检索 ┌──────────┐ │ (注入背景知识) │MCP Server │ ──> 数据库/API/文件 │ └──────────┘ ┌─────────┐ │ │ 另一个 │ <── A2A协议 (Agent间协作) ────┘ │ Agent │ └─────────┘

五、MCP的演变历程

5.1 时间线

5.2 从有状态到无状态：2026-07-28规范的转折

2026年7月发布的最新规范带来了一个根本性变化：MCP从双向有状态协议转变为请求/响应无状态协议。

有状态时代（2024.11 - 2026.06）：

• Client与Server保持长连接会话

• Server可维护状态：数据库连接、缓存凭证、打开的文件句柄

• 优势：连接复用、状态保持

• 问题：难以水平扩展、单点故障、云原生部署困难

无状态时代（2026.07 -）：

• 每个请求自包含所有上下文

• Server成为真正的无状态执行器

• 优势：可水平扩展、云原生友好、负载均衡简单

• 代价：连接状态管理迁移到Client侧

📌配图说明：下方HTML文件中包含"MCP演变时间线图"。

5.3 治理演变

从Anthropic主导到Linux Foundation社区治理的转变，是MCP走向行业标准的关键一步：

• SEP流程（Specification Enhancement Proposals）：任何人可提交规范增强提案，经社区评审后合并

• 厂商中立：不再由单一公司控制协议方向

• 多方参与：Microsoft、Google、Block、Replit等企业共同参与治理

六、安全与治理

6.1 安全模型

MCP的安全设计比传统API集成更严格，因为它涉及LLM的自主工具调用：

6.2 安全风险

MCP引入了新的攻击面：

1. 提示注入经由工具描述：恶意Server在工具描述中注入提示词，诱导LLM执行非预期操作

2. 工具权限过大：Server暴露了过多能力（如删除文件），LLM误调用造成损失

3. 中间人攻击：远程Server的HTTP连接需TLS保护

4. 供应链风险：第三方MCP Server可能包含恶意代码

6.3 防御建议

• 最小权限原则：Server只暴露必要工具，不暴露通配能力

• 工具描述审计：人工审查所有工具的description和inputSchema

• 白名单机制：Host维护允许调用的工具白名单

• 沙箱执行：远程Server在容器/沙箱中运行

• 调用日志：所有tools/call记录到审计系统

七、生态与应用场景

7.1 生态规模

截至2026年中，MCP生态已相当成熟：

• 规范仓库：GitHub上7,700+ stars

• Server生态：19个相关项目进入GitHub Top 1500

• 官方Server：文件系统、Git、PostgreSQL、SQLite、Slack、Google Drive等50+官方Server

• SDK：TypeScript、Python、Java、Go、Rust、C#多语言SDK

• 客户端支持：Claude Desktop、Cursor、Windsurf、VS Code、Zed等主流IDE

7.2 典型应用场景

场景一：AI编程助手连接开发工具链

Cursor (Host) ├── MCP Client → Filesystem Server (读写项目文件) ├── MCP Client → Git Server (查看diff、提交历史) ├── MCP Client → Database Server (查询开发数据库) └── MCP Client → Slack Server (发送代码审查通知)

LLM在Cursor中可以：读取文件内容（Resource）→ 搜索Git历史（Tool）→ 执行数据库查询（Tool）→ 发送Slack通知（Tool），全程通过MCP协议标准化通信。

场景二：企业Agent连接内部系统

企业自研Agent (Host) ├── MCP Client → SAP Server (查询订单、库存) ├── MCP Client → OA Server (发起审批流程) ├── MCP Client → Wiki Server (检索内部知识库) └── MCP Client → Monitoring Server (查询系统健康状态)

财务Agent可以："查询SAP中本月各区域营收（Tool）→ 检索Wiki中的差异分析模板（Resource）→ 在OA中发起分析报告审批（Tool）"。

场景三：数据分析Agent

数据分析Agent (Host) ├── MCP Client → PostgreSQL Server (执行SQL) ├── MCP Client → Python REPL Server (运行数据科学代码) ├── MCP Client → Chart Server (生成可视化图表) └── MCP Client → Email Server (发送分析报告)

7.3 开发一个MCP Server（概念示例）

以Python SDK为例，创建一个简单的"天气查询"Server：

from mcp.server import Server from mcp.types import Tool, TextContent server = Server("weather-server") @server.list_tools() async def list_tools() -> list[Tool]: return [ Tool( name="get_weather", description="查询指定城市的实时天气", inputSchema={ "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } ) ] @server.call_tool() async def call_tool(name: str, arguments: dict) -> list[TextContent]: if name == "get_weather": city = arguments["city"] # 实际调用天气API weather = await fetch_weather_api(city) return [TextContent(type="text", text=f"{city}当前天气: {weather}")] if __name__ == "__main__": import asyncio from mcp.server.stdio import stdio_server asyncio.run(stdio_server(server.create_session()))

Host端（如Claude Desktop）只需在配置文件中添加：

{ "mcpServers": { "weather": { "command": "python", "args": ["weather_server.py"] } } }

之后，LLM就能自动发现并调用get_weather工具——无需编写任何集成代码。

八、未来趋势

8.1 协议演进方向

2026-07-28规范揭示的演进方向：

1. 无状态核心：服务端可水平扩展，适配云原生和Serverless部署

2. Extensions框架：允许在不修改核心协议的情况下扩展功能（如视频流、二进制数据）

3. 长时任务一等公民：原生支持需要数分钟/数小时完成的异步任务，带进度通知

4. 丰富的UI表面：Server可以返回结构化的UI组件（表单、图表），由Host渲染

8.2 生态趋势

1. MCP + A2A融合：MCP负责Agent↔工具，A2A负责Agent↔Agent，两者共同构成"Agent互联网"的基础设施

2. MCP网关：企业部署MCP网关统一管理所有Server的认证、授权、审计，类似API网关的角色

3. MCP市场：类似App Store的MCP Server分发平台，开发者发布Server供他人使用

4. 行业模板：金融、医疗、制造等行业的标准化MCP Server集合，降低行业采纳门槛

8.3 挑战与隐忧

1. 安全治理：第三方Server的供应链风险需要类似软件物料清单（SBOM）的机制

2. 性能开销：JSON-RPC的序列化/反序列化在高频场景下存在性能瓶颈

3. 协议碎片化：Extensions框架可能导致不同实现之间的兼容性问题

4. 与Function Calling的边界模糊：部分场景下两者功能重叠，开发者面临选型困惑

九、总结

MCP在不到两年的时间内，完成了从Anthropic实验性开源项目到Linux Foundation行业标准的蜕变。它的核心价值不在于发明了新技术，而在于将已有的客户端-服务器模式标准化到AI工具集成领域。

对于技术决策者：如果你的AI应用需要连接3个以上外部系统，MCP的标准化收益已超过实现成本。对于工具/数据提供方：封装一个MCP Server，即可被所有支持MCP的AI客户端发现和使用，这比维护N套定制API集成更高效。

MCP正在成为AI时代的"HTTP"——一个看似简单但改变一切的连接标准。

参考资料

• MCP官方规范：Specification - Model Context Protocol

• MCP 2026-07-28发布公告：The 2026-07-28 Specification | Model Context Protocol Blog

• Avaya《The Model Context Protocol: A Status Report for Enterprise CX Leaders》

• Semantic Scholar论文《Model Context Protocol for Agentic AI》

• safeguard.sh《Model Context Protocol in 2026: Security Landscape》

• CSDN《MCP协议详解：架构原理、GitHub生态数据与开发实践(2026)》