关于模型上下文协议 (MCP) 的讨论层出不穷，今天我们来了解一下它到底是什么。从直觉上看，MCP像是AI应用的USB-C接口。
正如USB-C提供了一种标准化的方式，将设备连接到各种配件，MCP则标准化了AI应用与不同数据源和工具的连接方式。
让我们从技术角度稍微深入探讨。
MCP的核心是基于客户端-服务器架构，主机应用程序可以连接到多个服务器。
它有三个关键组成部分：
主机（Host）
客户端（Client）
服务器（Server）
在深入了解之前，先来看一张概览图?
主机（Host）
指任何提供AI交互环境的应用程序（例如Claude桌面、Cursor），可以访问工具和数据，并运行MCP客户端。
MCP客户端（Client）
在主机内运行，负责与MCP服务器进行通信。
MCP服务器（Server）
提供特定功能并访问数据，包括：
工具：使LLM通过服务器执行操作。
资源：向LLM暴露服务器中的数据和内容。
提示：创建可重复使用的提示模板和工作流。
了解客户端与服务器的通信机制是构建自己的MCP客户端和服务器的关键。
那么，客户端和服务器是如何通信的呢？
以下是一张图示，我们逐步解析……
首先是能力交换阶段：
客户端发送初始请求 (Initial Request)，了解服务器的能力。
服务器回应其能力细节 (Initial response)。
例如，当请求一个天气API服务器时，它可以回复可用的“工具”、“提示模板”以及其他资源。
完成交换后，客户端确认连接成功，然后继续进行后续的消息交换。
这种设计的强大之处在于
在传统的API设置中：
如果你的API最初需要两个参数（如地点和日期），用户会将这些参数集成到请求中。
但如果稍后你新增了一个必要参数（例如温度单位——摄氏或华氏），API的契约发生了变化。
这意味着所有使用你API的用户都必须更新代码以包括新参数。否则，他们的请求可能会失败、返回错误，或提供不完整的结果。
而MCP的设计如下：
MCP引入了一种动态且灵活的方式，与传统API形成鲜明对比。
例如，当一个客户端（如Claude桌面等AI应用）连接到一个MCP服务器（例如你的天气服务）时，它会发送初始请求了解服务器的能力。
服务器回应其可用的工具、资源、提示和参数详情。例如，若最初支持地点和日期，服务器会将这些作为能力的一部分进行通信。
如果后来你增加了一个单位参数，MCP服务器可以在下一次交换中动态更新其能力描述。客户端无需硬编码或预先定义参数——它只是查询服务器的当前能力并相应适配。
这样一来，客户端可以即时调整其行为，使用更新后的能力（如添加单位参数到请求中），而无需重新编写或重新部署代码。
未来我们将探索如何创建自定义MCP服务器，并围绕它们构建实践演示。敬请期待！
你觉得MCP是否比传统API设置更强大？
