MCP（模型上下文协议）

在 MCP 出现之前，一个 AI 应用想要让模型使用某个外部工具——数据库、文件系统、某个搜索 API——通常都要针对『这个应用 + 这个工具』的组合单独写一段集成代码。工具越多，这种一对一的集成工作量就越大。MCP 把这层连接标准化了：一个工具只需要被封装成一个 MCP 服务端，任何支持 MCP 的应用都可以直接接入它，不用重复开发。

MCP 由 Anthropic 发起并作为开放协议发布，其规范是公开的，后续也在朝着更开放、社区参与的治理方向演进。目前它是连接 AI 应用与外部上下文、能力这一领域里被引用最广泛的开放标准之一，不过这个方向还在快速演化，市面上也存在其他思路和方案。

在 MCP 的架构里，一个宿主应用（比如某个编程 Agent 或对话客户端）内部运行着一个 MCP 客户端，由它去连接一个或多个 MCP 服务端。每个服务端可以对外暴露三类能力：模型可以调用的工具（tools）、可以读取作为上下文的资源（resources），以及可以复用的提示词模板（prompts）。至于模型到底能看到什么、能调用什么，由宿主应用来决定和控制。

怎么运作

MCP 的通信基于 JSON-RPC 2.0，本地服务端通常走 stdio，远程服务端则用基于 HTTP 的传输方式。客户端连接上服务端后，会先做一次『能力协商』：问服务端支持哪些工具、资源和提示词，服务端如实回应。之后，模型（通过宿主应用）就可以用结构化参数调用某个工具、按 URI 读取某个资源、或者拉取某个提示词模板，服务端再返回结构化的结果。因为不管服务端背后具体做什么，协议本身是统一的，所以同一套 MCP 客户端实现，可以不加改动地对接文件系统服务端、数据库服务端、项目管理服务端等各种不同的服务。

举个例子

比如一个具备 MCP 客户端能力的编程 Agent，可以同时接入一个 github MCP 服务端（用来创建、查看 issue）、一个 postgres MCP 服务端（用来查数据库）、以及一个 filesystem MCP 服务端（用来读本地文件）——协议是同一套，具体某一步该调用哪个工具，由模型在运行时自行判断。

和相关概念的区别

常见误解

常见问题