mcp学习笔记（一）-mcp核心概念梳理

Model Context Protocol (MCP) ，即模型上下文协议 ，是一个开放标准和开源框架 ，旨在为大型语言模型（LLMs）应用提供一个标准化的接口，使其能够无缝集成和交互外部数据源、工具和系统。

其主要作用为：

提供标准化接口，让LLMs（或基于LLMs构建的AI代理）能够连接到各种外部资源，如数据库，文件系统，Service Api，爬虫等资源，获取到数据。
LLMs可以实时与mcp双向交互，及时更新LLM中的上下文信息并能够即时执行LLM发出的指令，完成任务。
解决碎片化：统一不同LLM和服务的交互方式，能够灵活切换不同的 LLM 提供商和厂商，简化了开发人员构建AI应用或将AI功能集成到现有系统中的复杂性。
数据安全：在你的基础设施内安全地处理数据

mcp架构

角色

MCP 核心采用客户端-服务器架构

MCP Hosts: 如 Claude Desktop、IDE 或 AI 工具，希望通过 MCP 访问数据的程序
MCP Clients: 维护与服务器一对一连接的协议客户端
MCP Servers: 轻量级程序，通过标准的 Model Context Protocol 提供特定能力为 clients 提供resources、tools 和 prompts

分层

数据层

数据层实现了一个基于 JSON-RPC 2.0 的交互协议，其主要作用是定义 MCP 客户端和 MCP 服务端之间的架构和语义。

生命周期管理：处理客户端和服务端之间的连接初始化、能力协商和连接终止
核心源语：定义了客户端和服务端可以相互提供的内容。这些原语指定了可以与 AI 应用共享的上下文信息类型以及可以执行的操作范围。
实用特性：支持额外功能，如用于实时更新的"通知"和用于长时间运行操作的"进度跟踪"

生命周期管理

MCP 是一个有状态协议需要生命周期管理。生命周期管理的目的是协商客户端和服务端都支持的能力。

核心源语

Server层源语

工具 (Tools) ：AI 应用可以调用以执行操作的可执行函数（例如：文件操作、API 调用、数据库查询）
资源 (Resources) ：为 AI 应用提供上下文信息的数据源（例如：文件内容、数据库记录、API 响应）
提示词 (Prompts) ：帮助构建与语言模型交互的可重用模板（例如：系统提示词、少样本示例）

每种原语类型都有关联的发现 ( */list)、获取 ( */get) 以及在某些情况下的执行 (tools/call) 方法。MCP 客户端将使用 */list 方法来发现可用的原语。例如，客户端可以先列出所有可用工具 (tools/list) 然后执行它们。这种设计允许列表是动态的。

Client层源语

采样 (Sampling) ：允许服务端请求客户端 AI 应用进行语言模型补全。当服务端作者想要访问语言模型，但希望保持模型独立且不愿在 MCP 服务端中包含语言模型 SDK 时，这非常有用。他们可以使用 sampling/complete 方法请求客户端 AI 应用进行语言模型补全。
引导 (Elicitation) ：允许服务端向用户请求额外信息。当服务端作者想要从用户那里获取更多信息或请求对某项操作的确认时，这非常有用。他们可以使用 elicitation/request 方法向用户请求额外信息。
日志记录 (Logging) ：使服务端能够向客户端发送日志消息，用于调试和监控目的。

实时特性

该协议支持实时通知，以实现服务端和客户端之间的动态更新。例如，当服务端的可用工具发生变化时------比如新功能上线或现有工具被修改------服务端可以发送工具更新通知，以告知已连接的客户端这些变化。通知以 JSON-RPC 2.0 通知消息的形式发送（不期望响应），并使 MCP 服务端能够向已连接的客户端提供实时更新。

传输层

定义使客户端和服务器之间实现数据交换的通信机制和通道，包括特定于传输的连接建立、消息框架和授权。有两个主流的transport方式：Stdio和Streamable HTTP transport

Stdio transport：使用标准输入/输出流进行同一机器上本地进程之间的直接进程通信，提供最佳性能而没有网络开销。
Streamable HTTP transport：使用HTTP POST进行客户端与服务器之间的消息传输，并可选地使用服务器推送事件实现流媒体功能。该传输方式支持远程服务器通信，并支持包括持有者令牌、API密钥和自定义头在内的标准HTTP身份验证方法。MCP建议使用OAuth来获取身份验证令牌。

Stdio

定义：使用标准输入/输出流进行同一机器上本地进程之间的直接进程通信，提供最佳性能而没有网络开销。
适用场景：Local Mcp Server，例如Claude Code连接localfilesystme server
核心优势：

- 零网络依赖：无需配置网络环境，适合本地开发调试。
- 高安全性：数据仅在本地流转，避免远程泄露风险。
- 低延迟：直接通过内存或管道传输，性能高效。

局限性：

- 单进程限制：无法同时处理多客户端请求，扩展性差。
- 仅限本地：无法支持分布式或远程资源访问。

Streamable HTTP

定义：使用HTTP POST进行客户端与服务器之间的消息传输，并可选地使用服务器推送事件实现流媒体功能。该传输方式支持远程服务器通信，并支持包括持有者令牌、API密钥和自定义头在内的标准HTTP身份验证方法。。
适用场景：Remote Mcp Server，例如连接高德地图MCP Server，获取天气的MCP Server等等
核心优势：

- 无状态支持：去中心化、无强制要求持续连接，服务器可完全无状态运行，降低运维复杂度。
- 基础设施兼容：与CDN、API网关、负载均衡无缝集成。
- 灵活流式处理：支持按需切换为流式传输（如长文本生成进度推送）。

局限性：

- 实现复杂度：需处理会话ID和状态管理（可选）。

SSE

实际上mcp之前还支持SSE，现在官网上已经没有说明了，但是实际还是可以使用。

定义：通过HTTP长连接实现远程通信。服务器需提供两个端点：

- /sse（GET请求）：建立长连接，接收服务器推送的事件流。
- /messages（POST请求）：客户端发送请求至该端点。

核心优势

- 支持远程访问：突破本地限制，适用于分布式部署。
- 实时性：服务器可主动推送事件。

局限性

- 高可用性要求 ：服务器必须一直保持一个稳定、不中断的 SSE 长连接，否则通信就中断，如果中断了，也没有断点续连的能力，只能重新开始新的连接，之前的上下文可能会丢失。
- 单向性缺陷：客户端需通过额外HTTP请求发送数据，无法实现双向流式交互。
- 即将废弃 ：实际上mcp之前还支持SSE，现在官网上已经没有说明了，但是实际还是可以使用。官方计划用Streamable HTTP替代SSE。

SSE与Streamable的区别

Streamable 移除了 /sse端点，所有客户端 → 服务端的消息都通过 /message发送
Streamable的所有客户端 → 服务端的请求都可以被服务器升级为 SSE，以发送通知或请求
Streamable的服务器可以选择建立会话 ID 以维护状态