首先回顾下MCP 出现之前，我们是如何使用大模型的。RAG 和 Agent是大模型应用开发的目前最常用，也最通用的两个范式。然而，要让你的大模型拥有各种工具调用能力，绝非易事。而有了 MCP 协议，无论是 RAG，还是 Agent+Tool Calls（或称 Function Calling），这两个大模型应用开发的关键范式，都将得益于 MCP 提供的工具发现和主动调用能力。

MCP（模型上下文协议）是一个开放标准，用于将 AI 连接到数据库和工具，就​​像专为 LLM 构建的 API 层一样。你可以将 MCP 想象成 AI 应用程序的“USB-C 接口”。正如 USB-C 为你的设备提供了连接各种外设的标准方式，MCP 为 AI 模型提供了连接不同数据源和工具的标准方式，也就是说MCP增强了RAG 和 Agent。

所有的工具或者服务提供商（如 Github、Milvus、PostgreSQL、Snowflake 或 Spark）都会按照 MCP 协议制定的标准定义一个共享接口，那就无需每个开发团队都分别与他们构建一次性集成，而 MCP 客户端中的 LLM 可以无缝地接入该接口。 对于 RAG 来说，MCP 通过定义统一的 SessionMessage 协议和工具发现机制，使 RAG 能够无缝接入多源数据检索，只需一次集成即可动态检索并注入上下文，大幅提高了检索增强生成的准确性和可维护性。 同时，MCP 为 Agent 提供了标准化的工具调用接口和结果回传格式，让大模型可以自主选择、分步调度各类工具执行复杂任务，无需手动注册或编码集成。这将显著提升 Agent 应用的开发效率和扩展能力。

在 MCP 架构中，“Host” 指的是最终部署大模型和用户界面的应用的平台，比如桌面端的 Claude 客户端、IDE 插件或自研的聊天机器人后台。一个 Host 启动时，会在内部创建一个 MCP Client 实例，这个 Client 负责与外部的 MCP Server 建立一对一的连接（通常通过 stdio、HTTP+SSE 或其他支持的传输层）。

 接入层面的 “Client” 正是这个 MCP 客户端，它把上层业务或大模型交互中产生的“请求”（例如“列出可用工具”“执行代码分析”）打包成符合 JSON-RPC 2.0 的消息，再通过底层传输通道发给 Server；同时，它也能接收来自 Server 的 Notification（如“工具状态更新”），并把所得数据交回给 Host，以便拼接到模型的 Prompt 中或做二次处理。

而 MCP “Server” 则是真正提供上下文内容和工具执行能力的进程或服务。它在启动时会注册一系列接口（Resource 列表、工具调用、文件系统访问、外部 API 调用等），并监听来自 Client 的 JSON-RPC 消息。当收到“调用某个工具”这样的请求时，Server 会校验参数、调用相应逻辑，将结果封装成 Result 消息回传；如果出现异常，则返回带有标准错误码（如 ParseError、InvalidParams、MethodNotFound）的 Error 响应。

整个交互流程可以分为三个阶段。

1.握手初始化：Host 的 MCP Client 向 Server 发起 initialize 请求，双方交换协议版本与能力列表，并用 initialized 通知确认；

2.正常通信：Client/Server 可双向发起 Request–Response（同步调用）或单向 Notification（异步事件），大模型应用只需按需调用 Client 的接口； 

3.优雅收尾：通信完成后，任意一端可调用 close() 或因底层通道断开而触发连接关闭。

在上面的 MCP 连接生命周期中，Client 和 Server 之间可以传递下列类型的 MCP 消息类型：

1.Request：期待收到响应。

2.Result：请求成功的响应。

3.Error：请求失败时返回。

4.Notification：单向消息，无需响应。

通过这种分层设计，MCP 将“业务逻辑”与“上下文 / 工具管理”解耦：Host 只管“我需要哪些信息 / 能力”；Server 负责“我怎样取到或实现这些能力”。最终，在 Host 内部，大模型得到的不再是死板的 API 返回值，而是经过精心组织的上下文提示，能够更灵活、更安全地调用外部工具、访问数据源，这样就扩展了大模型能力，让它可以对接更多复杂场景。