模型上下文协议（Model Context Protocol，MCP）解决的是互操作性问题。

它不会让智能体变得更聪明，不会决定哪些工具值得信任，也不会取代你的 API、权限模型或应用程序逻辑。

它所做的是标准化一种方式，让 AI 应用能够发现和使用外部工具、数据以及可复用的提示词。

这听起来只是一件小事。但在实践中，它很重要，因为如果没有这样的协议，AI 应用往往需要通过定制适配器来集成每一个外部系统。

没有共同协议，每个宿主应用都必须为每个工具提供方建立自己的集成契约。有了 MCP，服务器就能以标准化的形式提供能力，任何兼容的宿主应用都可以连接并使用这些能力。

可以这样理解：

MCP 是 AI 应用与外部能力之间的互操作层。

MCP 试图解决的问题

假设你正在构建一个智能体，需要访问：

  • GitHub；
  • 私有文档系统；
  • 数据库；
  • 内部计费 API；
  • 浏览器；
  • 本地开发环境。

你完全可以直接集成每个系统。

但这通常意味着要为以下方面编写定制代码：

  • 连接初始化；
  • 工具发现；
  • 数据结构模式（schema）；
  • 身份认证；
  • 传输机制；
  • 错误处理；
  • 能力元数据；
  • 生命周期行为。

随后，另一个 AI 客户端需要使用相同的系统，又得重新实现一套集成逻辑。

MCP 在 AI 宿主应用和能力提供方之间建立了共同的契约。

提供方实现一个 MCP 服务器，宿主应用通过 MCP 客户端连接。之后，模型就可以发现该服务器提供的能力。

MCP 官方 SDK 文档将这一协议描述为一种开放标准，用于把 AI 应用连接到工具和数据所在的系统。服务器可以提供工具、资源和提示词，而兼容的宿主应用可以连接并使用它们。

最重要的三种基础能力

MCP 服务器可以提供多种能力，其中三个概念尤其有用。

工具（Tools）

工具是可以调用的操作。

例如：

  • get_order(order_id)；
  • create_ticket(...)；
  • search_repository(...)；
  • run_test_suite(...)；
  • calculate_quote(...)。

工具通常有名称、描述和结构化输入。宿主应用可以发现它，模型可以决定是否调用它，而服务器负责执行相应操作。

工具是 MCP 中与函数调用最接近的部分。

资源（Resources）

资源是客户端可以读取的数据或内容。

例如：

  • 配置文件；
  • 文档；
  • 代码仓库中的产物；
  • 知识记录；
  • 生成的报告。

当应用需要获取上下文，却不希望把每次读取都建模为执行某项操作的函数时，资源就很有用。

提示词（Prompts）

提示词是服务器提供的可复用模板或交互模式。

它们可以封装特定领域的指令，使宿主应用不必分别重新实现相同的提示词逻辑。

这三种基础能力区分了三个不同的概念：执行操作、读取内容、复用交互模式。

MCP 不会取代函数调用

函数调用和 MCP 工作在不同的层次。

函数调用是一种机制：模型通过它选择一个函数，并提供结构化参数。

MCP 则标准化了外部能力如何在兼容客户端之间被发布、发现、连接和调用。

可以这样区分：

  • 函数调用定义模型如何调用函数；
  • MCP 为这些函数及相关能力的来源提供可复用的协议。

MCP 工具最终仍然可以通过宿主应用常规的工具调用机制呈现给模型。

例如，OpenAI 目前的 MCP 文档支持将模型连接到远程 MCP 服务器，也支持通过 MCP 隧道连接本地或私有服务器。API 会发现服务器提供的工具，并将它们提供给模型使用。

MCP 不会取代 REST API

MCP 服务器通常构建在现有 API 之上。

如果你的业务系统已经提供：

POST /refunds

你就不需要为了 MCP 重新构建支付系统。

你可以提供一个 MCP 工具，例如：

issue_refund(order_id, reason)

然后由服务器在内部调用现有 API。

REST API 仍然是服务的业务操作接口。MCP 则成为面向 AI 的互操作层。

这种区别很重要，因为现有 API 可能已经包含：

  • 业务规则；
  • 授权控制；
  • 输入验证；
  • 幂等性；
  • 审计；
  • 事务语义。

MCP 不应无谓地重复承担这些职责。

MCP 不会取代智能体框架

MCP 不会决定：

  • 智能体应该追求什么目标；
  • 应该先调用哪个工具；
  • 智能体是否应该重试；
  • 何时停止；
  • 记忆机制如何运作；
  • 何时需要审批；
  • 多智能体之间如何协调。

这些都是编排层面的决策。

智能体框架可以使用 MCP 服务器来获取工具和上下文，但 MCP 本身并不是推理循环。

这是围绕该协议最常见的概念误区之一。

一个连接了十个 MCP 服务器的系统，并不会因此自动获得更强的智能体能力。它只是拥有十个提供标准化能力的服务方。

MCP 不会取代 RAG

RAG（检索增强生成）和 MCP 可以协同工作，但它们解决的问题不同。

RAG 要回答的是：

我应该检索哪些证据，并将它们放入模型的工作上下文？

MCP 要回答的是：

AI 应用如何以标准化方式连接外部能力提供方？

MCP 服务器可以提供由向量数据库支持的搜索工具或文档资源。

但这并不意味着 MCP 本身定义了文本分块、排序、向量嵌入、检索质量、引用逻辑或事实依据策略。

这些仍然是应用程序和检索系统需要负责的问题。

MCP 实际标准化了什么

协议的价值体现在它使哪些边界变得可预测。

MCP 为以下方面提供了共同约定：

  • 能力发现；
  • 结构化工具定义；
  • 资源与提示词；
  • 客户端与服务器通信；
  • 传输方式；
  • 授权模式；
  • 错误处理和协议行为。

当前的官方 SDK 支持多种常用传输方式，包括本地 stdio 和 Streamable HTTP。

因此，在概念上相同的服务器可以应用于不同环境：由编程工具在本地使用，由托管的 AI 产品远程使用，或部署在企业基础设施内部。

这种可移植性是它主要的架构优势。

一个具体例子

设想一家公司拥有内部库存系统。

现有后端已经提供以下 API：

  • 搜索商品；
  • 查询库存；
  • 创建库存预留；
  • 释放库存预留。

公司无需将这些 API 分别集成到每一个 AI 应用中，而是可以创建一个 MCP 服务器。

这个服务器提供：

  • search_products(query)；
  • get_inventory(product_id)；
  • reserve_inventory(product_id, quantity)；
  • release_reservation(reservation_id)。

现在，兼容的 AI 宿主应用都可以通过同一协议发现这些能力。

MCP 服务器并不会因此成为库存数据库。

它也不会成为授权系统。

它不会决定智能体是否有权预留 10,000 件商品。

它只是为访问这些现有系统提供标准化接口。

安全边界仍然由你负责

标准化连接可以让集成变得更容易，也可能让不安全的集成变得更容易。

因此，信任模型非常重要。

OpenAI 目前的 MCP 指南明确警告：远程 MCP 服务器可能接收敏感数据，恶意服务器可能带来提示词注入和数据外泄风险。

重要的控制措施包括：

  • 通过允许列表，仅开放智能体真正需要的工具；
  • 对敏感操作要求审批；
  • 将凭据保存在模型生成内容之外；
  • 在适当情况下使用 OAuth 或同等的授权机制；
  • 验证连接的每一个服务器；
  • 限制发送给第三方服务器的数据；
  • 为影响重大的操作保留审计日志。

MCP 为你提供了协议，但并不意味着每台服务器都自动值得信任。

工具描述会成为系统行为的一部分

模型会根据工具的名称、描述和 schema 决定调用什么，因此工具设计也成为智能体控制面的组成部分。

例如，下面这个设计欠佳的工具：

manage_account(input)

会带来歧义。

相比之下，多个职责明确、范围较小的工具通常更容易分析：

  • get_account_status(account_id)；
  • update_billing_address(account_id, address)；
  • cancel_subscription(account_id, reason)。

清晰的能力边界有助于改善：

  • 工具选择；
  • 权限设计；
  • 可审计性；
  • 评估；
  • 人工审核。

MCP 标准化的是能力如何对外提供，但良好的工具设计仍然是工程责任。

当能力复用很重要时，MCP 最有价值

你很可能不需要为每一个内部函数都使用 MCP。

如果某个工具只属于一个应用，而且永远不会被其他客户端使用，直接进行函数调用可能更简单。

以下情况会让 MCP 更有价值：

  • 多个 AI 客户端需要使用相同的能力；
  • 能力需要在不同宿主应用之间移植；
  • 组织希望建立可复用的集成边界；
  • 本地与远程工具需要使用相似的接口；
  • 外部开发者或团队需要使用同一套能力契约。

该协议减少了重复的集成工作。

但它并不能替代架构判断。

实用决策对照表

问题 直接使用工具／函数 MCP
单个应用、单项私有集成 通常更简单 可能没有必要
多个 AI 宿主应用使用相同工具 需要重复实现集成逻辑 非常适合
需要标准化的能力发现 需要定制实现 协议内置
已有 REST API 直接调用 MCP 服务器可以封装该 API
本地开发者工具 需要定制进程集成 stdio 很适合
远程共享能力 需要定制 HTTP 契约 Streamable HTTP 很适合
仍然需要授权控制 是 是
是否包含智能体规划／编排 否 否

MCP 不能解决的问题

明确来说，MCP 不能解决以下问题：

1. 工具的正确性

即使故障工具符合标准协议，它仍然是有故障的工具。

2. 授权策略

你仍然需要决定哪些用户、智能体或组织可以执行哪些操作。

3. 提示词注入

外部内容仍然可能包含恶意指令或相互冲突的指令。

4. 智能体的可靠性

你仍然需要评估、追踪、重试机制、停止条件和故障处理。

5. 业务语义

该协议无法判断在你的业务领域中，退款、贷款审批或资源删除是否有效、合规或合理。

6. 数据质量

MCP 可以提供数据，但不会让过时或错误的数据因此变得可信。

7. 可观测性

你仍然需要应用层的日志、指标、追踪数据和审计记录。

设计原则

当你需要在 AI 应用与外部能力之间建立可复用的互操作边界时，就使用 MCP。

将业务逻辑、权限、作为事实依据的数据以及运行保障留在原本负责这些职责的系统中。

把 MCP 视为基础设施。

它本身不是智能。

不是治理机制。

也不能单独提供安全保障。

它不是智能体框架。

良好的 MCP 集成能够让各种能力更容易连接，同时保持其底层职责清晰明确。

这才是该协议真正的价值。

参考资料