[!abstract 为什么用 MCP] 来源：本文分析 内容： - MCP 是给模型用的“远程遥控器”接口，设计上并非直接面向终端用户； - 在写代码场景下，MCP 补充的是“本地环境操作”的能力，而不是“智能生成”的能力； - 在 Obsidian 场景下，是否需要 MCP，取决于你要不要让 AI“主动参与、自动处理”，而不只是辅助。

相关主题：Agent 工具链、AI 插件生态、Obsidian 自动化、大模型与工具融合

引言

昨天在 B 站看到 UP 主黄益贺展示了一个用对话操作 Obsidian 的 MCP。朋友最近也推荐了一个 MCP 应用：文颜，它可以将 Obsidian 文件发布到微信公众号。文颜 MCP 需要一个 MCP Client 连接大模型和 MCP Server 来处理 Obsidian 的 markdown 文件，理论上可以上传任意 markdown 到公众号的草稿箱。

文颜 MCP 有两个功能：列出支持的风格和上传草稿箱。使用这个工具需要设定微信账户、标题、封面图，以及安装必要的软件。虽然比直接用 Obsidian 插件复杂，但仍有一定用户。

当然，用户如何选择的关键在于工具的功能实现、是否稳定和收费，而不在于它是 Obsidian 插件还是 MCP Server。

模型说：MCP 的设计初衷，更像是给 Agent 系统提供“统一的调用接口”，让 AI 有办法去控制你的本地资源，比如打开 Obsidian 的某个笔记、修改其中内容、推送到公众号……本质上是暴露给“模型”用的 API，不是面向终端用户的 UX。

Obsidian+MCP

现在，一些 Obsidian 插件已经嵌入了大模型和 MCP 相关工具，但这些工具只是连接 Claude 调用 MCP，而不是直接在 Obsidian 中实现 MCP Client。那么，是否需要开发一个直接在 Obsidian 中嵌入 MCP Client 的插件呢？实现 MCP Client 相对简单，具体方法可参考：MCP_2_MCP服务器与客户端指南。MCP Client 的关键在于选择和调用工具，理解返回内容，维护 MCP Server 设置。如果不想额外付费或无法连接国外的 MCP Server，还需要在本地搭建 MCP Server。

  • 模型说：你提出“是否要做个插件把 MCP Client 嵌入 Obsidian”。答案可能是：适合某类“高交互 + 多步骤 +AI 主导”的任务，比如批量处理、自动归类、写草稿 + 发布一体化流程。而不太适合“我就是想写点东西 + 辅助润色”这类轻量操作。

MCP 的使用场景

现在很多工具都在 MCP 化，但是对于那些熟悉的工具，只需要点两下就能完成，为什么还要进行复杂的设置，用对话的方式调用大模型来处理呢？这是不是有点像“相声改小品、小品改快板”的意思？

我觉得 MCP 的设计初衷可能是为了服务提供者，通过这种方式暴露一些“API”，使用户在不需要掌握编程和调用细节的情况下也能使用功能。这不仅节省了适配接口的时间，还能够更好地与本地数据对接，降低了开发门槛。

2025 年 3 月，VSCode 更新增加了对 Agent 和 MCP 的原生支持。用户可以在工作区的.vscode/mcp.json 文件中定义 MCP 服务器，然后通过 Agent 调用 MCP 功能。

这两年我一直使用 Copilot 写代码，现在主要使用 Copilot Agent，感觉目前像 GPT-4.1，Claude 4 这样的模型基本上可以满足我绝大多数的代码需求。我不太明白在编程这个场景中，MCP 提供了哪些非常重要的额外功能。或者说，大而强大的大模型自带的一些功能和 MCP 的功能有一些重叠。

我理解，使用 MCP 可以提取网页内容、搜索地图、租房、买东西。但这些貌似和写代码的场景没有太大关系。是不是我们可以利用它的功能，但很难将其应用于我们自己的产品中？

模型说：GPT-4.1 和 Claude 4 等模型已经在很大程度上满足了编程需求，但 MCP 的强项在于“操作”而非“生成”。例如：

  • 大模型可以生成代码；
  • MCP 能帮助代理在本地环境中执行代码、运行测试、提取变量值，以及根据错误提示切换上下文文件。

因此，如果你只是编写代码和复制粘贴，MCP 并不显著。但若你希望 AI 长期参与项目并自主行动，而不仅仅是被动响应指令，MCP 就显得尤为重要。

总结

MCP 的核心价值在于两个方面：一是它作为一种新型接口，相较传统 API 提供了更高层、更语义化的调用方式；二是它在与其他工具（如本地应用、云服务）之间建立连接时，能够与 Agent 协同完成更复杂的任务链。在当前 AI 驱动的工具生态中，MCP 不仅是“调用”的桥梁，更是一个新型主控架构中的关键组件。