决定把能力做成 MCP server 之后，第一个要拍板的问题不是「暴露哪些工具」，而是「用哪种传输」。这个选择会决定你的服务跑在哪、谁连得上、以及要不要处理鉴权。
我在给琅嬛选型时走过一遍，下面是整理出来的判断，以及对每种传输该在什么时候用的结论。
三种传输方式
stdio
stdio 把 server 作为客户端的子进程启动，通过标准输入输出通信。它是 MCP 最早的传输，也是最简单的：不用端口、不用 DNS、不用证书，客户端拉起来就能用。
代价是它只在本机有效。server 和 client 在同一个进程树上，远端客户端连不上；也没有跨进程的身份边界，本机能启动它就意味着信任了它。
适合：本地开发、单机工具、Claude Desktop 或 Cursor 这类桌面客户端的本地扩展。
HTTP with SSE
这是早期的 HTTP 传输：client 用 POST 发起请求，server 用 SSE（Server-Sent Events）把流式结果推回来。它第一次让 MCP 能跑在服务器上、被远端客户端访问。
但它有两个端点、两套语义，实现起来繁琐，官方也已经把它标记为旧的传输方式。新项目我不建议从它开始。
streamable HTTP
这是当前推荐的 HTTP 传输，也是 MCP 规范 里取代 SSE 的方案。它把请求统一到一个 /mcp 端点：POST 一个 JSON，返回既可以是普通 JSON，也可以是 SSE 流，由请求头协商。因为是标准 HTTP，鉴权可以沿用 Authorization 头。
适合：部署在服务器上的共享服务、多客户端访问、需要网络隔离或鉴权的场景。
怎么选
我的判断可以用三句话概括：
- 只在本机给一个桌面客户端用，选 stdio，最省事。
- 要跑在服务器上、给多个客户端共享，选 streamable HTTP。
- 新项目不要从 SSE 开始，它是历史遗留。
安全维度也要想清楚：stdio 的信任边界是「本机进程」；HTTP 的信任边界是「网络 + 鉴权」。前者几乎不用管，后者必须认真对待。
琅嬛为什么用 MCP over HTTP
琅嬛是部署在服务器上的知识服务，而不是某个桌面客户端的本地插件。它要同时服务多个 Agent 和客户端，所以必须走 HTTP，而不是 stdio。
具体实现上，琅嬛在 /mcp 提供 MCP over HTTP，用 Workspace API Key 作为 Bearer 鉴权。工具的完整清单可以在 琅嬛仓库 里核对。
如果你的 MCP server 迟早要被第二个客户端、或另一台机器访问，那么从 streamable HTTP 开始，而不是先做 stdio 再迁移。传输方式是一个早决定、晚改动成本高的选择。