1. 从京东二面那道题说起：MCP 通信层到底在选什么
先把这道题的核心检索词摆出来：MCP 协议通信层选型，本质是在 JSON-RPC 2.0 这个消息格式之上，决定用 stdio 还是 Streamable HTTP 把消息送到对端。它解决的问题是——同一个 MCP Server，怎么既能被本机桌面客户端调用，又能部署到云端被多个客户端共享。适合谁看：正在写 MCP Server 的后端、准备面试的初中级工程师、以及想把本地工具接进 AI 客户端但被配置卡住的人。
我先把 MCP 的分层讲清楚，因为后面所有取舍都建立在这上面。MCP 像 HTTP 一样分层：最上面是 tools / resources / prompts 这些业务能力，中间是 JSON-RPC 2.0 消息层，最下面是传输层。传输层只干一件事——把已经序列化好的 JSON-RPC 消息送到对端。切换传输方式，上层业务代码一行都不用改。这就是为什么同一个 Server 既能跑本地也能上云。
面试里最容易翻车的三个点：第一，本地场景想当然走 localhost HTTP，忽略了 stdio 的零网络开销；第二，远程场景觉得双向通信就该用 WebSocket，其实 Streamable HTTP 才是当前标准；第三，以为 SSE 被淘汰了，实际上被弃用的是「HTTP + SSE 双端点」这套架构，SSE 这个技术本身还在 Streamable HTTP 内部继续用。
这篇我会按「消息格式 → stdio → Streamable HTTP → 选型对比 → 落地踩坑 → 接入验证」的顺序走，每一步都给可复制的配置和命令。最后会把 endpoint 改到 TaoToken 的统一 API 通道，跑一次真实的连通性验证，让你不只是看懂，而是能亲手跑通。
2. JSON-RPC 2.0 消息格式与 stdio 本地传输怎么配
先看消息格式，因为不管底层走 stdio 还是 Streamable HTTP，每条消息长得都一样。MCP 选 JSON-RPC 2.0 而不是自己设计一套，理由很实在：它是 2010 年就定下来的成熟规范，Python、JS、Go、Rust 都有现成库；JSON 易读，出问题直接看日志；比 gRPC 轻量太多；而且天然支持请求、响应、通知三种模式。
一个工具调用请求长这样：
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_weather", "arguments": {"city": "Beijing"} } }对应的响应：
{ "jsonrpc": "2.0", "id": 1, "result": { "content": [{"type": "text", "text": "北京：晴，22°C"}] } }注意通知消息没有 id 字段，因为它是单向的，不需要响应：
{ "jsonrpc": "2.0", "method": "notifications/progress", "params": {"progress": 50, "total": 100} }这里有个常被忽视的细节：JSON-RPC 2.0 在消息层就支持双向通信。Server 可以主动给 Client 发通知，比如工具列表更新了；也可以反向请求 Client 干活，比如让 Client 侧的 LLM 帮忙生成内容。所以「要双向通信就得用 WebSocket」这个推论是错的——消息层已经解决了双向，传输层只要能把消息送过去就行。
现在讲 stdio。它适合 Server 和 Client 在同一台机器上的场景，比如桌面客户端调用本地的文件系统、Git、SQLite 工具。工作流程很朴素：Client 用 subprocess 拉起 Server 子进程，把请求 JSON 写到 Server 的 stdin，每条消息一行用换行符分隔；Server 处理完把响应写到自己的 stdout；Client 读 stdout 拿到结果。整个过程不经过网卡，不走 TCP/IP 协议栈，就在操作系统内核的 pipe 缓冲区里走一趟。
一个最小可运行的配置，以桌面客户端常见的claude_desktop_config.json为例：
{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/Documents" ] } } }Client 启动时会执行npx -y @modelcontextprotocol/server-filesystem /Users/yourname/Documents，这个进程就是 MCP Server，它和 Client 之间通过 stdio 通信。stdio 的优点很明确：延迟极低，进程间内存通信比 localhost HTTP 还快；配置极简，不用分配端口、不用配防火墙、不用 TLS 证书；安全性高，没有监听端口，外部网络物理上访问不到；生命周期跟随 Client，Client 退出 Server 自动结束。
局限也要说清楚：只能本机，跨机器跑不动；每个 Client 启动一个独立 Server 进程，多个 Client 想共享同一个实例不行；某些受限环境可能没权限 fork 子进程。一句话，stdio 是本机场景的最优解，把工具调用降级成读写进程标准 IO，是 MCP 最聪明的设计之一。
3. Streamable HTTP 远程传输与 TaoToken 接入配置
Server 部署在云端、多个 Client 共享访问时，就得走网络。MCP 远程传输的当前标准是 Streamable HTTP，核心是单个 HTTP 端点，通常是/mcp。Client 用 HTTP POST 发 JSON-RPC 请求，Server 的响应有两种形态：普通 JSON 一问一答，或者 SSE 流式推送。Server 根据请求性质自己决定用哪种，这就是 Streamable 这个名字的由来。
一个最简单的请求：
curl -X POST https://your-mcp-server.example.com/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'需要流式推送时，响应头是Content-Type: text/event-stream，body 长这样：
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{"progress":30}} data: {"jsonrpc":"2.0","method":"notifications/progress","params":{"progress":60}} data: {"jsonrpc":"2.0","id":1,"result":{...}}Streamable HTTP 的好处：Server 可云端部署，多 Client 共享同一实例；天然支持 HTTPS 和标准鉴权；流式推送顺畅，长任务不用轮询；对负载均衡和 serverless 友好，单端点架构在 nginx、API Gateway 上配置简单。
为什么不用 WebSocket？几个工程权衡：Streamable HTTP 跟现有 HTTP 基础设施完全兼容，CDN、防火墙、代理、鉴权全套适用，而很多企业代理对 WebSocket 不友好；实现复杂度上，单连接单端点比 upgrade 握手加双向连接管理简单；鉴权走标准 HTTP header，WebSocket 重连后要重新鉴权；serverless 环境大多不支持长连接。MCP 主要是文本消息，又强调和现有 HTTP 基础设施兼容，选 Streamable HTTP 很合理。
现在把 endpoint 改到 TaoToken 的统一 API 通道。TaoToken 提供统一的 Key 和 API 入口，你可以把远程 MCP Server 的调用地址指向它，用同一套鉴权完成调用验证。先拿 Key：访问 API Keys 页面https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite创建密钥。接入文档在https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite。
一个可复制的 MCP Server 配置片段，把 Base URL、Key、Model ID 三件套写全：
{ "mcpServers": { "remote-tools": { "url": "https://taotoken.net/api/mcp", "headers": { "Authorization": "Bearer sk-your-taotoken-key", "Content-Type": "application/json" }, "transport": "streamable-http", "model": "claude-sonnet-4-5" } } }如果你用的是支持 TOML 配置的客户端，等价写法：
[mcp_servers.remote-tools] url = "https://taotoken.net/api/mcp" transport = "streamable-http" model = "claude-sonnet-4-5" [mcp_servers.remote-tools.headers] Authorization = "Bearer sk-your-taotoken-key" Content-Type = "application/json"注意 Base URL 用https://taotoken.net/api，不要加 UTM 参数到 API 地址上，UTM 只用于页面跳转的归因。Key 从 API Keys 页面拿，Model ID 按你实际要调用的模型填。这三件套缺一不可，后面排障章节会反复用到。
4. 连通性验证：一次真实的 tools/list 请求与结果
配置写完不能只看，得跑一次验证。我习惯先用 curl 直接打端点，确认网络和鉴权没问题，再放进客户端。
第一步，验证 Key 和端点是否通：
curl -sS -X POST https://taotoken.net/api/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-your-taotoken-key" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'正常返回应该是一个 JSON-RPC 响应，result.tools里列出可用工具：
{ "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "get_weather", "description": "查询指定城市天气", "inputSchema": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } ] } }第二步，实际调一次工具，确认端到端能跑通：
curl -sS -X POST https://taotoken.net/api/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-your-taotoken-key" \ -d '{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_weather", "arguments": {"city": "Beijing"} } }'返回里result.content[0].text就是工具执行结果。如果这一步拿到了内容，说明 Base URL、Key、Model ID 三件套都对了，Streamable HTTP 通道也通了。
第三步，如果你要验证模型对话本身，可以到模型对话页面https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite直接试。长期做编码或 Agent 任务的话，Coding Plan 页面https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite更适合，控制台在https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite。
验证时有个细节：Streamable HTTP 握手阶段会建立 session，响应头里带Mcp-Session-Id。后续请求要带上这个 id，否则可能报 session not found。用 curl 手动测时可以先看响应头：
curl -sS -D - -X POST https://taotoken.net/api/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-your-taotoken-key" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' \ | head -20看到Mcp-Session-Id: xxx就说明 session 建起来了。多实例部署时，同一个 session 的请求必须路由到同一个实例，要么用粘性会话，要么把 session 状态外置到 Redis，否则会出现「tools/list 成功、tools/call 报 session not found」这种诡异 bug。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
这一章按真实报错来对，每个都给定位思路。
401 Unauthorized。最常见的原因是 Key 没带对或过期。先确认 header 里是Authorization: Bearer sk-xxx，注意 Bearer 后面有一个空格。然后去 API Keys 页面https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=mcp_streamable_http&utm_campaign=rewrite确认 Key 还有效。如果 Key 是从环境变量读的，检查有没有多余换行或引号。还有一种情况是把 UTM 参数拼到了 API 地址上，导致请求打到了错误路径，API 地址就是https://taotoken.net/api，干净的不带参数。
local proxy failed。这个报错通常出现在客户端配置了本地代理但代理没起来，或者代理地址写错。检查客户端配置里有没有残留的 proxy 设置，把它清掉，让请求直连。如果你在受限网络环境，确认网络策略允许访问目标端点。这个报错和 MCP 协议本身无关，是网络层问题。
reading choices 相关报错。这类报错一般出现在模型响应解析阶段，说明请求发出去了、也拿到了响应，但响应结构不符合预期。常见原因是 Model ID 填错，或者请求里带了模型不支持的参数。回到配置里核对 Model ID，确保和实际调用的模型一致。如果用的是流式响应，检查客户端是否正确处理了 SSE 格式，data:前缀和空行分隔不能少。
OAuth 相关报错。Streamable HTTP 支持 OAuth 2.0，多租户场景常用。如果报 OAuth 错误，先确认 token 有没有过期，刷新逻辑是否正常。OAuth 的 token 刷新要写对，两条连接各自维护鉴权的情况在单端点架构下已经不存在了，但 token 过期后要能自动刷新。如果客户端不支持 OAuth，改用 Bearer Token 更简单。
stdio 模式下的日志陷阱。这个不算报错但很致命：MCP Server 把日志 print 到了 stdout。stdio 模式下 stdout 是 JSON-RPC 通信通道，你随便 print 一句调试信息，Client 直接解析失败，整个 Server 就挂了。正确做法是所有日志写 stderr，用 Python 的 logging 模块时显式指定stream=sys.stderr，调试时把 stderr 重定向到文件，stdout 留给 JSON-RPC。
session not found。前面提过，多实例部署时 session 路由错了。要么配粘性会话，要么把 session 外置到 Redis。单实例部署一般不会遇到。
不要手写 JSON-RPC 解析器。JSON-RPC 2.0 看着简单，但错误码、batch 请求、通知和请求的区分这些细节坑很多。直接用官方 SDK，@modelcontextprotocol/sdk或 Python 的mcp包，别自己造轮子。手撸解析器忘了处理 batch 请求，Client 一发批量调用整个 Server 就报错。
6. 选型口诀与接入路径
把 stdio 和 Streamable HTTP 放一起对比，选型就清楚了。stdio 适合本机工具调用，走进程 stdin/stdout pipe，延迟极低，不能跨机，每个 Client 一个 Server 进程，不需要鉴权，流式推送直接写 stdout，生命周期跟随 Client，典型代表是 filesystem、git、sqlite 这类本地工具，配置入口是claude_desktop_config.json的 command 和 args。Streamable HTTP 适合远程 Server 和多 Client 共享，走 HTTP/HTTPS，有网络延迟，能跨机，共享同一个 Server 实例，需要 OAuth 或 API Key 鉴权，流式推送用 SSE 响应，Server 独立运行，典型代表是各种 SaaS 工具和云端 MCP Server，配置入口是 HTTP URL 加鉴权信息。
选型口诀就一句：能跑本地就 stdio，延迟最低、配置最简、安全性最高；必须远程才 HTTP，需要多 Client 共享、需要云端能力、需要鉴权审计。
再强调一遍那个最容易翻车的细节：被弃用的是「HTTP + SSE 双端点」架构，不是 SSE 技术本身。Streamable HTTP 在需要流式推送时，响应内部仍然走 SSE。旧的双端点方案用/sse和/messages两个端点，两条连接要绑定同一个 session，重连逻辑头疼，对负载均衡不友好，serverless 跑不了，鉴权还要维护两份。Streamable HTTP 把两个端点合并成一个，session 管理只要绑定一条 HTTP 连接，绝大多数请求是普通 HTTP，serverless 也跑得了。
接入路径按你的场景选：排障和接入问题看 API Keys 页面加接入文档；验证模型效果去模型对话页面；长期编码或 Agent 任务用 Coding Plan。三个入口前面都给过带归因的链接，按需取用。
最后留个真实经验：新项目直接上官方 SDK 的双模式支持，业务逻辑代码完全相同，传输层切换是一行配置的事。别自己造「stdio 到 HTTP 的转换层」，stdio 一行一条消息但 HTTP 是请求响应配对，转换时容易丢消息。把这些工程细节提前避开，比追新规范版本更有价值。
