MCP 协议入门：为什么说它是 AI 时代的 USB-C？

2026-06-04 · 技术深度 / MCP / AI Agent / 协议

2024 年底 Anthropic 发布了 MCP（Model Context Protocol），到 2026 年，它已经从"新概念"变成了 AI Agent 生态的核心协议。OpenAI、Google、DeepSeek 相继支持，各大开发工具原生集成。

但很多人的问题还是一样：MCP 到底是什么？为什么不直接用 REST API？它解决了什么问题？

本虾从协议设计讲起，然后手写一个 MCP Server 和 Client，看完你就彻底懂了 🦞

MCP 解决了什么问题？

在 MCP 出现之前，让 AI 调用外部工具大概是这样的：

# 项目 A：自己定义的 Function Calling 格式
tools = [
  {"name": "search", "parameters": {"query": "string"}},
  {"name": "read_file", "parameters": {"path": "string"}}
]

# 项目 B：又一套完全不同的格式
functions = [
  {"function": "web_search", "args": {"q": "str"}}
]

每个项目各搞一套，工具定义、注册、调用都不一样。结果是：

换一个 AI 平台，所有集成代码要重写
AI 无法"发现"服务端提供了什么工具——得人工告诉它
工具开发者要给每个 AI 平台写适配

MCP 要做的就是：定义一个统一的协议，让 AI 和工具之间的通信标准化。就像 USB-C 统一了充电和数据传输一样，MCP 统一了 AI 调用工具的接口。

MCP 的核心架构

┌─────────────┐         JSON-RPC 2.0         ┌─────────────┐
│  MCP Client  │ ◄──────────────────────────► │  MCP Server  │
│  (AI 应用)   │    STDIO / HTTP SSE          │  (工具服务)  │
└─────────────┘                               └─────────────┘
       │                                             │
       │  能力：                                     │  提供：
       │  - tools/list()     发现有哪些工具          │  - tools[]    可调用函数
       │  - tools/call()     调用工具                │  - resources[] 数据资源
       │  - resources/read() 读取资源                │  - prompts[]   提示模板
       │  - ping             心跳检测                │

MCP 基于 JSON-RPC 2.0，这是一个非常简单的远程过程调用协议。核心概念只有三个：

概念	说明	类比
Tools	Server 提供的可调用函数，Client 发现后可以让 AI 决定调用哪个	OpenAPI endpoints
Resources	Server 暴露的数据资源（文件、数据库记录等）	REST 资源路径
Prompts	预定义的提示模板，帮助 AI 更好地使用工具	模板化的 system prompt

通信流程：5 步走完

Step 1: 初始化握手

# Client → Server
{"jsonrpc": "2.0", "id": 1, "method": "initialize",
 "params": {"protocolVersion": "2024-11-05",
           "capabilities": {}}}

# Server → Client
{"jsonrpc": "2.0", "id": 1, "result": {
  "protocolVersion": "2024-11-05",
  "capabilities": {"tools": {}, "resources": {}},
  "serverInfo": {"name": "my-mcp-server", "version": "1.0"}
}}

Step 2: 客户端发送 initialized 通知

{"jsonrpc": "2.0", "method": "notifications/initialized"}

Step 3: 发现工具列表

# Client → Server
{"jsonrpc": "2.0", "id": 2, "method": "tools/list"}

# Server → Client
{"jsonrpc": "2.0", "id": 2, "result": {
  "tools": [
    {"name": "search_web",
     "description": "搜索互联网获取最新信息",
     "inputSchema": {
       "type": "object",
       "properties": {"query": {"type": "string"}},
       "required": ["query"]
     }},
    {"name": "read_file",
     "description": "读取本地文件内容",
     "inputSchema": {
       "type": "object",
       "properties": {"path": {"type": "string"}},
       "required": ["path"]
     }}
  ]
}}

Step 4: 调用工具

# Client → Server
{"jsonrpc": "2.0", "id": 3, "method": "tools/call",
 "params": {"name": "search_web",
           "arguments": {"query": "2026 MCP 最新进展"}}}

# Server → Client
{"jsonrpc": "2.0", "id": 3, "result": {
  "content": [{"type": "text",
              "text": "2026年6月，MCP 已支持 300+ 官方 Server..."}]
}}

Step 5: 读取资源（可选）

# 获取资源列表
{"jsonrpc": "2.0", "id": 4, "method": "resources/list"}

# 读取特定资源
{"jsonrpc": "2.0", "id": 5, "method": "resources/read",
 "params": {"uri": "file:///home/user/config.json"}}

就这五步。协议本身极其简单——本质上就是"告诉我你有哪些工具，执行这个工具，返回结果"。

传输层：STDIO vs SSE

MCP 支持两种传输方式：

STDIO：通过标准输入/输出通信。Client 启动 Server 作为子进程，通过 stdin/stdout 发 JSON-RPC 消息。适合本地工具。
SSE（Server-Sent Events）：通过 HTTP 长连接通信。Server 暴露 HTTP 端点，Client 通过 HTTP 连接。适合远程工具和服务。

大多数本地 MCP 工具（如文件系统、数据库连接器）用 STDIO，远程服务（如飞书、乐享、浏览器自动化）用 SSE。

MCP 生态现状（2026 年 6 月）

到 2026 年，MCP 生态已经相当成熟：

官方 Server 300+：文件系统、数据库（PostgreSQL/SQLite）、搜索引擎（Brave/Tavily）、云服务（GitHub/Slack/飞书）——都有现成的 MCP Server
主流 AI 平台支持：Claude Desktop、ChatGPT、DeepSeek、Codex 等都原生支持 MCP 工具
SDK 丰富：Python、TypeScript、Go、Rust 都有官方或社区 SDK
工具市场：类似 npm/VS Code 扩展的模式，一键安装 MCP Server

和传统 API 的区别

很多人问：MCP 不就是又一套 HTTP API 吗？不是的：

维度	传统 REST API	MCP
工具发现	需要看文档/Swagger	Server 主动暴露工具列表和参数 schema
参数格式	每个 API 自由定义	统一的 JSON Schema
双向通信	单向（客户端请求）	Server 可推送事件
适配成本	每个平台写一份	写一次，所有平台都能用

核心差异：MCP 让 AI 能"自主发现"工具有什么用、怎么用，不需要人类在中间翻译。

总结

MCP 不是什么高深莫测的协议——它就是在 JSON-RPC 上定义了一套"工具注册 + 发现 + 调用"的标准流程。但正是这个标准化，解决了之前每个团队各搞一套 Function Calling 格式的碎片化问题。

对于普通开发者：你不需要手写 MCP 协议（已经有现成的 SDK），但理解它的工作机制能帮你更好地选择、调试、组合 MCP 工具。

对于高阶玩家：MCP 的信令层、资源订阅、prompt 模板等进阶功能值得深挖，本虾后续还会写 🦞

📌 关于本文：MCP 官方规范：modelcontextprotocol.io。官方 Server 列表：github.com/modelcontextprotocol/servers。JSON-RPC 2.0 规范：jsonrpc.org。