MCP（Model Context Protocol）是一个开放协议，用于标准化应用程序向大语言模型提供上下文的方式。可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化方式一样，MCP 为 AI 模型连接不同的数据源和工具提供了标准化方式。该协议用于将AI助手连接到数据所在系统，包括内容库、业务工具和开发环境。其目的是帮助前沿模型生成更好、更相关的响应。
- Anthropic MCP发布通告：https://www.anthropic.com/news/model-context-protocol
- MCP GitHub主页：https://github.com/modelcontextprotocol、https://modelcontextprotocol.io/introduction
MCP模型上下文协议
简单来说，现在企业和开发者要把不同的数据接入 AI 系统，都得单独开发对接方案，而 MCP 要做的，就是提供一个 “通用” 协议来解决这个问题。
Anthropic 在博客中解释说：“即便是最先进的模型，也受困于无法获取数据的限制，它们被困在信息孤岛和老旧系统之中。每接入一个新的数据源，就得重新开发一套对接方案，这让真正互联的系统很难大规模推广。”
MCP 解决了这一挑战。它提供了一个通用的开放标准，用于连接人工智能系统与数据源，用单一协议取代了碎片化的集成。结果是更简单、更可靠地让人工智能系统访问所需数据。
模型上下文协议是一个开放标准，它使开发人员能够在其数据源和AI工具之间建立安全的双向连接。该架构非常简单：开发人员可以通过MCP服务器公开其数据，或者构建连接到这些服务器的AI应用程序（MCP客户端）。
模型上下文协议的三个主要组成部分：
- 模型上下文协议规范和SDK
- Claude桌面应用程序中支持本地MCP服务器
- 一个开源仓库，包含MCP服务器
中国团队其实很早也开源过类似的智能体通信协议ANP（Agent Network Protocol），ANP最新版本已经能够让智能体自己组网。也许AI时代互联网的HTTP协议，正在被定义，并且彻底颠覆之前的互联网生态。
MCP通用架构
MCP 架构包含以下几个部分：
- MCP 主机：包括 Claude Desktop、IDE 等需要通过 MCP 访问资源的 AI 工具。
- MCP 客户端：与服务器保持一对一连接的协议客户端。
- MCP 服务器：一个轻量级程序，通过标准化的 MCP 协议开放特定功能。
- 本地资源：计算机上的数据库、文件和服务等资源，MCP 服务器可以安全地访问这些内容。
- 远程资源：通过互联网访问的 API 等资源，MCP 服务器可以与之建立连接。
可以看到，其中最主要的部分是 MCPServer，这是一个实现了本地资源或者远端资源交互的程序，并且实现 MCP 协议。Host 去调用资源时，实际上是通过不同的 MCPServer 去调用，比如 Server 可以是 GitHub 相关，也可以是 SQLite 相关。
例如，通过 MCP 去访问连接到本地 SQLite 数据库，整个流程如下图所示：
Server 和本地 SQLite 数据库之间的通信完全发生在本地，MCP 确保 Claude Desktop 只能通过明确定义的接口执行批准的数据库操作，所以这是一种安全的方式让 Claude 分析本地数据并与之交互，同时保持对其可以访问的内容的完全控制。通过该实例进行发散，如果要通过 MCP 访问更多的外部数据，就需要添加无数个 MCPServer。这种添加方式就类似于增加插件，那么现在 MCP 的能力就受限于 MCPServer 的个数。
MCP通信机制
MCP（Model Context Protocol）的连接机制遵循客户端-服务器架构。在这种架构中，MCP Clients与MCP Servers之间建立一对一的连接。
这种设计允许MCP Hosts（如AI应用程序）通过MCP Clients与一个或多个MCP Servers进行通信，以获取数据和执行任务。
MCP支持两种类型的通信机制：
标准输入输出（Stdio）：适用于本地进程间通信，其中Client启动Server程序作为子进程，消息通讯通过stdin/stdout进行，消息格式为JSON-RPC 2.0。
服务器发送事件（SSE）：SSE 全称是 Server-Sent Events，是一种 HTTP 服务器推送技术，允许服务器向客户端推送消息，而客户端到服务器的消息传递则使用HTTP POST，同样采用JSON-RPC 2.0格式进行消息交换。
所有传输都使用JSON-RPC 2.0进行消息交换，这为MCP Clients和MCP Servers之间的通信提供了统一的消息格式。至于连接类型，MCP没有明确指出是长连接还是短连接，但考虑到其基于JSON-RPC 2.0的特性，它更可能支持长连接，以便保持客户端和服务器之间的持久交互状态。MCP的通信协议可以是TCP或UDP，这取决于具体的实现和部署需求。
例如，如果MCP服务器和客户端在同一台机器上运行，可能会使用UDP。如果它们分布在不同的机器上，或者需要跨越网络边界，那么TCP可能是更好的选择，因为它提供了更可靠的传输保证。然而，MCP的设计允许它适应不同的网络环境和通信需求。
Streamable HTTP
近日，Anthropic又发布了MCP的更新，引入了一种新的“Streamable HTTP”传输方式，替代现有的HTTP+SSE方案。这一创新彻底解决了MCP远程传输的关键限制，同时保留了其原有优势，让MCP服务器变得更简单、更高效、更灵活，可以支持更大规模的分布式部署。
- 移除专用 /SSE端点：新机制取消了独立的 SSE（Server-Sent Events）端点，所有消息统一通过
/message端点传输，简化了服务器与客户端之间的交互流程。 - 动态升级 HTTP 请求为 SSE 流：服务器可根据需要将普通的 HTTP 请求动态升级为 SSE 流，实现更灵活的消息传递方式，支持实时通知和请求。
- 支持无状态服务器运行模式：新方案允许服务器在完全无状态的情况下运行，无需维持长期连接，显著提高了资源利用率，特别适合高并发场景的应用。
- 客户端通过 Header 提供 Mcp-Session-Id：客户端在请求中通过 Header 提供会话 ID，服务器可根据需要决定是否存储会话信息，增强了会话管理的灵活性。
- 简化部署与兼容性提升：开发者无需专门搭建 SSE 服务器，普通 HTTP 服务器即可支持 MCP，且新方案能够无缝集成 CDN、API 网关等网络基础设施，进一步推动了 AI 模型与应用间通信的发展。
为何不选择 WebSocket？
尽管存在其他替代方案如 WebSocket，Anthropic 基于其特性及 MCP 使用场景的考量，最终选择了保留 HTTP 并赋予其升级到 SSE 的能力。主要原因包括：
- WebSocket 需要维持长连接：MCP 主要采用类似 RPC 的模式，每个请求独立执行，WebSocket 的长连接特性会带来不必要的网络开销。
- WebSocket 无法传输 HTTP 头部信息：这导致身份验证过程变得复杂，难以与现有的认证机制无缝集成。
- WebSocket 仅支持 GET 升级：与 MCP 主要使用的 POST 请求不兼容，需要引入额外的升级流程，增加系统复杂性和延迟。
这次变革对开发者而言意义重大
- 部署更简便：不再需要专门搭建 SSE 服务器，普通 HTTP 服务器即可支持 MCP，降低了部署复杂度。
- 云平台兼容性提升：新方案更容易部署到不支持长连接的云平台，如 Vercel、Cloudflare 等，拓宽了部署选择。
- 基础设施无缝集成：作为标准 HTTP 实现，新方案能够与 CDN、API 网关、负载均衡等网络基础设施无缝集成，提升了系统的兼容性和扩展性。
- 支持无状态模式：服务器无需持续存储客户端会话信息，处理完请求后即可释放资源，适合高并发场景，提高了服务器资源利用率。
新方案在基础设施和服务器架构方面带来了革命性变化：
- 无状态服务器成为可能：服务器不再需要持续存储客户端会话信息，降低了服务器的维护成本和复杂性。
- 更适合微服务架构：新方案可轻松与 REST API、GraphQL、负载均衡、CDN 等系统集成，推动了微服务架构的发展。
- 服务器资源利用率更高：处理完请求后即可释放资源，适合高并发场景，能够支持更大规模的分布式部署。
Anthropic 的这一创新不仅优化了 MCP 的数据传输机制，也为未来的 AI 技术发展铺平了道路。随着 Serverless 架构的普及，越来越多的企业开始寻求轻量级、无状态的通信协议。Anthropic 的更新使 MCP 变得更加轻量级且灵活，服务器可自主决定是否支持流式传输，完美契合了 Serverless 架构的需求。
扩展内容阅读
Anthropic
Anthropic公司由OpenAI（ChatGPT的开发机构）前研究副总裁达里奥·阿莫迪（Dario Amodei）和 大语言模型GPT-3论文的第一作者汤姆·布朗（Tom Brown）等人共同创立。该公司于2024年11月25日发布了智能体生态协议MCP模型上下文协议，于2025年2月25日推出了全球首个混合推理模型Claude 3.7 Sonnet 智能模型「一个模型，两种思考方式，该模型能够在即时响应与逐步思考模式之间切换，模拟人类的快速反应与深度思考。它结合了传统大模型和推理模型的特性，既能实时生成答案，又能进行深度推理。」和代理编码工具Claude Code。
uv - Python依赖管理工具
uv 一个快速的 Python 包和项目管理器，用 Rust 编写。MCP开发要求借助uv进行虚拟环境创建和依赖管理。uv 这个Python 依赖管理工具，类似于 pip 和 conda，但它更快、更高效，并且可以更好地管理 Python 虚拟环境和依赖项。它的核心目标是替代 pip、venv 和 pip-tools，提供更好的性能和更低的管理开销。如果是一个新机器安装，没有任何缓存的情况下，uv 比 pip 和 pip-tools 快 8-10倍。
uv 特点
- 速度更快：相比
pip，uv采用 Rust 编写，性能更优。 - 支持 PEP 582：无需
virtualenv，可以直接使用__pypackages__进行管理。 - 兼容
pip：支持requirements.txt和pyproject.toml依赖管理。 - 替代
venv：提供uv venv进行虚拟环境管理，比venv更轻量。 - 跨平台：支持 Windows、macOS 和 Linux。
uv安装流程
方法 1：使用 pip 安装（适用于已安装 pip 的系统）
pip install uv方法 2：使用 curl 直接安装
如果你的系统没有 pip，可以直接运行：
curl -LsSf https://astral.sh/uv/install.sh | sh这会自动下载 uv 并安装到 /usr/local/bin。
uv基本用法介绍
安装 uv 后，你可以像 pip 一样使用它，但它的语法更简洁，速度也更快。注意，以下为使用语法示例，不用实际运行。
-
安装 Python 依赖
uv pip install requests与 pip install requests 类似，但更快。
-
创建虚拟环境
uv venv myenv等效于 python -m venv myenv，但更高效。
-
激活虚拟环境
source myenv/bin/activate # Linux/macOS
myenv\Scripts\activate # Windows-
安装
requirements.txt
uv pip install -r requirements.txt-
直接运行 Python 项目
如果项目中包含 pyproject.toml，你可以直接运行：
uv run python script.py这等效于：
pip install -r requirements.txt
python script.py但 uv 速度更快，管理更高效。
为什么MCP更推荐使用uv进行环境管理？
MCP 依赖的 Python 环境可能包含多个模块，
uv通过pyproject.toml提供更高效的管理方式，并且可以避免pip的一些依赖冲突问题。此外，uv的包管理速度远超pip，这对于 MCP 这样频繁管理依赖的项目来说是一个很大的优势。
