MCP 是什么 ？如果你只把 AI 当成聊天机器人，它最擅长的事情仍然是理解问题、整理资料和生成文字。但当你希望 AI 去读取网站资料、建立 WordPress 草稿、查询数据库，甚至执行某个系统里的动作时，问题就变成：AI 要怎样安全、标准化地连接这些外部工具？

这正是 MCP（Model Context Protocol，模型上下文协议）开始受到关注的原因。简单来说，MCP 不是一个新的 AI 模型，也不是另一款 ChatGPT。它是一套让 AI 应用与外部工具、资料来源和服务沟通的开放协议。

我自己最近在管理 sventang.com、stylomilo.net 等 WordPress 网站时，也已经实际接触 MCP：ChatGPT 不只是帮我写好文章，然后让我复制贴上 WordPress，而是可以透过网站提供的 MCP 工具建立草稿、修改草稿和写入 SEO 资料。理解 MCP 后，会更容易明白为什么现在的 AI 正从「会回答」走向「能连接工具完成工作」。

MCP 是什么？先把它想成 AI 的统一插座

MCP 的全名是 Model Context Protocol。官方文件把它定义为一种让应用程式以标准方式向大型语言模型提供 context 的协议，同时把「提供资料与能力」和「模型本身的互动」分开。

如果觉得这句话太技术化，可以把 MCP 想成一个统一插座。

以前每一个 AI 应用要连接 WordPress、数据库、文件系统或企业工具，开发者往往需要为每个组合分别设计接口。MCP 尝试建立共同规则：只要客户端和服务器都理解这套协议，就可以用比较一致的方法交换能力与资料。

这不代表接上 MCP 后什么系统都会自动兼容，也不代表完全不需要开发。但它解决了一个很实际的问题：AI 应用与外部系统之间，不必每次都从零设计一套沟通方式。

MCP 里面最重要的三个概念：Tools、Resources、Prompts

理解 MCP，不需要一开始研究所有协议细节。一般使用者先掌握三个核心概念已经足够。

1. Tools：让 AI 执行动作

Tools 可以理解为服务器开放给 AI 使用的功能。例如一个 WordPress MCP Server 可以提供「建立草稿」「读取文章」「修改草稿」等工具。

当 AI 判断任务需要某个工具时，它可以提出对应的调用，并按照工具规定的参数执行。这也是 MCP 和普通聊天最明显的差异：模型不再只是告诉你应该怎样做，而是有机会调用已经获授权的工具去做。

2. Resources：让 AI 读取资料

Resources 比较接近可读取的资料来源。它可能是文件、数据库内容、网站资料或应用程式提供的其他 context。

重点是：模型不必把所有资料永久塞进训练资料里，而可以在需要时从外部系统取得相关 context。

3. Prompts：把常用工作方式标准化

Prompts 是服务器可以提供的可重复使用提示模板，让某类工作有一致的起点。它不是 MCP 最吸引人的部分，却很适合把组织或个人经常重复的工作方式包装起来。

官方 MCP SDK 文件也把 Tools、Resources 与 Prompts 列为服务器可以提供给 AI 应用的主要能力。想进一步阅读技术定义，可以参考 Model Context Protocol 官方资料。

MCP 和 API 有什么不同？

很多人第一次看到 MCP，会问：我们不是早就有 API 了吗？为什么还需要 MCP？

答案不是「MCP 取代 API」。事实上，MCP Server 背后完全可能继续调用原有 API。

API 是应用程式之间沟通的接口；MCP 则更针对 AI 应用如何发现、理解和调用外部能力，提供一套共同协议。可以把 API 想成各家店铺原本已经存在的门，而 MCP 更像为 AI 提供一套比较统一的地图、门牌和使用规则。

因此，两者通常是互补，而不是二选一。

MCP 和 RAG 又有什么不同？

昨天我在 《RAG 是什么？为什么 AI 有了知识库，回答还是可能出错？》 解释过 RAG。两者很容易被混在一起，因为它们都涉及「让 AI 使用模型以外的资料」。

但关注点并不相同。

RAG 的核心是检索：先从知识库找出与问题相关的资料，再把这些资料交给模型生成答案。MCP 的范围则更广，它关注 AI 应用如何以标准方式连接外部工具、资源与能力。

一个 MCP Server 可以提供资料读取能力，而某个工具内部也可能使用 RAG。反过来说，建立 RAG 系统并不一定需要 MCP。

为什么 MCP 对 WordPress 网站经营者有意义？

如果只是偶尔写一篇文章，MCP 未必有明显价值。但当网站经营进入重复工作阶段，它的意义就出现了。

以 WordPress 内容流程为例，过去常见做法是：在 ChatGPT 写稿、复制正文、登入后台、建立文章、设分类标签、再填写 SEO Title、Meta Description 和 slug。每一步都需要人工在不同介面之间切换。

如果 WordPress 端提供经过限制的 MCP 工具，AI 就可能在获授权的范围内读取文章、检查现有草稿、建立 Draft，再写入 SEO 资料。这样做并不等于把网站完全交给 AI，而是把重复的机械步骤变成可调用的工具。

这和我之前写的 《用 ChatGPT 写 WordPress 文章：从选题到 Yoast SEO 的 8 步流程》 可以连起来看：写作流程解决「内容怎样产生与检查」，MCP 则进一步解决「AI 怎样把工作连接到实际系统」。

OpenAI 为什么也支持 MCP？

OpenAI 在 2025 年 5 月为 Responses API 加入 remote MCP server 支持，让开发者可以把模型连接到 MCP Server 所提供的工具。OpenAI 当时也说明，MCP 是一种标准化应用如何把 context 提供给大型语言模型的开放协议。

这意味着 MCP 已经不只是某一个 AI 产品内部的连接方式，而正在成为跨不同 AI 应用与工具生态讨论的共同标准之一。OpenAI 的相关说明可参考 Responses API 的 MCP 支持介绍。

MCP 不等于「AI 可以随便控制你的系统」

看到 AI 能调用工具，很容易产生两个极端想法：一个是觉得以后所有事情都可以全自动；另一个是担心 AI 一接上系统就会拥有全部权限。

实际上，真正关键的是服务器开放什么工具、每个工具允许做什么，以及权限与认证怎样设计。

例如我认为 WordPress 自动化最重要的安全原则之一，就是把「建立 Draft」和「直接 Publish」视为两种完全不同的权限。AI 可以帮忙建立草稿，并不代表它应该拥有自动发布文章的权力。

同样地，涉及删除资料、付款、寄信或修改生产系统的工具，都应该有更严格的授权、确认与审计机制。工具调用越强，权限设计越重要。

这也呼应我在 《2026 年 AI 战略怎么做？别急着买工具，先把 AI 放进真正的工作流程》 提到的原则：真正有用的 AI 不是单纯增加工具数量，而是把 AI 放进有边界、可检查的工作流程。

一般使用者需要自己架 MCP Server 吗？

不一定。

如果你只是使用已经支持 MCP 的应用和服务，可能只需要连接现成服务器并完成授权。只有当你拥有自己的系统、需要开放特定内部能力，或希望严格控制 AI 能做什么时，才比较有理由自己开发 MCP Server。

对于 WordPress 网站经营者，我会先问三个问题：

1. 现在有没有大量重复、规则明确的操作？
2. 这些操作是否可以限制在安全范围，例如只读取资料或只建立草稿？
3. 连接之后节省的时间，是否值得承担维护与权限管理成本？

三个答案都偏向「是」，MCP 才值得进一步研究。不要因为 MCP 最近很热门，就为了接 MCP 而接 MCP。

FAQ：关于 MCP 的几个常见问题

MCP 是一个 AI 模型吗？

不是。MCP 是协议，用来标准化 AI 应用与外部工具、资源和服务之间的连接方式。它本身不会取代 LLM。

MCP 会取代 API 吗？

不会。MCP Server 很可能仍然使用既有 API 完成实际操作。MCP 解决的是 AI 客户端如何以较统一的方法发现和使用这些能力。

MCP 和 AI Agent 是同一件事吗？

不是。Agent 是更广泛的 AI 工作方式，可以规划步骤、使用工具并完成任务；MCP 则可以成为 Agent 连接外部工具的一种标准协议。Agent 不一定使用 MCP，而 MCP 也不等于完整的 Agent。

MCP 安全吗？

协议本身不能替你决定所有安全策略。真正风险取决于服务器开放哪些工具、认证方式、权限范围以及是否要求人工确认。特别是写入、删除、付款和发布等动作，不应该因为可以自动化就默认全部开放。

小结：MCP 真正改变的是 AI 与工具之间的连接方式

MCP 最值得理解的地方，不是多记一个 AI 缩写，而是看懂 AI 产品正在发生的变化。

过去我们主要把资料贴给聊天机器人，再把答案复制回自己的工具；现在，AI 开始可以在明确权限下直接连接资料与工具。MCP 尝试让这种连接方式更标准化。

对一般网站经营者而言，现在不需要马上自己开发 MCP Server。但如果你已经开始用 AI 处理 WordPress、内容管理或重复行政流程，理解 Tools、Resources、权限和人工审核，会比单纯追逐「最新 AI 工具」更有价值。