ImQi1云笔记

外观

MCP

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 在2024年1月提出的一套开放协议，旨在实现大型语言模型（LLM）与外部数据源和工具的无缝集成，用来在大模型和数据源之间建立安全双向的链接。​

Anthropic的愿景，希望把MCP协议打造成AI世界的“Type-C”接口，可以通过MCP协议工具、数据链接起来，达类似HTTP协议的那种通用程度。

特性传统 REST API（如 Flask）MCP（模型上下文协议）
设计哲学面向资源（Resource-Oriented）面向能力（Capability-Oriented）
核心概念操作的是“资源”，如用户、订单。使用 HTTP 动词（GET、POST、PUT、DELETE）对资源进行增删改查。操作的是“工具”或“函数”。核心是远程过程调用（RPC）。
自发现能力弱。需要依赖 OpenAPI/Swagger 等外部文档才能知道有哪些 API 端点和参数。强（核心特性）。协议内置了 get_tools 这样的元调用，客户端可以程序化地查询服务端有哪些可用工具。
标准化程度灵活但松散。虽然有 RESTful 风格指导，但实现五花八门。高度标准化。请求和响应的结构由 JSON-RPC 规范严格定义，减少了模糊性。
适用场景Web 应用、移动应用后端、数据驱动的服务。为大模型或 Agent 提供工具。专为“调用一个函数并获得结果”这个场景优化。

MCP 协议组成

整体结构：

MCP
├── Transport
│   ├── STDIO
│   ├── HTTP
│   └── SSE
│
├── JSON-RPC
│   ├── Request
│   ├── Response
│   └── Notification
│
├── Lifecycle
│   ├── initialize
│   └── initialized
│
├── Tools
│   ├── tools/list
│   └── tools/call
│
├── Resources
│   ├── resources/list
│   └── resources/read
│
├── Prompts
│   ├── prompts/list
│   └── prompts/get
│
└── Sampling
    └── 调用宿主模型
MCP Host（宿主）

用户直接使用的 AI 应用，负责接收用户请求、协调工具调用并生成最终结果。

例如：

  • Claude Desktop
  • Cursor
  • OpenAI Agent
  • VS Code AI 插件
MCP Client（客户端）

MCP 协议通信层，负责与 MCP Server 建立连接、发现工具、发送请求和接收响应。

通常内置于 Host 中，开发者一般无需直接编写。

MCP Server（服务端）

能力提供者，向 AI 暴露工具、资源和提示词等能力。

例如：

  • 文件系统操作
  • 数据库查询
  • GitHub 操作
  • 浏览器控制
  • 自定义业务接口
Tools（工具）

Server 提供给 AI 调用的函数或能力，是 MCP 中最常用的组成部分。

例如：

@mcp.tool()
def get_weather(city: str):
    return "晴天"
Resources（资源）

供 AI 读取的数据资源，类似只读数据源。

例如：

  • 配置文件
  • 文档
  • 数据库记录
  • 本地文件
Prompts（提示词模板）

Server 提供的可复用 Prompt 模板，帮助 AI 快速完成特定任务。

例如：

  • 代码审查
  • 文档总结
  • 数据分析

如果从协议层面最简洁地概括：

MCP = Host + Client + Server

Server = Tools + Resources + Prompts

MCP 角色组成

MCP 包括两个核心角色：服务端和客户端。

MCP服务端 (Tool Provider)：​

  • 角色：工具的提供者。​
  • 职责：将一个或多个本地函数（例如，Python函数）包装起来，通过一个标准的MCP接口暴露出去。它监听来自客户端的请求，执行对应的函数，并返回结果。​
  • 例子：一个天气查询服务、一个数学计算服务、一个数据库访问服务。​

​ MCP客户端 (Tool Consumer)：​ ​

  • 角色：工具的调用者或消费者。​
  • 职责：连接到MCP服务端，查询可用的工具列表（自发现），并根据需要调用这些工具。

MCP 通信传输方式​

MCP协议本身与传输方式无关，mcp及python-a2a库等提供了两种常见的实现：stdio和基于HTTP的SSE。​

stdio (标准输入/输出)

​ stdio：一种非常经典和简单的进程间通信（IPC）方式。客户端启动服务端作为一个子进程。​

工作原理: 客户端通过写入子进程的标准输入 (stdin) 来发送请求，并通过读取子进程的标准输出 (stdout) 来获取响应。这种方式简单高效，无需网络开销。​

适用场景: 非常适合在本地环境中，将一个命令行工具或脚本快速封装成一个 MCP 服务。例如，server_stdio.py 文件中的代码就配置了这种传输方式。​

SSE (Server-Sent Events)​

​ SSE：一种基于 HTTP 的单向推送协议，它允许服务器在保持连接开放的情况下，持续向客户端发送事件流。​

工作原理: 客户端发起一个 HTTP 请求，服务器接收请求并保持连接，然后以 text/event-stream 格式将响应数据流式传输给客户端。这在 MCP 中被用来实现请求与响应的通信。​

适用场景: 适用于分布式或网络环境，当服务需要部署在远端，并通过网络供多个客户端访问时。​ ​

Streamable-HTTP (可流式 HTTP)​

​ Streamable-HTTP：MCP 提供的另一种基于 HTTP 的传输方式，它同样用于网络通信。​

工作原理: 客户端通过 HTTP 请求与服务器通信。与 SSE 的主要区别在于其传输格式和机制可能有所不同，但核心目的都是通过网络实现 MCP 协议。​

适用场景: 与 SSE 类似，适用于需要通过网络进行通信的分布式应用。

属性stdioSSE (Server-Sent Events)Streamable-HTTTP
通信方向双向 (请求 - 响应)单向 (服务器推送到客户端)双向 (双向流)
通信模式本地进程间通信 (IPC)网络通信 (长连接流)网络通信 (双向流)
主要用途封装本地命令工具仅服务端更新场景复杂、实时双向交互场景
是否容易丢数据否 (系统保障)否 (TCP 保障)否 (TCP 保障)
关键优势简单高效安全，无网络开销适用于简单单向推送，兼容性好灵活支持双向流，提升大型任务效率

许可证：署名 4.0 国际 (CC-BY-4.0)

2026 © 棋