MCP协议：给AI装上"USB接口"的技术标准

上周我把一个AI Agent接入了公司内部系统。

说实话，以前做这种事，每接一个工具就要写一套适配层——数据库一套、API一套、文件系统一套，光胶水代码就写了2000多行。改一个接口，三个地方跟着动。

这次我用MCP协议，同样的功能，写了不到200行。

不是因为MCP多神奇，是因为它做了一件看似简单但极其重要的事：把"AI调用工具"这件事标准化了。

---

没有MCP之前的世界长什么样

假设你要做一个AI客服Agent，需要5个能力：查订单、改地址、查库存、发短信、写工单。

每个能力的接入方式都不一样：

能力	调用方式	认证方式	返回格式
查订单	REST API	Bearer Token	JSON
改地址	GraphQL	API Key	JSON
查库存	SQL直连	数据库账号	ResultSet
发短信	SDK调用	AccessKey	XML
写工单	SOAP	WS-Security	XML

5个能力，5套接入逻辑，5种错误处理方式。如果你还要加第6个能力，再来一套。

这就是MCP出现之前的真实状况——每接一个工具，就写一套适配层，N个工具就是N套。

更致命的问题是，你在A项目写的适配代码，到B项目基本不能复用。因为每个项目的AI框架不同、调用约定不同、错误处理策略不同。

---

MCP是什么

MCP的全称是Model Context Protocol，2024年11月由Anthropic发布。

你不需要记住这个全称。你只需要理解一个类比：

MCP之于AI，就像USB之于电脑。

在USB出现之前，键盘用PS/2接口，打印机用并口，鼠标用串口，每个外设一种接口。你买一个新设备，先看电脑上有没有对应的插口。

USB统一了这一切：不管什么设备，插上就能用。

MCP做的是同样的事：不管什么工具，AI接上就能调用。

具体来说，MCP定义了三个核心概念：

Tools（工具）——AI可以执行的函数。比如"查订单""发邮件""搜索文档"。

Resources（资源）——AI可以读取的数据。比如"用户信息""订单详情""知识库文档"。

Prompts（提示词模板）——预定义的交互模板。比如"代码审查模板""翻译模板"。

任何工具，只要按照MCP规范暴露这三个能力，任何AI应用就能直接调用。不需要为每个AI框架写适配层。

---

MCP的架构长什么样

MCP的架构分为两层：

┌─────────────┐    MCP协议    ┌─────────────┐ │  MCP Client  │ ◄──────────► │  MCP Server  │ │  (AI应用)    │    stdio/    │  (工具提供方) │ │              │    HTTP+SSE  │              │ │ Claude Desktop│              │  数据库Server │ │ Cursor       │              │  API Server   │ │ 自研Agent    │              │  文件Server   │ └─────────────┘              └─────────────┘

MCP Client是AI应用这一端——Claude Desktop、Cursor、或者你自己开发的Agent。

MCP Server是工具提供方这一端——暴露数据库查询、API调用、文件操作等能力。

Client和Server之间通过两种方式通信：

• stdio
  本地运行，Server作为子进程，通过标准输入输出通信
• HTTP+SSE
  远程运行，Server部署在服务器上，通过HTTP通信

一个Client可以同时连接多个Server。一个Server也可以被多个Client使用。

这就是MCP的核心价值：一次封装，到处调用。

---

实战：用Python写一个MCP Server

说了这么多原理，来点实际的。我写一个最简单的MCP Server，暴露两个工具：

1. get_weather
   ——查询城市天气（模拟数据）
2. calculate
   ——数学计算

from mcp.server.fastmcp import FastMCP  mcp = FastMCP("weather-and-calc")  WEATHER_DATA = {  "北京": {"temp": 28, "condition": "晴", "humidity": 35},  "上海": {"temp": 31, "condition": "多云", "humidity": 72},  "广州": {"temp": 33, "condition": "雷阵雨", "humidity": 85},  "深圳": {"temp": 32, "condition": "阵雨", "humidity": 80}, }  @mcp.tool() def get_weather(city: str) -> str:  """查询指定城市的天气信息"""  if city in WEATHER_DATA:  data = WEATHER_DATA[city]  return f"{city}：{data['condition']}，温度{data['temp']}°C，湿度{data['humidity']}%"  return f"暂无{city}的天气数据"  @mcp.tool() def calculate(expression: str) -> str:  """计算数学表达式，例如 '2+3*4'"""  try:  result = eval(expression, {"__builtins__": {}}, {})  return f"{expression} = {result}"  except Exception as e:  return f"计算错误：{e}"  if __name__ == "__main__":  mcp.run()

运行方式：

pip install mcp python weather_server.py

在Claude Desktop的配置文件中添加：

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

重启Claude Desktop，你就能在对话中让AI调用这两个工具了。AI会自动判断什么时候需要调用哪个工具，你不需要写任何触发逻辑。

---

我用MCP接入了公司5个内部系统

回到开头说的那个AI Agent项目。

我需要接入的系统：

• 内部工单系统（REST API）
• 客户数据库（PostgreSQL）
• 知识库（Elasticsearch）
• 通知服务（邮件+短信）
• 文档存储（MinIO）

以前的做法是写5套适配层，每套处理认证、错误重试、结果解析。

用MCP之后，我写了5个独立的MCP Server，每个Server只负责一件事：

mcp = FastMCP("ticket-system")  @mcp.tool() def create_ticket(title: str, description: str, priority: str) -> str:  """创建工单"""  resp = requests.post(  "https://ticket.internal/api/tickets",  json={"title": title, "desc": description, "priority": priority},  headers={"Authorization": f"Bearer {API_TOKEN}"}  )  return f"工单已创建，编号：{resp.json()['id']}"  @mcp.tool() def query_ticket(ticket_id: str) -> str:  """查询工单状态"""  resp = requests.get(  f"https://ticket.internal/api/tickets/{ticket_id}",  headers={"Authorization": f"Bearer {API_TOKEN}"}  )  data = resp.json()  return f"工单{ticket_id}：状态={data['status']}，负责人={data['assignee']}"

5个Server加起来不到200行代码。Agent那边只需要在配置里声明连接哪些Server，就能自动发现和调用所有工具。

核心好处：

1. 解耦
   ——工具提供方和AI应用完全分离，改工具不影响Agent代码
2. 复用
   ——同一个Server可以被多个Agent使用，不用重复开发
3. 可组合
   ——不同Server的工具可以组合使用，比如"查订单+发通知"一条链路搞定
4. 可独立迭代
   ——升级工单系统的Server，不影响数据库的Server

---

MCP vs Function-Calling：什么关系

很多人会问：MCP和我之前用的Function-Calling有什么区别？

简单说：

Function-Calling是"AI怎么调用工具"的协议——定义了AI输出函数调用的格式。

MCP是"工具怎么暴露给AI"的协议——定义了工具注册、发现、调用的标准。

打个比方：Function-Calling定义了"插头的形状"，MCP定义了"插座的形状+电压标准"。

它们不是替代关系，而是互补关系：

• 你用MCP暴露工具（定义插座）
• AI用Function-Calling调用工具（插入插头）

实际开发中，MCP Server底层可以对接任何AI框架的Function-Calling——OpenAI的、Anthropic的、Google的都行。MCP做的是把"工具暴露"这层标准化了，让工具不再绑定某个特定AI框架。

---

MCP目前的局限

说好处也得说问题。MCP现在并不完美：

1. 生态还在早期

目前支持MCP的AI应用主要是Claude Desktop、Cursor等少数产品。OpenAI官方还没宣布支持MCP，虽然社区已经在做OpenAI-MCP的桥接方案。

2. 远程部署的安全问题

MCP的stdio模式很安全（本地进程通信），但HTTP+SSE模式意味着你要把工具暴露到网络上。认证机制目前还在完善中，生产环境需要额外加网关和安全层。

3. 调试工具不成熟

Server出问题时，排查手段有限。目前主要靠日志和手动测试，还没有成熟的MCP调试工具链。

4. 状态管理是灰色地带

MCP本身是无状态的，但很多工具需要状态（比如数据库连接池、认证Token刷新）。怎么在MCP框架内优雅地管理状态，目前社区还在探索。

---

谁应该关注MCP

如果你是以下几类人，MCP值得你现在就开始了解：

AI应用开发者——你在做Agent、做RAG、做AI工具集成，MCP能让你少写大量胶水代码。

工具/平台开发者——你有一个内部系统想让AI调用，用MCP封装一次，所有支持MCP的AI应用都能直接用。

技术管理者——你在规划AI基础设施，MCP是工具层的标准化方向，值得纳入技术路线图。

---

MCP解决的不是一个技术难题，而是一个工程混乱问题。在AI能力飞速迭代的今天，工具集成的标准化比某个具体功能更重要。

USB用了20年才成为通用标准。MCP不需要那么久——因为AI的工具调用需求比外设连接更迫切，生态收敛的速度会更快。

你今天花2小时写一个MCP Server，明天就能被任何一个支持MCP的AI应用调用。这种一次封装到处调用的体验，用过就回不去了