【claude code实践】MCP Server 的基本概念：工具、资源与上下文扩展

MCP Server 的基本概念：工具、资源与上下文扩展

引言：为什么现在需要理解它

最近一年，越来越多的开发者开始在项目中接入大语言模型。刚开始大家觉得很新鲜——把需求丢给 ChatGPT，它能生成一段能用的代码。但很快，问题就来了：模型不了解你的项目结构，不知道你用的是什么框架版本，也不清楚数据库里有哪些表。每次对话都要手动粘贴文件内容、解释上下文，几轮下来比手写还累。

于是，一个自然的需求浮现出来：能不能让模型直接“看到”项目的真实情况，并且可以安全地执行一些操作？这种需求并不是要模型替代开发者，而是希望减少那些重复、机械的“搬运上下文”工作。

这就是 MCP（Model Context Protocol，模型上下文协议）以及 MCP Server 出现的大背景。它由 Anthropic 提出并开源，旨在为 AI 模型和外部工具、数据源之间建立一套标准化的连接方式。而 MCP Server，正是这个协议中承载“工具、资源、上下文扩展”的核心角色。

本文将围绕 MCP Server 的三个基本概念——工具、资源、上下文扩展——帮助你从开发者的角度建立起对这套机制的系统理解。读完你会明白，它不是什么神秘的黑盒，而是一种让 AI 协作更工程化的设计。

一、MCP Server 是什么

一句话定义：MCP Server 是一个实现了模型上下文协议的服务端程序，它向 AI 模型暴露标准化的工具、资源访问能力和上下文提示，让模型可以按需获取外部信息并执行操作。

展开来说，MCP 是一种客户端-服务端协议。AI 应用（比如 Claude Desktop、Cursor 或其他支持 MCP 的编程助手）充当客户端，而 MCP Server 则是运行在本地或远端的一个进程。模型并不会直接调用文件系统、数据库或 API，而是通过 MCP Server 提供的“菜单”来决定它可以做什么、读什么。

可以这样理解：如果没有 MCP Server，模型就像一个被关在空房间里的人，只能根据你从门缝里塞进去的纸条来回答问题。有了 MCP Server，房间被装上了一些带标签的按钮和抽屉——模型可以按按钮（调用工具），打开抽屉（读取资源），还能看到墙上的提示卡片（上下文扩展）。但这一切都在你的控制范围之内，你决定装哪些按钮、哪个抽屉可以开。

MCP Server 不是什么：它不是一个 Agent，也不具备自主决策能力。它仅仅是一个“能力提供者”，被动响应客户端的请求。它不替代数据库、不替代 API 网关，更不是又一个 AI 模型。

与类似概念的区别：如果你熟悉 OpenAI 的 Function Calling 或插件系统，可能会觉得相似。区别在于，Function Calling 是模型厂商定义的调用格式，每次都需要在请求中临时描述函数签名，而 MCP 把这些能力标准化为一种持续存在的服务，模型可以通过tools/list和resources/list等标准方法动态发现可用能力。它更像是一个长期运行在旁边的工具中间件，而不是一次性传入的函数定义列表。

二、从“工具、资源与上下文扩展”三个入口理解它

MCP Server 对外暴露的能力可以归结为三个核心抽象：工具（Tools）、资源（Resources）和提示（Prompts，即上下文扩展）。这三个概念是理解 MCP Server 的关键入口。

工具代表“可以做的事”。比如：查询数据库、创建文件、调用 API、执行 Shell 命令。工具由 MCP Server 定义并实现，模型可以看到工具的名称、描述和参数 Schema，然后决定要不要调用。调用请求发给 Server，Server 执行后返回结果。

资源代表“可以读的数据”。比如：文件内容、数据库表结构、系统状态信息、日志。资源与工具不同，工具是“动作”，资源是“静态信息或实时数据”。模型可以请求读取某个资源 URI，就像通过 HTTP GET 拉取数据一样。资源支持类似文件系统的 URI 结构，比如file:///project/src/main.py或postgres:///users/table。

**提示（上下文扩展）**是 MCP 1.0 规范中的一个补充概念，它可以理解为“预设的对话模板或上下文注入”。提示可以由 Server 预定义，用户在客户端选择后，将一段结构化的上下文（包括角色、内容、资源引用等）注入到对话中，帮助模型更快地进入正确的上下文状态。这是对开发者常用“粘贴一段指令+代码片段”这一行为的标准化。

这三个概念协同工作：工具让模型能做事情，资源让模型能看到世界，提示让模型能更准确地理解当前要解决什么问题。它们一起构成了 MCP Server 对外暴露的“能力三角形”。

三、它解决了什么问题

从开发者工作流的角度看，MCP Server 解决的是“AI 模型与真实开发环境之间的鸿沟”。具体体现在三个层面：

问题一：上下文手动搬运成本高

原来的痛点：每次让 AI 帮忙改代码，需要手动找到相关文件，复制粘贴到对话框，还要说明文件路径、项目结构、依赖版本。一个简单功能可能需要对十几行对话上下文进行“预热”。

MCP 的介入方式：模型通过resources可以主动读取项目文件、配置文件、依赖清单。你只需要说“修复这个 bug”，它就能自己去翻相关模块的代码。

改变：将“上下文准备”从手动操作变成了协议化自动获取，对话启动成本大幅降低。限制在于：模型能读到什么取决于你暴露了哪些资源，这要求开发者在配置 Server 时有清晰的安全意识。

问题二：AI 输出与执行之间存在手动断层

原来：模型生成一段 SQL 或一段 Bash 脚本，你需要复制到数据库客户端或终端里执行，出错再贴回去。这个过程不仅低效，还容易引入转录错误。

MCP 介入方式：Server 提供tools，模型可以直接调用 SQL 执行工具或 Shell 工具，但执行结果仍返回给模型（或开发者）进行判断。

改变：形成了“观察-思考-行动”的闭环。模型生成的不再是“建议”，而是经过实际环境反馈后的修正结果。限制：工具的权限边界必须严格管理，否则一次误判就可能删库跑路。

问题三：多源信息整合困难

原来：一个任务可能需要同时参考数据库 Schema、API 文档、日志和某段业务代码。开发者需要在多个工具间切换，手工综合信息。

MCP 介入方式：多个 MCP Server 可以同时连接到一个客户端，各自暴露不同领域的资源和工具。模型可以跨 Server 调用，比如从一个 Server 读数据库 Schema，从另一个 Server 查 Git 历史，再结合当前文件内容做分析。

改变：实现了“上下文联邦”——不同来源的信息在模型侧聚合，不需要人做中转。限制：跨 Server 调用的效率和安全策略还比较早期，真正生产级使用需要评估性能和信任边界。

四、它的基本工作方式

要理解 MCP Server 的运行机制，可以先记住它的通信模型：基于 JSON-RPC 2.0 的请求-响应协议，使用标准输入输出或 SSE 传输。

启动 MCP Server 后，它维持一个持久连接。客户端（AI 应用）向它发送请求，Server 响应结果。核心流程可以分为三个层面：

能力发现阶段：客户端启动后会向 Server 发送tools/list和resources/list等请求，获取当前 Server 提供的所有工具和资源列表。这一步就像是插件初始化时注册自己的功能菜单。Server 返回的每个工具都包含名称、描述和 JSON Schema 定义的参数格式。模型通过这个元数据“知道”自己可以做什么。

上下文获取阶段：当模型判断需要更多信息时，会通过客户端向 Server 发起resources/read请求，指定 URI 来读取资源内容。比如读取file:///src/config.py，Server 返回文件文本。对于支持resources/subscribe的 Server，还可以推送资源更新通知。

工具调用阶段：模型决定使用某个工具时，通过tools/call请求传递工具名称和参数。Server 执行实际操作（查库、跑命令、调 API），然后返回结果文本或错误信息。结果被追加到对话上下文中，模型基于反馈决定下一步动作。

整个过程中，开发者是最终决策者。当前主流 MCP 客户端（如 Claude Desktop）都要求用户对工具调用进行批准，或者至少提供明确的授权设置。这不是一个全自动的 Agent 循环，而是一种“建议-审批-执行-反馈”的协作模式。

打个比方：MCP Server 像是给模型配了一个高度听话但不会自主思考的“机械臂”，它能按指令完成精确操作，但每个按钮的权限开关都捏在开发者手里。

五、一个典型使用流程

假设场景：一个后端项目，需要根据新需求在用户服务里添加一个“获取最近注册用户列表”的 API，涉及查询 PostgreSQL，并编写测试。

步骤 1：开发者提出任务
在支持 MCP 的编程助手中输入：“在 user 模块新增一个 API，返回最近 7 天内注册的用户，包含 ID、昵称和注册时间，按时间倒序。加集成测试。”

步骤 2：工具读取上下文
模型判断需要了解现有代码结构。它通过 MCP Server 的resources/read读取项目目录树、现有的 user 路由文件、模型定义和测试文件。它还通过另一个 Postgres MCP Server 的tools/call执行 SQL 查询，获取users表的实际字段（它知道通过tools/list获得的能力列表中有execute_sql这个工具）。

步骤 3：分析并生成方案
模型整合信息后，理解到项目使用 FastAPI + SQLAlchemy，测试用 pytest。它给出修改计划：在 model 中新增一个查询函数，在路由中新增一个 GET 端点，创建测试文件。开发者确认计划。

步骤 4：修改代码
模型通过tools/call调用文件写入工具，在对应文件插入代码段。它生成的三段代码都是基于真实项目结构和数据库 Schema 的，不需要开发者手动喂文件内容。

步骤 5：运行验证
模型调用执行命令的工具，运行pytest tests/test_user.py -v，获取测试输出。如果失败，它读回错误信息，修正代码后再次运行。

步骤 6：开发者 review 和调整
整个过程模型提出的修改都是可见、可审计的。开发者看到测试通过后，手动检查代码风格、逻辑正确性，做微调后提交。开发者始终是代码的作者和责任人。

这个流程的关键变化在于：上下文获取、工具调用和验证循环都自动化了，但决策权和最终审核权在开发者手中。

六、它和传统方式的区别

下面用一张表来对比 MCP Server 协作模式与几种常见传统方式：

核心区别在于：传统方式下，模型看到的是一扇小窗；MCP Server 模式下，模型可以通过协议化通道获得更立体、更实时的项目视图。但这也意味着开发者需要投入精力配置和维护这些 Server。

七、适合什么场景，不适合什么场景

适合的场景：

• 阅读陌生代码库：模型能主动拉取文件、追踪引用关系，快速生成结构化的代码导读。
• 小范围重构：在指定模块内，让模型根据真实依赖关系修改函数签名、更新调用方。
• 生成测试和文档：基于现有代码和数据库 Schema 生成符合实际情况的测试用例和 API 文档。
• 日常排查错误：连接日志文件资源、数据库状态查询工具，快速定位异常数据或报错上下文。
• 自动化重复任务：比如批量调整配置文件格式、根据 Swagger 生成前端 API 层代码并验证。

不适合的场景：

• 缺少充分上下文的高层架构决策：模型没有业务全景视野，建议仅作参考。
• 高风险生产环境变更：直接操作生产数据库或服务器配置的工具权限绝对不应开放给模型。
• 不经 review 的自动提交：任何由模型生成或修改的代码都需要经过正常 Code Review 流程。
• 安全敏感代码的生成：如加密逻辑、权限验证模块，必须由资深开发者编写和审计。
• 需要极高确定性的场景：模型输出存在随机性，即使绑定真实上下文，也无法保证每次输出完全一致。

八、开发者应该如何使用它

首先需要明确一点：MCP Server 不是开发者的替代品，而是工作流的增强工具。使用它的正确心态是“我有了一个能看懂上下文并执行简单操作的助手”，而不是“我不用管了”。

实践建议：

1. 从最小权限开始配置：只暴露模型当前任务确实需要的资源和工具。比如先让它能读某个模块的代码，不要一上来就给它全项目读写权限和 Shell。
2. 写清楚任务边界：好的提示依然重要。明确告知目标、约束（“不要修改数据库配置文件”）、期望的输出格式。
3. 利用 MCP 的“资源”减少手动喂料：如果你发现自己经常粘贴某几类信息，就考虑把这些做成资源——例如让 Server 暴露一个返回当前日期时间或组织架构的资源。
4. 建立 review 和验证习惯：把模型生成的内容视为“实习生提交的初稿”。必须运行测试、检查 diff、做人工审核。
5. 为高频工具建立白名单：某些只读查询工具可以设置为无需每次审批，但写入类操作应始终保留确认步骤。
6. 理解工具的失败模式：提前考虑一个工具调用失败（比如数据库连不上）时，模型会得到什么错误信息，它会如何反应。不要让错误信息泄露敏感系统细节。

九、它的局限和风险

客观审视 MCP Server 模式的风险，是每个工程团队在引入它之前必须做的事。

• 幻觉仍然存在：模型可能调用工具后错误解读返回结果，或生成看似合理但逻辑有误的代码。缓解：对关键输出做独立验证，不盲目信任。
• 上下文遗漏：resources/list返回的概要和实际文件内容可能存在差异，模型可能只读了部分关键文件而忽略隐式依赖。缓解：为复杂任务明确列出需要检查的文件范围。
• 代码质量不稳定：同样的任务，每次生成的代码风格和设计思路可能不同。缓解：在项目中有明确的编码规范和 Lint 工具，作为最后一道防线。
• 安全风险：工具调用本质上是模型触发代码执行。如果 Server 对参数校验不严格，可能被注入恶意操作（例如 SQL 注入、路径遍历）。缓解：在 Server 实现层做严格的参数校验和权限检查，不能依赖模型“不会那么做”。
• 过度依赖开发者判断：新手开发者可能过度信任模型建议，放弃自己查阅文档和源码的习惯。缓解：团队内部要建立使用规范，强调 MCP 是辅助而非权威。
• 大型项目理解有限：当项目大到模型上下文窗口无法容纳所有相关文件时，模型容易“管中窥豹”。缓解：结合 RAG 或更智能的上下文裁剪策略，但已超出 MCP Server 本身的范围。

十、总结：它真正改变的是什么

回到标题中的三个基本概念——工具、资源、上下文扩展。MCP Server 并没有发明什么新的 AI 算法，它做的是一件工程上的事：把模型与外部世界的交互方式，从临时的、手动的“口述传达”，变成了结构化的、可发现的、可审计的协议。

它的本质价值在于两点。第一，降低 AI 模型获取项目上下文和触发操作的边际成本，让开发者从重复的“环境描述者”角色中解放出来。第二，为 AI 协作提供了一个安全可控的模式——工具调用的白名单、资源的读取权限、用户的审批流程，都在架构层面被显式处理，而不是藏在某个产品的黑盒配置里。

如果非要用一个角色来类比，MCP Server 更像是开发团队里新来的“工具集成工程师”：他负责把所有数据源和操作接口的线缆整理清楚，给模型提供一套标准化的面板。至于该按哪个按钮、什么时候按，仍然由坐在主控位上的开发者决定。

对于今天的开发者而言，理解 MCP Server 的基本概念，并不是为了追赶某个风口，而是因为它很可能成为下一阶段 AI 协作工具的基础协议——就像你理解了 REST API，就能更好地使用各种 Web 服务一样。把它看作一个可组合、可定制的工具中间件，花一个下午自己搭建一个简单的 MCP Server，你会发现，让模型“看到真实世界”这件事，其实比你想象的更简单，也更有工程美感。