在上一篇《Context Engineering》中，我们讨论了一个问题：
Agent 想要把事情做好，不仅需要一个足够强的模型，还需要正确的 Context。
但 Context 解决的主要是「让 Agent 知道什么」。
还有一个问题没有解决：
Agent 怎么真正去做事情？
例如，一个 Coding Agent 需要读取代码、修改文件、执行测试；一个企业 Agent 需要查询数据库、读取 CRM、发送邮件；一个知识库 Agent 需要搜索文档、查询向量数据库。
最直接的办法当然是给 Agent 接 API。
但当工具越来越多，问题很快就出现了。
每个 AI 应用都有自己的工具接入方式，每个工具都有自己的参数定义和调用方式。开发者需要为不同的模型、不同的 Agent、不同的应用重复做适配。
MCP 正是在这样的背景下出现的。
MCP 全称是 Model Context Protocol（模型上下文协议），是一个用于标准化 AI 应用与外部系统连接的开放协议。官方文档目前将它定义为连接 AI 应用与外部系统的开放标准，并围绕 Tools、Resources、Prompts 等能力建立协议规范。
如果把 Agent 看成一个需要不断获取信息和执行操作的软件，那么 MCP 解决的核心问题可以简单概括为：
如何用一种标准方式，让 AI 应用发现、理解并使用外部能力。
1. AI Agent 为什么需要“工具协议”
先不考虑 MCP。
假设我们正在开发一个 AI Agent，它需要操作 GitHub。
最简单的方式是：
Agent
↓
GitHub API
↓
GitHub
然后我们又希望它能够查询 MySQL：
Agent
↓
MySQL API / 自定义代码
↓
MySQL
再增加一个文件系统：
Agent
↓
Filesystem API
↓
File System
再增加 Slack、Notion、Jira、浏览器……
最后很容易变成：
┌── GitHub
│
├── MySQL
│
AI Application ─────┼── Slack
│
├── Notion
│
├── Browser
│
└── File System
真正麻烦的地方不是这些 API 本身，而是每个 AI 应用都需要自己做一遍连接和适配。
如果有 10 个 AI 应用、100 个工具，理论上就会产生大量重复的集成工作。
MCP 想解决的就是这一层问题：
┌── GitHub MCP Server
│
├── MySQL MCP Server
│
AI Application ─ MCP ┼── Slack MCP Server
│
├── Notion MCP Server
│
└── FileSystem MCP Server
于是 AI 应用不需要为每个系统重新设计一套完全不同的工具接入机制，而是通过 MCP 与符合协议的 Server 通信。
这就是 MCP 最核心的价值：
把“AI 如何连接外部能力”从各个应用自己的实现，逐渐变成一个标准化的协议层。
Anthropic 在 2024 年首次公开 MCP 时，就将它定位为连接 AI 应用与外部数据源、工具的开放标准。到 2025 年 12 月，Anthropic 又将 MCP 捐赠给 Linux Foundation 旗下的 Agentic AI Foundation，并明确推动其向开放、社区驱动和厂商中立的方向发展。
2. MCP 到底解决了什么
理解 MCP，最容易犯的错误是把它理解成：
「一个让 LLM 调用 API 的协议。」
这句话并不完全错误，但太窄了。
MCP 的目标实际上是标准化 AI 应用如何向模型提供 Context 和能力。
目前 MCP Server 的核心能力包括：
MCP Server
│
├── Tools
│
├── Resources
│
└── Prompts
它们分别解决不同问题。
2.1 Tools
Tools 是 Agent 可以调用的操作。
例如：
search_code
read_file
write_file
run_test
query_database
create_issue
send_message
MCP 规范把 Tool 定义为 Server 暴露给模型调用的函数，并要求工具具有名称以及描述其输入参数的 Schema。
2.2 Resources
Resources 更接近「可以被读取的上下文或数据」。
例如：
file://project/README.md
file://project/package.json
database://schema/users
docs://api/auth
它们并不一定意味着「执行一个动作」，而是为 AI 应用提供可以读取和使用的 Context。
2.3 Prompts
Prompts 是可复用的提示模板和工作流。
例如：
review-code
debug-error
generate-report
analyze-database
它可以让 MCP Server 向客户端提供结构化、可复用的 Prompt 模板。
因此：
Tools
→ 做什么
Resources
→ 看什么
Prompts
→ 怎么开始一个任务
虽然这个理解是简化后的，但对于初学 MCP 非常有帮助。
MCP 官方规范也明确将 Resources、Prompts 和 Tools 作为 Server 侧的核心能力。
3. MCP 的基本架构是什么
MCP 的架构可以先简单理解成：
┌───────────────────────────────┐
│ AI Application │
│ │
│ Claude / IDE / Agent / App │
└───────────────┬───────────────┘
│
MCP Client
│
MCP Protocol
│
┌───────────────▼───────────────┐
│ MCP Server │
│ │
│ Tools / Resources / Prompts │
└───────────────┬───────────────┘
│
┌───────┼────────┐
↓ ↓ ↓
GitHub MySQL Files
这里有三个角色需要区分。
Host / AI Application
就是最终承载 AI 能力的应用，例如一个 AI IDE、桌面 AI 应用或者 Agent 平台。
MCP Client
负责在 Host 内部与 MCP Server 建立 MCP 通信。
MCP Server
负责把自己的工具、资源或 Prompt 暴露给 MCP Client。
因此，MCP 并不是：
LLM
↓
MCP
↓
Database
更准确的关系是：
AI Application
│
│ MCP Client
│
│ MCP Protocol
↓
MCP Server
│
├── Tool
├── Resource
└── Prompt
│
↓
External System
官方架构文档也是按照 Host、Client、Server 以及协议层来描述 MCP 的整体架构。
4. MCP 和 API 到底有什么区别
这是理解 MCP 最重要的问题之一。
因为 MCP Server 背后通常还是在调用 API、数据库、文件系统或者其他程序，所以很多人会问：
「我已经有 API 了，为什么还需要 MCP？」
关键在于它们解决的问题不同。
API 主要解决：
软件和软件之间如何进行通信。
例如：
POST /api/orders/refund
调用方需要知道：
URL
HTTP Method
Authentication
Headers
Request Schema
Response Schema
Error Handling
而 MCP 更关注：
AI 应用如何发现、理解和使用这些能力。
例如一个 MCP Tool：
refund_order
它可以提供：
名称：
refund_order
描述：
对指定订单执行退款。
参数：
order_id
amount
reason
这样 Agent 就可以根据 Tool 的名称、描述和 Schema 判断：
当前任务需要退款
↓
发现 refund_order
↓
理解参数
↓
生成参数
↓
调用 Tool
所以可以简单理解：
API
↓
定义软件能力
MCP
↓
定义 AI 应用如何发现和使用这些能力
MCP Server 甚至完全可以把现有 API 包装成 MCP Tool。
例如：
已有系统
Order API
↓
POST /orders/refund
MCP Server
↓
refund_order Tool
↓
Order API
因此 MCP 并不是 API 的替代品。
很多情况下，它反而是建立在现有 API 之上的一层 AI 原生适配层。
5. MCP 和 Function Calling 又是什么关系
另一个容易混淆的概念是 Function Calling。
Function Calling 解决的问题是：
让模型产生结构化的函数调用请求。
例如模型可能产生：
{
"name": "get_weather",
"arguments": {
"city": "Tokyo"
}
}
你的应用拿到这个调用请求后，再执行真正的函数。
所以一个简单的 Function Calling 流程是：
User
↓
LLM
↓
Function Call
↓
Application
↓
Function
↓
Result
↓
LLM
而 MCP 关注的是另一层：
AI Application
↓
MCP Client
↓
MCP Server
↓
Tools / Resources / Prompts
↓
External Systems
因此它们不是完全竞争关系。
可以把它们理解成不同层次：
Function Calling
↓
模型如何表达“我要调用某个函数”
MCP
↓
AI 应用如何标准化发现和连接外部能力
一个 MCP Tool 最终仍然可能被 AI 应用转换成模型能够理解的工具定义，然后通过模型的 Tool Calling 能力完成调用。
所以：
Function Calling 是模型调用工具的一种机制；MCP 是连接 AI 应用与外部工具、数据和上下文的一套开放协议。
这个区别非常重要。
6. 一个 MCP Tool 是怎么被调用的
假设我们有一个简单的 MCP Server：
MCP Server
└── search_document
它提供：
name:
search_document
description:
搜索知识库中的相关文档。
input:
{
"query": "string",
"limit": "integer"
}
用户问：
MySQL InnoDB 的 Buffer Pool 是做什么的？
Agent 判断需要搜索知识库。
大致流程可以理解为：
User
↓
AI Application
↓
LLM 判断需要知识检索
↓
选择 search_document
↓
生成参数
↓
MCP Client
↓
MCP Server
↓
search_document()
↓
Knowledge Base
↓
返回搜索结果
↓
AI Application
↓
LLM
↓
生成最终答案
如果是 Coding Agent，则可能变成：
用户：
修复 UserService 的测试。
Agent
↓
搜索代码
↓
read_file
↓
修改代码
↓
write_file
↓
执行测试
↓
run_test
↓
获取结果
↓
继续修复
这时候 MCP 的价值就变得非常明显。
它让 Agent 面对的不是几十套完全不同的集成方式，而是一个相对统一的工具发现和调用模型。
7. MCP 为什么特别适合 Agent
在上一篇文章中我们讲过，Agent 与普通 Chatbot 最大的区别之一，是 Agent 不只是回答问题，而是可以：
理解任务
↓
制定计划
↓
调用工具
↓
观察结果
↓
继续行动
所以 Agent 的能力实际上取决于两个方面：
Agent
├── Reasoning
└── Tools
没有工具，Agent 很多时候只能「建议」。
有工具，Agent 才能真正「行动」。
例如：
没有工具：
“你可以运行 PHPUnit 检查代码。”
有工具：
Agent
↓
调用 PHPUnit
↓
获得测试结果
↓
分析错误
↓
修改代码
↓
重新测试
因此，随着 Agent 能够使用的工具越来越多，工具接入本身就会变成一个基础设施问题。
MCP 正好提供了一种标准化方式。
Anthropic 在 MCP 的工程实践中也将它描述为连接 AI Agent 与外部系统的开放标准，并展示了 MCP 在大量工具场景中的应用。
8. MCP 为什么不是简单的“万能 API 插件”
如果把 MCP 只理解成：
API
↓
MCP Server
↓
LLM
实际上低估了它。
MCP 的重要意义在于，它正在尝试建立一套围绕 Agent 的通用连接协议。
例如一个 AI 应用可以连接：
GitHub MCP
PostgreSQL MCP
Filesystem MCP
Slack MCP
Notion MCP
Sentry MCP
Browser MCP
然后 Agent 面对的是：
Tools
Resources
Prompts
而不是需要理解每个系统完全不同的集成方式。
这也是 MCP 生态快速发展的重要原因。
截至 2025 年底，Anthropic 表示 MCP 已经被 ChatGPT、Cursor、Gemini、Microsoft Copilot、Visual Studio Code 等多个 AI 产品采用，并有超过 10,000 个公开 MCP Server；同一时期，Anthropic 将 MCP 捐赠给 Linux Foundation 旗下的 Agentic AI Foundation。
这些数据说明 MCP 已经不再只是 Anthropic 自己的一个实验性接口。
但这里也应该保持一个技术判断：
MCP 已经形成了广泛生态，并不意味着它已经成为所有 AI 应用唯一的标准。
AI Agent 的协议和工具生态仍然在快速演进。
因此，更准确的说法是：
MCP 正在成为 AI 应用连接外部工具和上下文的重要开放协议之一。
而不是简单宣布：
「MCP 已经统一了整个 AI 世界。」
9. MCP 的真正价值在哪里
如果只从技术实现来看，MCP 并没有神奇到可以解决所有问题。
它真正有价值的地方，是把一个过去高度分散的问题标准化。
以前：
Claude
├── GitHub Adapter
├── MySQL Adapter
├── Slack Adapter
└── Custom Adapter
Cursor
├── GitHub Adapter
├── MySQL Adapter
├── Slack Adapter
└── Custom Adapter
Other Agent
├── GitHub Adapter
├── MySQL Adapter
├── Slack Adapter
└── Custom Adapter
大量重复。
MCP 希望变成：
MCP
│
┌──────────┼──────────┐
↓ ↓ ↓
GitHub MySQL Slack
Server Server Server
然后不同 AI 应用都可以接入这些 MCP Server。
这实际上很像软件生态中曾经出现过的一个非常重要的规律：
当连接数量开始快速增长时，标准化接口的价值往往会越来越高。
MCP 的意义也正在这里。
它不是让 GitHub、MySQL、Slack 本身发生变化，而是让它们能够以更统一的方式成为 Agent 可以使用的能力。
10. MCP 还远没有结束
MCP 当前已经覆盖 Tools、Resources、Prompts、授权、传输等多个方面，规范也仍在持续演进。官方规范目前的 2025-11-25 版本已经包含异步操作、授权、Server Identity 等能力，而官方 Roadmap 也继续讨论事件驱动更新等未来方向。
这意味着 MCP 后续面对的问题已经不只是：
“怎么调用一个工具？”
而会越来越接近：
工具怎么设计？
工具怎么发现？
工具太多怎么办？
工具权限怎么控制？
工具调用如何审计？
工具结果如何进入 Context？
多个 Agent 怎么共享工具？
长时间运行的 Agent 怎么管理工具状态？
这些问题，实际上已经开始进入 MCP 的工程实践。
尤其值得注意的是：
工具数量本身也可能成为 Context 的负担。
如果一个 Agent 同时连接大量 MCP Server，每个工具的名称、描述和参数 Schema 都需要被模型理解，工具定义本身就会占用 Context。因此，MCP 的下一阶段并不只是「连接更多工具」，而是如何让 Agent 在大量工具中高效发现和选择真正需要的工具。Anthropic 也已经针对大量工具场景推出 Tool Search、Programmatic Tool Calling 等能力。
这又回到了上一篇文章讨论的 Context Engineering：
Agent
↓
需要工具
↓
MCP
↓
获得大量 Tools
↓
Context 变大
↓
需要更好的 Context Engineering
所以这几篇文章实际上是连在一起的。
11. MCP 真正改变的是什么
到这里，可以重新回答最开始的问题：
为什么 AI Agent 需要一个“工具协议”？
因为 Agent 的能力正在从「生成文本」转向「使用外部世界」。
它需要访问：
代码
文件
数据库
API
知识库
浏览器
企业系统
云资源
如果每一个 AI 应用都自己实现一套连接方式，生态最终会变得非常复杂。
MCP 的目标，就是在 AI 应用与这些外部能力之间增加一个标准化协议层：
AI Agent
│
AI Application
│
MCP Client
│
Model Context Protocol
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Tools Resources Prompts
│ │ │
↓ ↓ ↓
GitHub Docs Workflow
Database Files Templates
API Knowledge Instructions
所以，MCP 最值得关注的并不是它有多少个 API，也不是某个 MCP Server 有多少功能。
真正值得关注的是：
AI 正在从“调用几个预先写死的函数”，走向“动态发现并使用一个庞大的外部能力生态”。
MCP 正是在解决这个生态中的连接问题。