MCP 入门：让 Claude Code 连接外部工具与数据源
引言：为什么现在需要理解它
如果你在过去几个月里使用过 Claude Code、Cursor 或其他 AI 编程助手，很可能遇到过这样的场景：你让它帮你写一段查询数据库的代码，它给出了看似合理的 SQL，但其中的表名和字段名全是臆造的；你让它帮你排查一个生产环境的错误日志，它只能凭经验猜测，却无法真正登录服务器去查看日志文件。你不得不反复把真实数据粘贴进聊天框，在终端和编辑器之间来回切换。
这背后暴露的是一个根本问题：大语言模型就像一个知识渊博但被关在密室里的专家——它能推理、能总结、能生成代码，但它无法自主地感知外部世界。它不知道你的文件系统里有什么文件，不能读取你内部 API 的最新返回值，也无法查询你那台只读备库里的实时订单状态。
这正是 MCP（Model Context Protocol）要解决的核心问题。它试图为 AI 模型与外部工具、数据源之间建立一种标准化的连接方式，让模型不仅仅是一个聊天对象，而成为一个能够主动获取上下文、调用工具、操作环境的智能代理。
这篇文章将围绕“让 Claude Code 连接外部工具与数据源”这个具体入口，讲清楚 MCP 的本质、工作方式、能解决什么问题、不能解决什么问题，以及你应该如何以一种务实的方式把它引入自己的开发工作流。
一、MCP 是什么
MCP 是一种开放协议，它定义了 AI 应用与外部工具、数据源之间通信的标准。简单来说，它规定了一套“语言”，让模型知道可以向外界请求什么资源、调用什么工具，以及如何安全地把结果传回来。
可以把它类比为 USB-C 接口：在 USB-C 出现之前，不同设备使用不同的接口——打印机用并口，鼠标用 PS/2，外置硬盘用 FireWire 或 eSATA。你需要一堆转接头，而且每种设备的驱动方式都不一样。MCP 要做的，就是在 AI 模型与外部世界之间提供一个统一的“接口标准”。无论是文件系统、数据库、第三方 API，还是内部的微服务，只要按照 MCP 规范实现一个服务端，模型就可以用同一套协议去发现和调用它们。
需要注意的是，MCP 不是替代 Claude Code 或 API 的东西。它并不提供模型能力，也不取代现有的 Function Calling 机制。它解决的是上一层的问题：当你有大量不同的工具和数据源需要接入多个 AI 应用时，如何避免为每一个模型、每一个工具都编写一套定制化的连接代码。Claude Code、Claude 桌面应用等已经内置了 MCP 客户端，你只需要提供符合规范的 MCP 服务端，它们就能自动发现并调用这些工具。
它与 OpenAI 的 Function Calling 或 Plugin 机制的区别在于：Function Calling 是一种模型层面的能力——模型输出一个结构化的“我想调用某个函数”的意图，而实际执行和结果传回仍然依赖于调用方自己编写胶水代码；MCP 则是在协议层面把工具的定义、发现、调用和结果返回全都标准化了，并独立于具体的模型提供商。这使得工具可以跨模型、跨应用复用。
二、从“让 Claude Code 连接外部工具与数据源”开始理解它
Claude Code 是 Anthropic 发布的一个命令行 AI 编程代理，它能够理解整个项目结构、读取文件、运行 shell 命令、编辑代码，并在迭代中与你协作完成任务。但如果它只能操作你本机的文件和命令，它的价值就会被局限在“增强版的本地代码生成器”这个角色里。
MCP 的出现，让 Claude Code 的能力范围从“本地项目”扩展到了“任何可连接的外部系统”。你可以在 Claude Code 的配置文件（.mcp.json）中注册一个或多个 MCP 服务器，这些服务器可以是你自己编写的、社区开源的，也可以是内部团队提供的。配置完成后，Claude Code 在启动时会连接到这些服务器，自动发现它们暴露了哪些资源和工具。
举个例子，你配置了一个连接公司 Postgres 只读从库的 MCP 服务器，它暴露了两个工具：list_tables和execute_readonly_query。当你在 Claude Code 中提出“帮我找出过去七天注册但未下单的用户，并生成一个 CSV 导出脚本”时，模型会意识到它需要实际的数据库结构信息，于是它通过 MCP 调用list_tables发现相关的表，再用execute_readonly_query获取真实数据样本，最后基于这些真实上下文编写脚本。整个过程你不需要手动拷贝任何数据。
这里的关键入口在于：开发者不再需要充当模型与外部世界之间的“人工路由器”。过去你的工作流是“复制日志片段 → 粘贴给模型 → 复制模型生成的脚本 → 到终端执行 → 把报错信息再复制回去”。现在这个循环可以被模型直接驱动的工具调用所替代，而你只需要配置好哪些工具可以被调用，并在关键节点做出决策。
三、它解决了什么问题
从开发者工作流的角度来看，MCP 主要解决三个层面的问题。
第一个问题：真实上下文的自动获取。
原来的痛点是：模型拥有强大的推理和生成能力，但它对当前问题所涉及的真实环境一无所知。你不得不把大量的背景信息手工注入到 Prompt 中——粘贴表结构、提供 API 文档片段、描述配置文件的格式。这个过程繁琐且容易出错，一旦你的描述不够准确，模型的输出就会出现偏差。MCP 介入后，模型可以在需要时主动拉取这些信息。比如它可以通过read_file工具直接读取配置文件，通过数据库查询工具获取真实的表结构。它改变了信息流向——从“人推给模型”变为“模型按需拉取”。但仍有限制：模型能拉取的范围完全由你配置的 MCP 服务器决定，如果服务器没有暴露某个资源，模型依旧“看不见”。
第二个问题：工具集成的标准化与复用。
在没有 MCP 的时代，你想让一个 AI 助手连接 Jira、GitHub 和你的私有 API，需要分别编写三套集成代码，而且它们很可能只适用于特定的 AI 客户端。每换一个模型或助手，你可能需要重写一遍。MCP 提供了一个统一的工具描述格式（基于 JSON Schema），使得同一个 MCP 服务器可以被任何实现了 MCP 客户端的应用使用。你的 Jira MCP 服务器今天在 Claude Code 中用，明天也可以接进 Claude 桌面应用或未来的其他 AI 代理里。这改变了工具开发的 ROI：一次实现，多次复用。但限制在于，MCP 生态仍然处于早期，社区提供的成熟服务器还不够丰富，很多场景你仍需自己动手实现。
第三个问题：多步骤操作的状态保持。
简单的问答式聊天中，模型通常不记得上一步操作产生的副作用。但在真实开发任务中，往往需要“查询数据库 → 根据结果修改代码 → 运行测试 → 根据测试结果调整代码”这样的长链条操作。MCP 使得 Claude Code 这类代理可以在一轮会话中持续调用多个工具，并把前一步的返回结果作为下一步的上下文。这改变了任务完成的方式：从“一次问答解决一个小问题”变成“一个会话完成一个相对完整的子任务”。限制是：这种长链条操作会显著增加 Token 消耗，并且当工具返回数据量过大时，上下文窗口很容易被淹没，导致模型忽略关键信息。
四、它的基本工作方式
理解 MCP 的运作机制，可以从客户端-服务器架构入手。
- MCP 客户端：嵌入在 AI 应用中（如 Claude Code），负责与模型交互，理解模型发出的工具调用意图，并将这些意图转发给对应的 MCP 服务器。
- MCP 服务器：一个实现了 MCP 协议的进程，它可以访问某些本地或远程资源，并对外暴露三类原语：工具（Tools，可以被调用的函数）、资源（Resources，可读取的数据）、提示模板（Prompts，预定义的对话模板）。
一次典型的调用流程如下：开发者向 Claude Code 提出一个任务，比如“分析最近的错误日志，找出出现最频繁的三个异常”。Claude Code 将任务和当前上下文一起发送给 Claude 模型。模型在推理过程中判断需要获取日志文件的内容，于是生成一个工具调用请求，内容大致是：调用名为read_logs的工具，参数{"service": "api-gateway", "lines": 500}。Claude Code 中的 MCP 客户端收到这个请求后，查找到已连接的日志 MCP 服务器，并通过标准 JSON-RPC 协议将调用转发过去。服务器执行请求，将最新的日志内容返回给客户端，客户端再将其作为新的上下文发送给模型。模型分析完日志后输出分析结果。
关键在于，这一切发生在一个统一的协议框架下。MCP 规定了工具发现（客户端启动时向服务器索取工具列表）、调用请求和结果返回的标准化格式。对开发者来说，你只需要实现一个 MCP 服务器——它可以用 Python、Node.js 或任何语言编写，遵循规范暴露工具——剩下的发现与调用过程由客户端和模型自动完成。
从上下文工程的角度看，MCP 实际上把“检索增强”的决策权部分交给了模型。传统的 RAG 方案是先检索再回答，检索策略由开发者预设；而在 MCP 模式下，模型在推理过程中自行决定“我什么时候需要什么数据”，这是一种更动态的上下文构建方式。
五、一个典型使用流程
假设你正在维护一个电商后端项目，需要给订单服务新增一个接口，用于返回某个用户最近 30 天的订单总金额。这个接口需要查询一个已有的 PostgreSQL 数据库，并且需要遵从项目中现有的 API 规范。
步骤 1：配置 MCP 服务器。你在项目根目录的.mcp.json中添加一个 Postgres MCP 服务器的配置，指定连接参数为一个只读从库。该服务器暴露了list_tables、get_table_schema和execute_query工具。启动 Claude Code 后，它自动连接到这个服务器。
步骤 2：提出任务。你输入：“在 orders 模块中新增一个 API，路径为 /users/{id}/total-amount，返回该用户最近 30 天的订单总金额。请先确认数据库中是否有对应的表和字段，再生成代码。”
步骤 3：模型主动获取上下文。Claude Code 没有立刻编造字段名，而是调用list_tables，发现存在orders和order_items两张表。接着它调用get_table_schema获取两表的完整结构，发现orders表有user_id、order_date、status等字段，order_items表有order_id、amount字段。然后它甚至执行了一个execute_query，用SELECT ... LIMIT 1抓取一条真实数据样本，以确认字段的实际内容格式。
步骤 4：生成代码。在充分掌握真实数据结构后，模型查阅项目现有的路由注册方式、响应封装格式，生成了路由处理函数代码，包括参数校验、SQL 查询语句和响应映射。
步骤 5：运行验证。你让 Claude Code 在本地启动服务并调用这个新接口。它使用内置的 shell 工具启动服务，用 curl 发了一个测试请求，并把返回结果展示给你。
步骤 6：Review 和调整。你发现查询效率可以优化，于是要求它添加一个覆盖user_id + order_date的索引建议，它通过 MCP 查询了现有索引后，给出了一个CREATE INDEX语句并解释了对查询计划的影响。最终你确认无误后，手动提交代码。
在这个流程中，你作为开发者始终处于决策和审核的位置，但中间那些机械的数据发现和上下文搬运工作被模型和 MCP 消化了。
六、它和传统方式的区别
| 对比维度 | 传统 API 直接调用 | 普通 ChatGPT 问答 | MCP + AI 代理（如 Claude Code） |
|---|---|---|---|
| 交互入口 | 编写脚本手动调用 API | 网页聊天框 | 命令行 / 编辑器内直接发起 |
| 上下文获取 | 开发者自行编写数据获取逻辑 | 依靠开发者粘贴上下文 | 模型通过 MCP 按需拉取 |
| 是否操作项目 | 不可直接操作 | 仅提供文本输出 | 可读写文件、执行命令、调用工具 |
| 工具复用性 | 每个集成都需要单独编码 | 无工具集成概念 | 一次实现 MCP 服务器，多客户端复用 |
| 多步骤任务 | 需编写完整脚本 | 单轮或多轮纯文本对话 | 会话内自动编排多个工具调用 |
| 对开发者能力要求 | 需要完整的工程实现能力 | 仅需描述需求 | 需要理解代理行为、配置工具、审核输出 |
从上表可以看出，MCP 加代理的模式并没有消除对开发者的需求，而是将开发者的精力从“编写胶水代码”转移到“定义工具边界与审核结果”上。这是一种工作重心的迁移，而非能力的替代。
七、适合什么场景，不适合什么场景
适合的场景：
- 探索与理解陌生代码库：在阅读一个新项目时，模型可以通过 MCP 工具遍历目录、读取关键文件、追踪依赖关系，帮你快速建立整体认知。
- 小范围的重构与代码迁移：例如将某个模块的错误处理从回调改为 async/await，模型可以系统性地扫描相关文件、识别模式并逐文件修改。
- 生成与现有数据紧密结合的代码：如前文所述，基于真实表结构生成 API 代码，或基于真实 API 返回结构生成类型定义。
- 排查非生产环境的错误：连接测试环境的日志和监控工具，模型帮你交叉分析错误来源。
- 重复性维护任务的半自动化：比如批量升级依赖、统一代码风格、同步多语言翻译文件等，模型执行，你审核。
不适合的场景：
- 缺少上下文的大型架构决策：架构设计依赖大量隐性知识和业务判断，模型通过 MCP 获取的上下文往往只是冰山一角，无法取代深度讨论。
- 高风险的生产环境变更：任何直接操作生产数据库或基础设施的工具调用都存在难以预料的风险，即使有审核步骤也不应在紧急变更中依赖此模式。
- 未经人工审核的自动提交：代理输出的代码质量波动较大，自动提交通常是危险的做法。
- 安全敏感性高的代码生成：涉及加密算法实现、权限验证逻辑等安全核心代码，必须由熟悉安全实践的开发者亲手编写和审计，不应交由模型直接生成。
八、开发者应该如何使用它
MCP 带来的不仅是工具的革新，更是工作习惯的改变。以下几条实践建议可以帮助你用好它，而不是被它牵着走。
写清楚任务，而不是只给指令。像给一个聪明的初级工程师分配任务一样，你需要说明背景、目标、约束条件。比如“在 user 模块中新增一个接口，返回用户的基本信息和最近一笔订单详情，要求使用现有的 BaseResponse 格式包裹，添加参数校验，并考虑 N+1 查询问题”比“加个接口”要好得多。
有意识地提供和限制上下文。在 MCP 服务器中，只暴露那些完成任务所需的最小权限和最小数据集。数据库查询工具应使用只读连接；文件操作工具应限制在工作目录内；不要暴露不必要的环境变量。你提供什么上下文，模型就只能在这个边界内工作，这是你的安全杠杆。
建立严格的 Review 习惯。把模型的输出看作一份初稿，而不是最终提交。使用git diff逐段审查，运行测试套件，并手动走查关键路径。如果一个任务足够复杂，可以要求模型先给出执行计划，获得你的认可后再执行具体修改。
渐进式验证，不要一步到位。对于包含多个修改步骤的任务，让模型先完成一个独立的最小可验证部分，你确认后再继续。这能防止模型在错误的方向上越走越远，消耗大量 Token。
理解它是一只“能力强大的盲眼猎犬”。它的嗅觉很灵敏，能根据你指的方向快速奔跑，但它没有视力，不知道前方是猎物还是悬崖。你的角色是把关方向和检查边界的人。
九、它的局限和风险
任何技术都有其边界，MCP 也不例外。正视这些局限，才能避免在实践中踩坑。
- 幻觉问题：当工具返回的数据量很大或内容复杂时，模型可能“选择性阅读”或曲解其中的信息，最终生成看似合理但实际错误的代码。缓解建议：要求模型在生成结论前先引用它依据的具体数据源，你在审核时重点核对这部分引用的准确性。
- 上下文遗漏：在多轮工具调用中，早期获取的信息可能随着会话推进被挤出上下文窗口，导致模型做出前后矛盾的决策。缓解建议：对于长链条任务，定期要求模型总结当前已获取的关键信息，或使用 Claude Code 的
/compact功能强制压缩上下文。 - 代码质量不稳定：同一个任务在不同时间运行，由于模型推理的随机性，输出质量可能差异明显。缓解建议：将关键的业务逻辑约束以显式的方式写入项目规则文件（如 CLAUDE.md），让模型每次都能读取到这些硬约束。
- 安全风险：如果 MCP 服务器暴露了具有破坏性的工具（如删除文件、重启服务），模型可能因为在错误的时间调用它们而导致严重问题。缓解建议：暴露的工具应遵循“默认安全”原则——优先提供只读和可回滚的操作，高风险工具需要显式的二次确认（可以通过在工具描述中声明“此操作需要用户显式批准”）。
- 依赖开发者判断：MCP 并没有让模型“理解”你的系统，它只是让它能够“看到”更多。如果开发者自身对系统缺乏足够的理解，模型的输出只会放大这种无知。缓解建议：先独立理解系统，再使用辅助工具，这个顺序不要颠倒。
- 对大型项目的全局理解有限：受限于上下文窗口的大小和当前代理技术的能力，模型很难真正掌握一个单体巨石项目的全貌。缓解建议：将任务拆解为模块内的修改，尽量让每次会话聚焦在一个清晰的边界范围内。
十、总结：它真正改变的是什么
MCP 没有发明新的模型能力，也没有带来性能上的突破。它真正改变的，是 AI 模型与外部世界的连接方式——从一种手工粘贴、一次性连接的脆弱模式，变为一种标准化、可复用、可扩展的协议化连接。
在这个变化中，开发者的角色也在悄然发生偏移。过去你可能需要大量编写中间层代码来桥接模型和工具，现在你更多地在扮演一个“编排者”和“审核者”的角色：决定把哪些工具交给模型使用，定义每一次调用的边界，评估每一次输出的质量，并在模型的建议之上做出最终的技术决策。
不妨把 MCP 加 AI 代理的组合看作一个执行力很强、但缺乏全局判断力的队友。它能跑得很快，能搬运那些机械而重复的上下文获取和代码生成工作，但它需要你的方向指引和最终确认。它不是来替代你的工程判断力的，而是把你从那些琐碎的手动桥接工作中解放出来，让你有更多时间去思考那些真正需要工程智慧的问题。理解这一点，你就不会对它有不符合实际的期待，也不会因为它明显的缺陷而轻视它带来的实际效率提升。
