MCP是什么 为什么2026年每个AI开发者都需要了解它

我去年帮一个客户做AI助手，需求很简单，让Claude能查公司内部的工单系统。我兴冲冲写了一堆function calling的函数，接通那天演示得很顺。结果第二周客户说想换ChatGPT，第三周又想接Cursor。每换一个宿主，我那套工具定义就得重写一遍，参数格式、调用约定全都不一样。那段时间我加班到凌晨两点，盯着屏幕上三个版本的胶水代码，心里只有一个念头，这事儿不该这么难。

后来我接触到MCP，第一次跑通一个Server，五分钟接进了Claude Desktop，又花两分钟接进了Cursor，同一份代码，一行没改。那一刻我意识到，这个东西会改变AI应用接外部系统的方式。这篇我想跟你聊聊MCP到底是个啥，它解决了什么老问题，以及为什么我认为2026年搞AI开发绕不开它。

---

先搞清楚MCP是什么

MCP全称Model Context Protocol，模型上下文协议。Anthropic在2024年底开源发布，目前最新协议版本是2025-06-18。官方给了一个很形象的比喻，MCP之于AI应用，就像USB-C之于电子设备。USB-C统一了充电和数据的接口，你不用再区分安卓线、苹果线、各种专有线。MCP统一了AI应用访问外部系统的方式，你不用再为每个AI宿主单独写一套对接代码。

从技术定义上说，MCP是一个开放标准，规定了AI应用如何连接数据源（比如本地文件、数据库）、工具（比如搜索引擎、计算器）和工作流（比如预设的提示模板）。Claude、ChatGPT、VS Code的Copilot、Cursor这些主流客户端都已经支持。写一次Server，到处都能接。

它本质上是一套基于JSON-RPC 2.0的通信协议。架构上有三个角色。

• MCP Host，宿主，也就是AI应用本身，比如Claude Desktop、Cursor。它负责协调管理多个MCP客户端。
• MCP Client，客户端，宿主内部为每个Server创建的一个连接维护者。
• MCP Server，服务端，真正提供上下文数据的程序，可以跑在本地，也可以跑在远程。

协议分两层。数据层定义消息结构和语义，用JSON-RPC 2.0收发请求。传输层负责具体的通信通道，目前支持两种，Stdio（标准输入输出，用于本地进程通信）和Streamable HTTP（用于远程通信）。两套传输用同一套消息格式，这就是为什么本地写的Server搬到远程几乎不用改逻辑。

MCP的发展时间线

我把这条线捋了一遍，方便你建立时间感。

2024年11月，Anthropic发布MCP规范和Python、TypeScript SDK，同时开源了一批参考Server实现，比如文件系统、GitHub、PostgreSQL。这一步定下了协议骨架。

2025年上半年，生态快速扩张。OpenAI宣布ChatGPT和Agents SDK支持MCP，微软把MCP接进了VS Code Copilot，Cursor、Zed等编辑器陆续跟进。社区里的Server数量从几十个涨到几千个。

2025年6月，协议版本更新到2025-06-18，完善了授权、流式传输等机制。远程Server用Streamable HTTP替换了旧的SSE传输，更贴近主流Web开发习惯。

到2026年的今天，MCP已经是事实标准。主流AI客户端几乎全部原生支持，你写的Server无需关心对方是哪家产品。

Function Calling的痛点在哪

要理解MCP的价值，得先看看我们以前怎么干的。Function Calling是OpenAI先带起来的能力，让模型能调用预定义的函数。思路没错，但工程上有个老问题一直没解决，碎片化。

我给你看一段典型的function calling代码，这是OpenAI风格。

# OpenAI风格的工具定义，每个宿主格式不同
import openai

# 工具schema要按OpenAI的格式手写
tools = [
    {
        "type": "function",
        "function": {
            "name": "search_tickets",
            "description": "按关键词搜索内部工单",
            "parameters": {
                "type": "object",
                "properties": {
                    "keyword": {"type": "string", "description": "搜索关键词"}
                },
                "required": ["keyword"],
            },
        },
    }
]

# 调用时还要自己处理模型返回的function call，再回填结果
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "查一下登录相关的工单"}],
    tools=tools,
)

问题在哪。第一，工具定义的schema格式各家不同。OpenAI是一套，Claude的tool use是另一套，Gemini又一套。你想同时支持三家，就得维护三份schema描述。

第二，工具的发现和调用逻辑全靠你自己写。模型返回一个调用意图，你得解析、执行、把结果塞回去。这部分胶水代码每个项目都要重写。

第三，工具没法复用。你给OpenAI写的搜索工具，没法直接给Cursor用，因为Cursor有自己的工具接入约定。同一个查工单能力，在三个地方写了三遍。

第四，状态管理混乱。工具运行时的上下文、错误处理、日志，全散落在业务代码里，没有统一规范。

这些痛点加在一起，导致每接一个新AI平台就是一次重复劳动。MCP就是来解决这个问题的。

MCP是怎么解决的

MCP的核心思路是标准化。它把"AI应用怎么发现工具、怎么调用工具、怎么拿到结果"这件事，变成一套公开协议。

回到上面那个查工单的需求，用MCP写出来是这样。

# 同一个能力，用MCP写一次，所有支持MCP的客户端都能用
from mcp.server.fastmcp import FastMCP

# 初始化一个MCP Server，名字随意
mcp = FastMCP("ticket-server")

# 用装饰器声明一个工具，类型注解和docstring会自动生成schema
@mcp.tool()
async def search_tickets(keyword: str) -> str:
    """按关键词搜索内部工单。

    Args:
        keyword: 搜索关键词，比如"登录失败"
    """
    # 这里换成你真实的查询逻辑
    results = await query_internal_db(keyword)
    return f"找到 {len(results)} 条相关工单"

# 以stdio方式运行，本地客户端会通过标准输入输出与之通信
if __name__ == "__main__":
    mcp.run(transport="stdio")

注意几个关键点。工具定义用的是Python原生的类型注解和docstring，FastMCP自动帮你生成符合MCP规范的JSON Schema，你不用手写。调用约定、结果回填、错误处理这些，协议全规定好了，客户端和Server各自按规范实现就行。

最重要的是，这段代码写完，Claude Desktop、Cursor、ChatGPT、VS Code Copilot都能接。你不用为任何一个改代码。这就是MCP的价值，写一次，到处接。

三大原语初识

MCP Server能向外提供三类东西，官方叫原语（primitives）。

• Tools，工具。AI可以调用的函数，比如发邮件、查数据库、调外部API。这是用得最多的一类，对应function calling的能力。
• Resources，资源。只读的数据源，比如一份配置文件、一个数据库表结构、一段API响应。客户端按URI去读，AI据此获取上下文。
• Prompts，提示模板。预定义的参数化消息模板，帮用户快速构造特定任务的对话，比如代码审查的提示词模板。

这三类原语各有适用场景，后续我会专门写一篇细讲。现在你只要记住，Tools是让AI动手做事，Resources是给AI看数据，Prompts是给AI定调子。三者搭配，一个Server就能覆盖大部分AI增强需求。

一个最小的对比

我把Function Calling和MCP放一起对比，差距很直观。

维度	Function Calling	MCP
工具定义格式	各家私有，互不兼容	统一协议规范
跨客户端复用	每家重写一遍	一份代码多端通用
工具发现机制	需自己维护工具列表	协议内置list/get方法
传输方式	依赖宿主SDK	Stdio和HTTP，标准通道
生态	各自为政	共享Server生态
状态管理	自定义	协议规定生命周期

简单说，Function Calling是能力，MCP是标准化的交付方式。两者不冲突，MCP底层照样让模型调用函数，但它把对接这件事标准化了，省掉了大量重复胶水代码。

常见问题与避坑

问题一，MCP要取代Function Calling吗。 不是。MCP底层依然依赖模型的功能调用能力，它解决的是工具怎么被发现、怎么被标准化交付的问题。你可以把MCP理解成Function Calling之上的传输和发现层。

问题二，学会了MCP就能让AI干任何事吗。 MCP只管协议层，具体能力取决于你Server里写了什么逻辑。它能帮你把能力标准化地交给AI，但能力本身还得你实现。

问题三，MCP只支持Claude吗。 早就不是了。ChatGPT、Cursor、VS Code Copilot、Zed都支持。生态已经跨出了Anthropic自家产品。

问题四，远程Server和本地Server有啥区别。 本地Server用Stdio，跑在你机器上，性能好但只能自己用。远程Server用Streamable HTTP，能服务多个客户端，适合团队共享，但要注意鉴权。

小结

MCP本质上是给AI应用和外部系统之间定了一个统一接口标准。它把过去每个项目都要重写的工具对接胶水代码，变成了可复用、可共享的Server。Function Calling解决了"AI能不能调用函数"的问题，MCP解决了"这些函数怎么被标准化交付和复用"的问题。协议版本已经迭代到2025-06-18，主流AI客户端基本全部支持。如果你的工作涉及让AI访问外部数据或工具，2026年这个协议值得花时间搞明白。

下一篇我会带你5分钟跑通第一个MCP Server，用Python从零写起，全程可运行代码。