从源码看看Claude Code MCP机制是怎么样的!

本文基于 src 目录中的源码梳理 Claude Code 的 MCP 机制。

这里的 MCP 可以理解为 Claude Code 与外部能力之间的一层协议化适配器：外部服务、插件、本地进程、IDE、SDK 或 claude.ai connector 不需要直接改造 Claude Code 的核心工具系统，而是以 MCP server 的形式暴露 tools、resources 和 prompts，Claude Code 再把这些能力接入自己的工具池、命令系统、资源读取工具、权限检查和任务上下文。

从源码结构看，MCP 机制并不是简单地读一个配置，然后调用一个远程工具，而是一条完整链路：先从多个配置来源收集 server 定义，再经过策略、审批和去重，随后按 transport 类型建立连接，发现服务端能力，把工具包装成 Claude Code Tool，把资源和 prompts 注入到对应入口，最后在调用时进行权限检查、认证续期、连接恢复、结果转换、大输出落盘和状态更新。

Claude Code 并不把外部 server 当作一个特殊旁路，而是把它们发现到的能力转换成内部已经熟悉的结构。MCP tool 会变成普通工具池中的一个工具，MCP prompt 会变成命令入口，MCP resource 会通过列表和读取工具进入上下文；这种转换让外部能力既能复用 Claude Code 的权限、渲染、进度和结果处理，又不会和内置工具的实现耦合在一起。

MCP server 在 Claude Code 中主要提供三类能力。

第一类是 tools，也就是模型可以直接调用的动作能力，例如查询外部系统、读取服务数据、操作第三方平台或触发一个本地集成；源码会把每个 MCP tool 包装成 Tool 对象，并且统一命名为类似 mcp__server__tool 的形式，以避免不同 server 或内置工具之间发生名称冲突。

第二类是 resources，也就是 server 暴露出来的可读取上下文材料，例如文档、数据库条目、远程文件、索引结果或二进制内容。Claude Code 不会把所有 resource 自动塞进上下文，而是提供列出资源与读取资源的工具，让模型在需要时选择具体 server 和 URI；如果资源内容是二进制 blob，源码会把它保存到磁盘并返回可读路径，避免 base64 内容直接污染模型上下文。

第三类是 prompts，它们会进入 Claude Code 的命令系统，表现得像由 MCP server 动态提供的 slash command。模型或用户触发这类命令时，Claude Code 会向对应 server 请求 prompt 内容，再把返回的 MCP message content 转换成 Claude Code 可理解的消息块；在开启相关能力时，部分 MCP resources 还可以被发现为 skills，从而进入技能搜索和调用体系。

Claude Code 支持多种 MCP 配置来源，包括用户配置、项目配置、本地配置、企业托管配置、动态配置、插件提供的 MCP server，以及 claude.ai connector。源码会给每个 server config 带上 scope，并且在合并时处理优先级、去重和策略过滤；这使得同一个 MCP server 可以来自不同地方，但最终进入连接层之前必须先变成一份明确、可审计、可启用或禁用的配置。

项目级 .mcp.json 不会无条件生效，因为项目配置可能来自仓库本身，带有更强的供应链风险。源码中会检查项目 server 的审批状态，未审批的 server 会在启动时通过对话框要求用户确认；企业托管配置则可以更强地控制 MCP server 来源，并配合 allowlist、denylist 或 plugin-only 策略限制用户能连接哪些 server。

这层治理背后的设计思想是：MCP server 本质上可以带来外部网络、子进程、第三方 OAuth、远程数据和工具调用能力，因此配置存在不等于应该连接。Claude Code 先把配置变成候选，再让策略、审批、禁用状态和去重机制决定哪些候选真正进入连接流程。

一次 MCP tool 调用通常从模型选择 mcp__server__tool 开始。工具包装层会先进入 Claude Code 的权限流程，因为 MCP 工具可能读写外部系统、访问网络或执行有副作用的操作；通过权限之后，工具会确认当前 client 仍然可用，如果远程 session 已失效，则清理缓存并尝试用新连接重试一次。

真正调用 server 时，Claude Code 会把工具参数、tool use id 等元信息传给 MCP client，并监听 MCP SDK 的 progress 回调，把 long-running tool 的进度映射回 Claude Code 的 tool progress。server 返回后，结果会经过统一处理：文本、图片、音频、资源链接和结构化内容会被转成模型可接收的内容块；如果结果过大，源码会优先把非图片大输出持久化到文件，再返回去读取这个文件的说明，从而保护主上下文不被巨量工具结果填满。

如果远程 server 返回认证错误，工具调用会把 server 标记为需要重新授权；如果 server 需要用户打开 URL 完成 elicitation，Claude Code 会把这个请求交给 hook、SDK 控制通道或交互式 UI 处理，用户完成后再重试工具调用。也就是说，MCP 调用链不仅包含“请求-响应”，还包含认证、用户交互、重试和结果治理这些现实世界集成必需的环节。

如果想从源码验证上述机制，可以按下面顺序阅读：

Claude Code 的 MCP 机制，本质上是在核心工具系统外面建立了一套协议化扩展层。它允许外部系统提供工具、资源和 prompt，但不会让外部能力直接绕过 Claude Code 的上下文管理、权限系统、结果治理和连接状态管理；所有 MCP 能力都要先被配置、审批、连接、发现和包装，然后才会成为模型可见的能力。

理解这套机制时，可以抓住三句话：配置层决定哪些 server 有资格进入，连接层决定哪些能力被发现并保持可用，工具层决定每次调用如何被授权、执行、转换和回传。这三个层次合在一起，使 MCP 既能扩展 Claude Code 的外部能力，又不会把外部系统的复杂性和风险原样暴露给模型上下文。

Agent面试题（更新中...）

• 字节二面：Function Calling 和 MCP 有什么区别？
• 快手二面：A2A 和 MCP 有什么区别？
• 百度一面：SSE 和 WebSocket 有什么区别？

源码解读Claude Code（更新中）

• 从源码看Claude Code的架构是怎么样的！
• 从源码解析Claude Code的记忆系统！
• 从源码看看Claude Code Multi-Agent 机制是怎么样的！