把 Claude Code 看作一个运行在终端里的「智能体宿主」，MCP（Model Context Protocol）就是它向外延伸的标准化管道——负责把外部服务、数据库、API 转成模型可直接调用的工具；传统插件机制则是宿主内部的能力扩展包，二者落在完全不同的层。Anthropic 在公开材料中把 MCP 定位为「让模型连接外部系统的开放协议」，并通过 JSON-RPC 2.0 把每个外部服务抽象成可发现的工具集。
一、MCP 在 Claude Code 能力体系中的位置
MCP 解决的是「Claude 怎么伸手够到本地之外的东西」。没有 MCP，Claude 只能读写本地文件、跑 shell；接上 GitHub MCP 后它能开 PR，接上 Postgres MCP 后能跑 SQL，接上 Slack MCP 后能发消息。模型不再是「困在机器里的助手」，而是通过标准协议按需接入真实环境的执行者。
| 能力维度 | 没有 MCP 的 Claude Code | 接入 MCP 之后 |
|---|---|---|
| 可触达范围 | 本地文件、shell 命令 | 任意暴露 MCP Server 的外部服务 |
| 工具发现 | 内置工具枚举 | 启动时通过 JSON-RPC 拉取每个 Server 的工具列表 |
| 鉴权与凭据 | 走本地环境变量 | 由各 MCP Server 独立管理 token / scope |
| 上下文开销 | 低 | 视工具数量上升，可用 Tool Search 优化 |
| 协议形态 | 无 | JSON-RPC 2.0 over stdio / HTTP |
从工程视角看，MCP 把「工具描述（name、inputSchema）」和「工具调用（call）」统一成一种契约，模型只需看工具清单与参数 schema，就能像调用本地函数一样调用远端能力。这种契约不绑定具体业务，因此同一个 MCP Server 既能服务 Claude Code，也能被其他兼容协议的 Agent 复用。
二、MCP 的工作流程
MCP 的运行链路是「发现—匹配—调用—回填」四步，把外部世界翻译成模型能理解的工具语义。
- 启动发现：Claude Code 读取
~/.claude/settings.json或项目级.mcp.json，按command、args、env拉起各 MCP Server； - 工具枚举：每个 Server 把自己暴露的
tools列表通过 JSON-RPC 推回，模型据此建立mcp__<server>__<tool>形式的命名空间； - 计划匹配：用户提问后，模型在工具清单里挑选最匹配的工具，把自然语言意图映射成结构化参数；
- 执行回填：JSON-RPC 消息经 stdio 或 HTTP 发出，Server 调用真实 API，把结果原样回填到上下文。
下面这段配置展示了 GitHub MCP 的典型接法——command 用 npx 启动官方包，env 注入受限 token：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ghp_xxx" }
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
}
}
}配置完成后，模型会自动获得 mcp__github__list_issues、mcp__filesystem__read_file 之类工具，无需在系统提示里手写工具说明。
三、与传统插件机制的本质区别
传统插件（Plugin/Extension）以「宿主内可加载模块」为基本形态，通常通过 npm 包、动态链接库或脚本插件机制注入到主进程，强调扩展宿主本身的功能。Claude Code 中的 Plugin 走的是同一思路：把 Skills、Hooks、Subagents、MCP Server 一并打包成分发单元。
两者的差异集中在三个维度。
| 对比维度 | MCP | 传统插件 |
|---|---|---|
| 抽象层次 | 协议层（跨进程、跨语言） | 进程内模块（动态加载） |
| 通信方式 | JSON-RPC 2.0 over stdio / HTTP | 函数调用 / 事件回调 / ABI |
| 复用范围 | 任意兼容 MCP 的 Agent 都能用 | 依赖宿主实现，跨产品几乎不通用 |
| 鉴权 | 由 Server 自管，可按 scope 收口 | 通常共享宿主进程的权限 |
| 升级影响 | 协议稳定，Server 独立演进 | 插件升级往往绑定宿主版本 |
判断标准其实很简单：MCP 是「把外部系统接到模型面前的管道」，传统插件是「在宿主内部加一块新能力」。前者把外部世界标准化，后者把内部能力组件化；MCP Server 可以独立部署、独立鉴权、独立升级，传统插件则必须随宿主打包发布。一个工程实践上的小坑是：把鉴权逻辑塞进传统插件里，会让多个宿主共享同一份凭据，难以做最小权限；MCP Server 则可以在自己的进程里把 token 收口，再按 scope 暴露工具。
四、落地建议与易错点
落地 MCP 时，按「先少后多、先收口后放开」的节奏推进最稳。先配 2–3 个高频 MCP（如 GitHub、Filesystem、Context7），跑通协议通路，再视业务需要加垂直领域服务；不要一上来就堆几十个 Server，因为工具清单会吃上下文，多个高基数 MCP 同时启用会让模型在选择上出现偏差。
常见易错点有三个。其一，把敏感 token 写在仓库内的 .mcp.json 里——MCP 配置文件应进全局 ~/.claude/settings.json，仓库里只保留非敏感的 Server 声明。其二，忽略工具命名空间冲突——两个 MCP 暴露同名工具时 Claude Code 会按加载顺序择优，建议在 args 里显式区分 server 名。其三，把 MCP 当万能胶水——业务逻辑如果只是「告诉 Claude 怎么做」，用 SKILL.md 写流程更省上下文，MCP 适合的是「让 Claude 真能动手操作外部系统」。
到这里，MCP 在 Claude Code 中作为「外部连接管道」的角色就比较清晰了：它用统一协议把异构服务转成可调用工具，与「宿主内插件」在抽象层、通信方式、复用范围上形成互补。
常见问题（FAQ）
Q1：MCP 和 OpenAPI 是什么关系？
OpenAPI 描述单个服务的接口契约，MCP 定义 Agent 与外部服务之间的统一调用协议，二者正交。
Q2：能不能不用 MCP 直接让 Claude 调外部 API？
能，但每个 API 都要手写工具描述与调用逻辑；MCP 把这部分标准化，可大幅降低接入成本。
Q3：MCP Server 需要常驻吗？
取决于配置：stdio 模式下随 Claude Code 启停，HTTP 模式下可独立常驻，由 Claude Code 按需调用。
