一句话解释

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 发起并开源的一套开放协议，规定了 AI 应用和外部工具、数据源之间“怎么对话”。有了它，一个工具只要按 MCP 实现一次，就能被所有支持 MCP 的 AI 应用直接使用。

它想解决什么问题

大模型要真正有用，就得能读你的文件、查你的数据库、调用你公司的内部系统。在 MCP 出现之前，常见做法是每个 AI 应用各自写一套接入代码：聊天客户端写一份 GitHub 插件，编程助手再写一份，另一个 Agent 框架又写一份。

如果有 M 个 AI 应用、N 个外部系统，最坏情况下要写 M×N 套集成，维护成本很高，而且各家接口格式互不兼容。

MCP 的思路和 USB 接口类似：定义一个统一标准，让“应用”和“工具”各自只对接这个标准。这样集成数量就从 M×N 降到 M+N。工具开发者写一个 MCP 服务器，应用开发者实现一个 MCP 客户端，双方就能互通。

架构：主机、客户端与服务器

MCP 里有三个角色：

主机（Host）：用户直接使用的 AI 应用，比如桌面聊天客户端、代码编辑器里的 AI 助手。它负责管理与模型的交互，并决定连接哪些服务器。

客户端（Client）：运行在主机内部的连接器，每个客户端与一个服务器保持一对一连接，负责收发协议消息。

服务器（Server）：对外暴露能力的轻量程序。比如一个“文件系统服务器”可以让模型读取指定目录，一个“数据库服务器”可以让模型执行查询。

协议消息基于 JSON-RPC 2.0 格式。传输方式上，常见的有两种：本地进程间通过标准输入输出（stdio）通信，适合在自己电脑上运行的服务器；以及基于 HTTP 的远程传输，适合部署在网络上的服务。

服务器能提供哪三类能力

MCP 服务器主要通过三种“原语”向 AI 应用提供能力：

工具（Tools）：可以被模型调用的函数，比如“创建 Issue”“发送消息”“执行 SQL 查询”。每个工具都带有名称、说明和参数格式（JSON Schema），模型据此判断何时调用、怎么传参。工具通常由模型主动决定使用。

资源（Resources）：可供读取的数据，比如文件内容、数据库表结构、API 返回的文档。资源一般由应用或用户决定是否放进上下文。

提示模板（Prompts）：服务器预先写好的、可复用的提示词模板，比如“代码审查”“总结会议纪要”，用户可以在应用里直接选用。

此外，协议也定义了一些由客户端提供给服务器的能力，例如允许服务器请求主机代为调用模型生成内容。

一次调用是怎么发生的

以“让 AI 助手帮你查一下仓库里未关闭的 Issue”为例：

  1. 主机启动时连接 GitHub 的 MCP 服务器，获取它提供的工具列表。
  2. 主机把这些工具的名称和说明告诉模型。
  3. 用户提问后，模型判断需要调用“列出 Issue”工具，并生成参数。
  4. 客户端把调用请求发给服务器，服务器访问 GitHub 接口并返回结果。
  5. 结果交回模型，模型整理成自然语言回答用户。

整个过程中，模型并不直接接触 GitHub 的接口或密钥，它只看到工具说明和返回结果。

MCP 和函数调用是什么关系

很多模型本身支持“函数调用”（Function Calling），即模型输出一段结构化的调用请求。MCP 并不取代它，而是位于它之上：函数调用解决的是“模型如何表达想调用什么”，MCP 解决的是“工具如何被发现、描述和执行，并且在不同应用之间通用”。

常见误区

误区一：MCP 是一个模型或一项 AI 能力。 MCP 只是通信协议，本身不让模型变得更聪明。模型能否用好工具，仍取决于模型能力和工具说明的质量。

误区二：接入 MCP 服务器是安全的。 服务器能执行代码、访问数据，本质上和安装一个软件一样需要谨慎。只使用可信来源的服务器，给它最小必要权限，对写入和删除类操作保留人工确认，都是基本做法。还要警惕“提示注入”：工具返回的内容里可能夹带诱导模型执行其他操作的指令。

误区三：有了 MCP 就不需要 API 了。 MCP 服务器内部通常仍然调用原有的 API，它只是给 AI 应用提供了一层统一的包装。

误区四：工具接得越多越好。 每个工具的说明都会占用上下文，工具过多还会让模型选错。按任务挑选需要的服务器即可。

延伸阅读