MCP 到底解决了什么问题

很多技术名词刚出现时，最容易被讲成一句抽象口号。MCP 也是这样。有人说它是“AI 应用的 USB-C”，有人说它是“连接模型和工具的协议”，这些说法都没错，但如果只停留在比喻层面，就很难理解它真正解决了什么问题。

要理解 MCP，先不要从协议细节开始，而要从 AI 应用的实际困境开始。

大模型本身没有你的上下文

大模型很强，但它天然不知道你的本地文件、数据库结构、项目状态、笔记内容、业务系统和实时数据。

如果你只是把问题粘贴给模型，它能回答的范围就被限制在这次输入里。上下文少，回答就容易泛化；上下文过长，又会带来成本、延迟和噪音。

于是 AI 应用需要一种稳定方式，把外部世界里的信息和能力接进来。

比如：

  • 读取项目里的某个文件。

  • 查询数据库表结构。

  • 搜索知识库。

  • 创建一条任务。

  • 调用接口获取最新状态。

  • 修改一篇 Markdown 笔记。

这些能力不应该每个 AI 客户端都重新发明一遍。否则每接一个工具，就要写一套专门适配逻辑。

MCP 解决的正是这个连接层问题。

MCP 的基本角色

MCP 可以简单理解为三类角色之间的协作：

客户端负责承载 AI 应用，比如一个桌面助手、IDE 插件或命令行代理。

服务器负责暴露某个外部系统的能力，比如文件系统、数据库、GitHub、Obsidian、浏览器、内部业务平台。

模型负责基于上下文推理，并在需要时请求调用工具。

这样一来，AI 应用不需要直接理解每个外部系统的私有细节。它只需要按照 MCP 的标准方式发现资源、调用工具、读取结果。

这就是协议的价值：让集成从“点对点定制”变成“标准接口组合”。

资源、工具和提示词

MCP 服务器通常可以暴露三类核心能力。

第一类是资源。资源可以理解为给模型阅读的上下文，比如文件、数据库 schema、日志、文档、笔记。资源通常有 URI，可以被发现和读取。

第二类是工具。工具是可以执行动作的函数，比如搜索、写文件、创建笔记、查询接口、提交表单。工具调用会产生结果，也可能改变外部系统状态。

第三类是提示词。提示词是服务器提供的结构化任务模板，让用户或客户端可以选择某种预设工作流。

这三类能力对应了 AI 应用最常见的需求：看见信息、执行动作、复用流程。

为什么不是直接给模型联网

很多人会问：既然模型需要外部信息，直接联网或者直接开放文件权限不就行了吗？

问题在于，真实系统需要边界。

模型不应该拥有无限权限。它应该知道自己能访问哪些资源，能调用哪些工具，参数是什么，结果如何返回，哪些操作需要用户确认。一个好的工具协议，不只是为了“能连上”，也是为了“可控地连上”。

MCP 的意义之一，就是把外部能力包装成可声明、可发现、可约束的接口。

这比随意给模型一段脚本权限更安全，也更容易维护。

MCP 让个人工具也能被组合

MCP 不只适合企业系统。个人工作流里也有大量可以接入的工具。

比如把 Obsidian 作为知识库，把浏览器作为测试入口，把数据库作为查询对象，把本地脚本作为自动化能力。每个工具各自提供 MCP 服务，AI 客户端就能把它们组合起来。

这意味着个人电脑上的很多软件，不再只是孤立应用，而可以变成 AI 助手可调用的能力模块。

以前你要手动打开 Obsidian、搜索笔记、复制内容、整理成文章。接入 MCP 后，AI 可以直接搜索 vault、读取笔记、生成草稿、写回文件。人仍然负责判断方向，但重复操作被工具接走了。

MCP 不是万能层

也要看到，MCP 不是让 AI 自动可靠完成一切的魔法。

首先，工具本身要设计好。一个危险的删除工具，即使通过 MCP 暴露，也仍然危险。其次，模型调用工具时仍可能误判，所以高风险操作需要确认、审计和回滚。再次，MCP 只解决连接标准化问题，不解决业务规则是否正确、权限设计是否合理、数据质量是否可靠。

协议让系统更容易连接，但连接之后仍然需要工程治理。

这和 API 世界一样。REST 或 GraphQL 让服务通信更标准，但不会自动让业务系统变好。

什么场景适合 MCP

如果一个外部系统满足这些特征，就很适合考虑 MCP：

  • AI 需要经常读取它的上下文。

  • AI 需要调用它完成明确动作。

  • 这个系统不应该把全部权限直接暴露给模型。

  • 你希望多个 AI 客户端复用同一套集成。

  • 工具调用结果需要结构化返回。

典型例子包括代码仓库、知识库、数据库、任务系统、文档系统、浏览器自动化、内部平台。

如果只是一次性复制一段文本给 AI，那不需要 MCP。MCP 适合的是稳定、重复、可组合的外部能力。

结语

MCP 解决的问题，不是“让 AI 更聪明”，而是“让 AI 更规范地使用外部能力”。

它把资源、工具和提示词以标准方式暴露给 AI 客户端，让模型有机会在受控边界内读取上下文、调用动作、完成任务。

未来的 AI 应用很可能不是一个封闭聊天框，而是一组可组合工具的调度入口。MCP 的价值就在这里：它让外部世界可以被模型理解和调用，同时保留协议层面的边界。

AI 真正进入工作流，不是因为它会聊天，而是因为它能在正确的上下文里，调用正确的工具，完成正确的动作。