What is the Model Context Protocol (MCP)? - Model Context Protocol
依赖
pip install fastmcp anyio
server_sse.py
from fastmcp import FastMCP
# pip install fastmcp anyio
mcp = FastMCP("mcp‑helloworld-sse")
@mcp.tool()
async def hello_world(name: str) -> str:
"""hello world演示工具
Args:
name: 用户名字
"""
return f"Hello {name}, this is mcp‑helloworld! （sse）"
if __name__ == "__main__":
# 直接内置运行sse服务，不需要sse_app()
mcp.run(transport="sse", host="0.0.0.0", port=8000)
cherry studio 中配置
{
"mcpServers": {
"mcp‑helloworld_sse": {
"type": "sse",
"url": "http://127.0.0.1:8000/sse"
}
}
}
powershell
npx @modelcontextprotocol/inspector@latest http://127.0.0.1:8000/sse
mcpInspector 启动
MCP Inspector，MCP 官方的调试工具，相当于 MCP 协议的「调试控制台 / Postman」Model Cont...。
专门用来测试你写的 MCP Server，不用接入 Cursor/Claude，直接可视化调用工具、看完整 JSON‑RPC 报文、排查连接错误。
开发 MCP 的标准流程：
- 写代码 → 2. Inspector 调试验证工具完全正常 → 3. 再配置 Cursor/Claude Desktop。
不要直接丢给 Cursor 调试，Cursor 报错信息很模糊，Inspector 可以看到完整原始协议报文，定位问题快很多。
Inspector：专门给 MCP 协议用的 Postman 调试客户端（6274 端口 web 页面）
http://127.0.0.1:6274/
SSE 是什么
SSE = Server‑Sent Events，服务器推送事件，是 HTTP 协议的一个标准，单向长连接技术。
通俗大白话
普通 HTTP：
客户端（浏览器/Cursor）发请求 → 服务返回结果 → 连接立刻断开。每次拿数据都要重新发请求。
SSE：
客户端发起一次 GET 请求，建立一条持久的HTTP长连接，连接一直保持打开。
✅ 服务端可以源源不断主动往客户端发消息（ping心跳、业务数据）
❗注意：SSE 只能服务→客户端单向推；客户端要发给服务端，必须重新发起一次全新POST请求。
这就是 MCP SSE 模式为什么要两个接口：
-
GET /sse：建立SSE长连接，服务往客户端推送消息（ping心跳、工具调用返回结果） -
POST /messages?session_id=xxx：客户端发送MCP指令（list_tools、call_tool）发给服务端。
对比 WebSocket
| SSE | WebSocket | |
|---|---|---|
| 底层 | HTTP | HTTP握手后升级为双向TCP |
| 方向 | 服务→客户端单向推送；客户端发消息要另起POST | 双向互相收发消息 |
| 兼容性 | 普通HTTP代理、防火墙友好 | 部分网络环境会拦截ws升级 |
| MCP场景 | Legacy遗留传输，就是你现在跑的这套 | MCP不使用ws |
放到MCP协议里理解
MCP是JSON‑RPC协议，需要双向通信：客户端发指令，服务返回结果。
-
SSE做下行通道（服务→客户端）：服务把结果、ping心跳通过SSE长连接推给客户端，就是你浏览器看到的
: ping。 -
独立POST请求做上行通道（客户端→服务）：客户端把JSON‑RPC POST到
/messages。
所以SSE模式不是真正双向socket，是「SSE长连接 + 独立POST」组合实现双向RPC。
MCP现在新标准：Streamable‑HTTP
解决SSE要两个接口的麻烦，只用单个HTTP端点，既可以GET建立SSE流，也可以POST发请求，是官方推荐新项目用的模式。
你现在的链路完整流程
- Inspector/Cursor 发起
GET http://127.0.0.1:8000/sse→ 创建SSE长连接 - 服务返回
event:endpoint，告诉客户端消息投递地址/messages?session_id=xxx - 服务持续通过SSE推送
: ping保活，防止浏览器/代理把长连接掐断 - 客户端要调用工具：发起POST请求到上面拿到的/messages地址，发送json‑rpc
- 服务处理完工具逻辑，通过已有的SSE长连接把返回结果推回客户端。
浏览器直接打开
/sse只能看到服务推送下来的ping事件，浏览器不会自动发POST，所以浏览器不能直接当MCP客户端，必须用inspector、Cursor这类MCP客户端。
补充
配置里 "type":"sse" 的含义：告诉MCP客户端，使用这套「SSE长连接 + POST上行」这套传输逻辑，而不是默认的stdio子进程，也不是新的streamable‑http。
