MCP 协议 vs HTTP 协议完整区别

MCP：Model Context Protocol，模型上下文协议，专门给 LLM Agent 和工具服务之间通信； HTTP：Hypertext Transfer Protocol，超文本传输协议，通用应用层协议，网页、接口、微服务都在用。

先一句话核心差异： HTTP 是通用“请求-响应”传输框架；MCP 是在传输层之上，定义了一套【Agent ↔ 工具服务】专用的业务消息模型，MCP 可以跑在 HTTP（Streamable HTTP / SSE）上面，也可以跑在 stdio 管道上。

1. 层级关系（非常关键，很多人混淆）

MCP 不是替代 HTTP，二者不在同一层级：

HTTP：传输承载层（负责字节流、连接、状态码、Header、路由、重试）
MCP：应用消息协议 / RPC 语义层（定义消息结构、能力协商、工具调用、资源读取、提示模板、会话生命周期）

MCP 的三种标准传输绑定：

stdio：不走 HTTP，父子进程管道（本地 MCP Server 最常用）
SSE over HTTP：老的流式传输方式，HTTP 长轮询/SSE
Streamable HTTP：官方主推新版，基于标准 HTTP POST + JSON-RPC 2.0，支持流式、可复用连接

👉 简单说：Streamable HTTP 只是 MCP 的一种 transport（传输绑定），MCP 的消息体是 JSON-RPC 2.0 规范的。

2. 核心定位 & 设计目标对比

维度	HTTP	MCP
设计初衷	浏览文档、资源获取、通用客户端 ↔ 服务端交互（浏览器、后端API）	LLM Agent 和外部工具/资源之间上下文协作
交互范式	经典：单次请求 → 单次响应；也支持SSE/WS流式，但不是原生语义	面向会话、能力协商、多轮工具协作；内置工具发现、资源、prompt模板、日志、进度通知
角色模型	固定：Client ↔ Server	固定：Client（Agent/LLM端） ↔ Server（工具服务端）
语义重心	资源（URL）、Method（GET/POST/PUT）、状态码	能力（tools/resources/prompts）、JSON-RPC 方法调用、会话状态、通知推送
无状态	HTTP 设计上默认无状态（cookie/token是上层扩展）	MCP 原生面向会话：会话ID、能力握手、客户端和服务端互相交换支持的能力

HTTP 关心：你要哪个资源，成功还是失败； MCP 关心：我有哪些工具可以给大模型用，调用工具、读文件、拿资源、推送进度、返回结果给模型。

3. 消息模型：REST HTTP(JSON) vs MCP(JSON-RPC)

普通 HTTP JSON API（REST）

POST /api/query
Content-Type: application/json
{
  "city": "上海"
}
→ { "temp": 26 }

由 URL + HTTP Method 表达动作
响应就是返回数据，没有统一的错误结构、通知、进度回调标准
服务端不知道“我要给LLM暴露一个工具”，工具描述、入参schema需要额外文档（OpenAPI）

MCP（底层是 JSON-RPC 2.0，跑在 Streamable HTTP / stdio）

// 客户端请求调用工具
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {"city": "上海"}
  }
}

内置固定标准方法：

initialize：握手、协商双方能力（最重要！HTTP没有标准握手）
tools/list：查询服务端有哪些工具、JSON Schema描述
tools/call：执行工具
resources/list / resources/read：读取文件/知识库资源
prompts/list：预定义提示模板
notifications/*：单向通知（日志、进度，不需要id回包）

✅ 重点： HTTP 没有 tools/list 这种标准语义！如果用普通HTTP做工具，你自己要定义一套“获取工具列表”接口，每家格式不一样，Agent无法自动适配。 MCP 统一了这套发现和调用规范，所以 Cursor、Claude Desktop 可以自动接入任意合规 MCP Server。

4. 流式、通知、多轮交互差异

HTTP：标准HTTP1.1是一问一答；SSE/WS是扩展。没有原生“通知”语义，通知是自定义事件。断开重连后，没有标准会话恢复机制。
MCP：原生区分 请求（需要id、等返回） 和 通知（no id，单向推送，比如日志、工具执行进度） Agent 调用工具时，服务端可以一边跑任务一边持续推进度，模型实时看到日志。 initialize 握手交换协议版本、支持能力，防止版本不兼容。

5. 典型能力对照表

能力	HTTP	MCP
通用互联网传输	✅ 核心能力	❌ 只是可绑定在HTTP上，本身不解决路由、DNS、端口
自动工具发现	❌，依赖OpenAPI/人工文档	✅ 原生 `tools/list`
资源（文件/知识库）读取标准	❌，自定义接口	✅ `resources/*`
Prompt模板托管	❌	✅ `prompts/*`
双向能力协商握手	❌	✅ initialize 流程
单向进度/日志通知	只能SSE/WS扩展	✅ JSON-RPC notification 原生支持
本地进程间通信（管道）	❌	✅ stdio transport（MCP特色）
负载均衡、鉴权、TLS、缓存	✅ 成熟生态	✅ 交给下层HTTP transport实现

6. 常见误区澄清

误区1：MCP 替代 HTTP

❌ 错。 MCP 是消息语义协议；HTTP 是传输协议。Streamable HTTP 就是 MCP 官方推荐的远程传输方式，二者搭配使用。

类比：HTTP = TCP；MCP = gRPC。gRPC 跑在HTTP/2上，但gRPC定义了自己的服务调用模型。更贴切类比：MCP（JSON-RPC）之于 Streamable HTTP ≈ gRPC之于HTTP/2

误区2：MCP 就是 JSON over HTTP

❌ 错。普通JSON over HTTP 没有标准化工具发现、资源、prompt、通知、握手；你写的API大模型客户端无法自动识别哪些是工具。 MCP 的价值是统一Agent工具契约，不是简单JSON。

误区3：MCP 只能远程访问

❌，MCP 最经典场景就是 stdio：本地子进程，完全不走HTTP，比如本地文件MCP、sqlite MCP。

7. 什么时候选哪个？

如果你做：网页、移动端接口、普通后端微服务、给程序调用的通用API → HTTP / REST
如果你做：给 Claude Desktop / Cursor /自研Agent 调用的工具服务，希望Agent自动发现、调用工具、读资源 → MCP
存量HTTP REST API想给Agent当工具：两种路线
1. 写一层适配层，包装成 MCP Server（ContextForge 就是干这个）
2. 直接用 OpenAPI + 自定义tool parser（没有MCP标准，兼容性差）

8. 极简总结（方便放进文档）

HTTP 是通用传输协议，解决网络请求、路由、字节传输；MCP 是面向LLM Agent的RPC消息协议，可搭载在HTTP上，也可以走stdio管道。
HTTP 没有工具发现、资源、prompt、通知的标准语义；MCP 内置这套统一契约，是Cursor/Claude等客户端能够即插即用工具的根本原因。
HTTP 默认无状态；MCP 原生基于会话握手、能力协商，面向大模型多轮工具调用场景。

如果你想要，我可以给你一段MCP Streamable HTTP 完整请求响应示例，和普通HTTP REST做并排对照。

MCP 协议 vs HTTP 协议 完整区别 ​

1. 层级关系（非常关键，很多人混淆） ​

2. 核心定位 & 设计目标对比 ​

3. 消息模型：REST HTTP(JSON) vs MCP(JSON-RPC) ​

普通 HTTP JSON API（REST） ​

MCP（底层是 JSON-RPC 2.0，跑在 Streamable HTTP / stdio） ​

4. 流式、通知、多轮交互差异 ​

5. 典型能力对照表 ​

6. 常见误区澄清 ​

误区1：MCP 替代 HTTP ​

误区2：MCP 就是 JSON over HTTP ​

误区3：MCP 只能远程访问 ​

7. 什么时候选哪个？ ​

8. 极简总结（方便放进文档） ​