MCP协议全解析：AI的万能插座

来源：互联网 2026-07-23 06:36:14

AI资讯合集

MCP协议作为AI工具接入的开放标准，解决了应用与工具间的N×M适配问题。其三层架构（宿主、客户端、服务器）定义了工具发现与通信规范，提供工具、资源、提示词模板和反向采样四种能力。自2024年11月发布后，生态迅速扩展，2025年底被捐赠给Linux基金会，成为行业基础设施。

AI 工具越来越多，接入却越来越麻烦——每个 AI 应用都要单独适配每个工具，开发者快被搞崩溃了。MCP 就是来解决这个问题的。

你用过 Cursor 帮你查 GitHub 代码、用过 Claude 帮你读 Notion 文档、用过 Copilot 帮你查数据库吗？

长期稳定更新的攒劲资源： >>>点此立即查看<<<

这些背后都有一个隐形的苦力：工具接入。

没有统一标准之前，每家 AI 应用想接入一个外部工具，都要从头写一套适配代码。10 个 AI 应用 × 10 个工具 = 100 套独立接口，每个都长得不一样。

这就是工程师界著名的"N×M 问题"。

Anthropic 在 2024 年 11 月提出了解法：MCP（Model Context Protocol，模型上下文协议）。

一句话理解：MCP 是给 AI 工具世界制定的"USB 标准"——插进去就能用，不用管谁造的。

什么是 MCP？

MCP 是一套开放标准协议，定义了 AI 应用（Host）和外部工具/数据（Server）之间怎么"说话"。

你可以把它想象成家里的插座规格。以前每台电器都有自己的专属插孔，换个品牌就要换插座；有了统一的国标插座规格，所有设备按规格生产，插进去就能用。

MCP 做的正是这件事：

反面：每个 AI 应用单独写代码接入 GitHub、Slack、数据库……改一处、全乱套
有了 MCP：任何工具只要做成 MCP Server，任何 AI 应用就能直接用

MCP协议全解析：AI的万能插座

MCP 的三层架构

MCP 把整个系统拆成三个角色，分工明确：

MCP Host（宿主）就是你用的 AI 应用本体，比如 Claude Desktop、Cursor、VS Code。它负责统筹全局，管理与各个工具的连接。

MCP Client（客户端）内嵌在 Host 里的"连接器"，专门负责和 MCP Server 通话，把服务器提供的工具和数据传给 AI。

MCP Server（服务器）真正和外部系统打交道的程序。比如 GitHub MCP Server 负责读代码仓库，Notion MCP Server 负责读文档，数据库 MCP Server 负责查数据库。

用个更接地气的比喻：你（Host）要查资料，助理（Client）负责帮你打电话，图书馆（Server）负责找书给你——三方各司其职，谁也不越位。

MCP协议全解析：AI的万能插座

MCP 能给 AI 提供四种能力

MCP 定义了四类"原语"，每种原语解决不同的问题：

1. Tools（工具）——让 AI 能"动手"

可执行的动作：查数据库、发消息、创建文件、调用接口。这是最常用的原语，也是最有"副作用"的——执行后会真实改变外部系统。

2. Resources（资源）——让 AI 能"看数据"

只读的上下文来源：文件内容、日志片段、数据库记录、配置信息。AI 不需要执行操作，只需要读取相关信息来理解背景。

3. Prompts（提示词模板）——让 AI 有"作业模板"

Server 提供预定义的提示词模板。比如代码审查 MCP Server 内置了"审查规范模板"，调用时自动带上最佳实践要求，不用每次重写。

4. Sampling（反向采样）——让 Server 能"请 AI 帮忙"

这个最容易被忽视，也最有意思：Server 可以反过来请求 Host 的 AI 做一次推理。比如日志分析 Server 读到异常日志后，自己调不了模型，就通过 Sampling 请宿主 AI 帮忙做个摘要分类。这是 MCP 让系统真正"双向智能"的关键。

MCP vs Function Calling：不是同一层的事

这是很多人最容易混淆的地方。

Function Calling（函数调用）解决的是：模型如何用结构化 JSON 表达"我要调什么工具、参数是什么"。

MCP解决的是：这个调用如何真正"接"到外部系统上——工具从哪来、怎么被发现、怎么通信。

三层关系清晰地摞在一起：

┌─────────────────────────────────────────────┐
│Agent 层：任务怎么规划、循环执行                 │
├─────────────────────────────────────────────┤
│MCP 层：工具从哪来、怎么发现、怎么接入           │
├─────────────────────────────────────────────┤
│Function Calling 层：模型怎么表达调用意图        │
└─────────────────────────────────────────────┘

换个说法：

Function Calling = 前端发出了一个请求
MCP = 定义请求该怎么格式化、路由到哪、怎么鉴权的 REST 规范

OpenAI 早就有 Function Calling，但在 2025 年 3 月依然主动支持了 MCP——原因正在于此，它们解决不同层的问题，并不冲突。

一次完整的 MCP 调用长什么样？

以"用 AI 审查 GitHub PR"为例：

① 你问：帮我审查这个 PR，重点检查安全漏洞

② 模型判断：需要读 PR 差分（Tool）
   读相关代码（Resource）
   使用审查模板（Prompt）

③ Host 通过 MCP Client 向 GitHub MCP Server 发起请求

④ Server 读取 PR 差分 → 读取关联文件 → 加载审查 Prompt 模板

⑤ 结果全部传回模型

⑥ 模型生成完整的安全审查报告

⑦ 如有疑问，模型继续发起工具调用循环直到任务完成

全程一次认证，多步操作；而传统 REST API 每一步都要重新认证、重传上下文。

MCP 的生态有多大？

这个数字能说明问题：

时间	公开 MCP Server 数量	月均 SDK 下载量
2024 年 11 月（发布时）	~100 个	—
2025 年 5 月	>4,000 个	—
2025 年 12 月	>10,000 个	9,700 万次

从发布到主要玩家全面采纳，MCP 只用了不到一年：

2024.11：Anthropic 发布 MCP，同步开放 GitHub、Slack、PostgreSQL 参考实现
2025.03：OpenAI 在 ChatGPT 和 API 中正式支持 MCP
2025.04：Google 将 MCP 集成到 Gemini（AI Studio & Vertex AI）
2025年：Microsoft 在 VS Code、Azure OpenAI、Copilot Studio 全面支持
2025.12：Anthropic 将 MCP 捐赠给 Linux Foundation，成立 AAIF（Agentic AI Foundation），AWS、Google、Microsoft、OpenAI 共同加入

捐赠给中立基金会是个关键信号：MCP 已经不是 Anthropic 的私有标准，而是整个行业的基础设施。

MCP协议全解析：AI的万能插座

使用 MCP 的三个实操建议

1. 把 description 当说明书来写

MCP Server 里每个工具的 description，是模型决定"要不要调这个工具"的唯一依据。

反面：description: "读文件"

改成：description: "读取本地文件内容，适合需要查看源码、配置、日志的场景。不适合读取超过 10MB 的大文件，超大文件请先用 get_file_info 获取摘要。"

描述越清晰，模型调用越准确，幻觉越少。

2. 写操作加"确认门"

删除、发邮件、提交代码这类写操作，不要让模型直接执行。最简单的做法：在 Tool 定义里加一个 require_confirmation: true 字段，让 Host 在执行前提示用户确认一次。有了 Elicitation 原语（2025.06 新增），Server 可以原生向用户追问信息，不用手动实现。