MCP 扩展（Extension）解决的是”协议层如何叠加可选能力”，而内置工具（如 Claude Code 的 Read、Bash、Grep、Glob）解决的是”宿主本身要原生支持哪些动作”。两者不在同一层：扩展是协议侧的加法，内置工具是宿主侧的原生能力。一条粗略的边界——只要改动需要让客户端与服务器在握手时协商、且不识别方要能优雅降级，就属于扩展；只要改动只发生在某个宿主内部、对其他客户端无意义，就属于内置工具。下面从定位、机制、边界、协作四方面展开。
一、扩展与内置工具的根本差异
MCP 扩展是 Model Context Protocol 协议层定义的”可选模式”，由 SEP（Specification Enhancement Proposal）流程管理，跨所有客户端与服务器生效。内置工具是某个 AI 宿主（如 Claude Code、Cursor、Windsurf）自己实现的命令，对其他宿主完全不可见。
| 维度 | MCP 扩展 | 宿主内置工具 |
|---|---|---|
| 所属层 | 协议层 | 宿主应用层 |
| 谁实现 | 任何遵循协议的客户端/服务器 | 单个宿主 |
| 跨宿主可见 | 是 | 否 |
| 协商机制 | 初始化握手时声明 capability | 宿主硬编码 |
| 识别失败 | 优雅降级，跳过该扩展 | 不存在 |
| 典型例子 | MCP Apps、Tasks、OAuth Client Credentials | Claude Code 的 Read / Bash / Grep / Glob |
扩展的”扩展性”体现在它能横向铺到所有客户端，而内置工具的”内置性”体现在它只能在该宿主内部用。两者的能力范围完全不同。
二、扩展的三大类别
MCP 官方把扩展分成三类，分别对应不同成熟度与适用面。
| 类别 | 含义 | 典型扩展 |
|---|---|---|
| Official | 官方维护、SEP 流程审批、跨生态可用 | MCP Apps、Tasks、OAuth Client Credentials、Enterprise-Managed Authorization |
| Experimental | 工作组孵化中，可能升为 Official 也可能废弃 | experimental-ext-interceptors 等 |
| Custom | 第三方自行定义，使用反向域名前缀 | com.example/my-extension |
任何扩展都有三个不变的特征：必须有 RFC 2119 语言书写的规范、必须有对应的标识符（{vendor-prefix}/{extension-name}）、必须经过握手协商。不满足这三条的不能算扩展，只能算”私有协议”。
三、内置工具的常见范畴
不同宿主提供的内置工具不完全一致，但大体集中在四类能力上：文件操作、命令执行、搜索检索、对话元能力。
Claude Code 内置工具（典型集合）
├── 文件类：Read、Write、Edit、MultiEdit
├── 命令类：Bash（含白名单与超时控制）
├── 搜索类：Grep、Glob
├── 会话类：TodoWrite、Task
└── 协议类：MCP 连接管理这些工具的共同特征是”宿主说了算”——是否提供 Read、是否允许 Bash、是否要二次确认，都由宿主的产品决策决定。一个宿主即使不识别某个 MCP 扩展，也照样能跑；而一个宿主如果把 Read 工具关掉，模型就只能借助 MCP 协议去找外部服务器代替。
四、四条边界判定准则
判断一项能力应该走扩展还是走内置工具，可以按下面四条逐条核验：
- 是否需要多端互通：如果只有某一个宿主要用，其他宿主用不到，放内置更省事；如果多个宿主都要用，必须走扩展。
- 是否需要握手协商：如果客户端不识别就要降级或失败，必须有 capability 声明，这就是扩展；如果只在宿主内部生效，握手协商无意义。
- 是否会改变协议消息结构：如果加了新的 JSON-RPC method、新的 result 字段、新的 metadata key，必须走扩展；如果只是工具内部逻辑变了，跟协议无关，放内置。
- 是否需要 SEP 流程治理：如果改动会影响所有 MCP 实现，需要走 SEP；只在单个宿主里改，宿主自己决定。
举例：MCP Apps 改变了 tools/call 的返回（多了 UI payload），跨多个宿主都需要用，因此是扩展。Claude Code 的 TodoWrite 工具只是宿主内部的任务列表，不影响其他宿主，因此是内置工具。
五、扩展、内置工具与 MCP 服务器三者的协作
实际工程里，扩展、内置工具、外部 MCP 服务器经常配合工作。举一个完整的链路：用户让 AI 改一个文件的某一行。
| 步骤 | 角色 | 实际组件 |
|---|---|---|
| 1. 找到目标文件 | 内置工具 | Glob 匹配路径 |
| 2. 读取当前内容 | 内置工具 | Read |
| 3. 检索全仓类似代码 | MCP 服务器 | grep / ripgrep MCP |
| 4. 计算 patch | 内置工具 | Edit |
| 5. 跑测试验证 | 内置工具或 MCP | Bash 或测试 MCP |
| 6. 异步长任务 | 扩展 | Tasks（实验性扩展） |
| 7. 展示可视化结果 | 扩展 | MCP Apps |
这条链路说明：内置工具是底座，外部 MCP 服务器是补充，扩展是横向能力层。混用没有冲突，因为扩展只规定协议层多出来的能力，宿主仍然可以同时跑自己的内置工具。
六、扩展的协商与降级机制
扩展在初始化握手时通过 extensions 字段声明，结构如下：
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2026-07-28",
"capabilities": {
"extensions": {
"io.modelcontextprotocol/ui": {
"mimeTypes": ["text/html", "application/vnd.mcp-ui+json"]
}
}
}
}
}两端都声明某个扩展时才启用；任一端不识别，直接跳过该扩展、回到核心协议。这一条”严格可选、严格加法”的设计，是扩展与内置工具最关键的差别：内置工具不存在”客户端不识别”问题，扩展必须考虑识别失败。
七、设计建议：什么情况下别自己造扩展
扩展的代价是维护成本——一旦标识符发布出去就要长期兼容。以下情况建议留在内置或私有实现层：
- 仅你的宿主使用，跨端没有需求；
- 实现细节未稳定，半年内可能大改；
- 涉及宿主特定的安全审批模型，外部客户端用不上。
反过来，如果功能是”任何一个 MCP 实现都可能想用”（如异步任务、可视化、鉴权流程），就该走扩展流程。
常见问题（FAQ）
Q1：扩展和 MCP 服务器有什么区别？
服务器是能力提供方，扩展是协议能力声明；扩展改变握手消息，服务器只提供 tools/resources/prompts。
Q2：内置工具调用失败能降级到扩展吗？
不能。内置工具是宿主决定的，扩展是协议层可选能力，两者没有降级关系，只能互为补充。
Q3：扩展标识符改了算破坏性变更吗？
算。规范要求破坏性变更必须换新标识符，不能原地改字段语义。
