本地与远程 MCP

一句话理解：stdio 是 Host 在本机启动一个子进程、用标准输入输出通信，适合个人和本地工具；Streamable HTTP 是一个可以被很多客户端访问的网络端点，适合团队共享和对外服务。选哪种，取决于数据在哪、谁来用、谁来运维。

同一个内部订单 MCP Server，可以打包成 npm 包让工程师在自己电脑上跑，也可以部署成 https://mcp.example.com/mcp 让全公司的 Agent 连接。代码几乎一样，产品形态却完全不同：安装方式、认证方式、升级方式、安全风险、成本结构都不一样。

MCP 规范定义了两种标准传输方式：stdio 与 Streamable HTTP。早期的 HTTP+SSE 传输已被弃用。

两种传输方式对比

维度	stdio（本地）	Streamable HTTP（远程）
运行方式	Host 把 Server 作为子进程启动	Server 是独立运行的服务，暴露一个 HTTP 端点
通信方式	从 stdin 读、向 stdout 写，每行一条 JSON-RPC 消息	每条消息是一次 HTTP POST，响应为 JSON 或该请求专属的 SSE 流
服务对象	一台机器上的一个 Host	任意数量的客户端
认证	规范建议从环境变量等本地环境获取凭据	规范定义了基于 OAuth 2.1 的授权流程
分发与升级	用户安装 npm / PyPI 包或二进制，各自升级	服务端升级一次，所有用户生效
能访问什么	用户本机的文件、命令、本地网络	服务器所在网络能访问的系统
主要风险	以用户权限执行任意代码；恶意安装命令	公网暴露面、令牌泄露、DNS 重绑定（本地 HTTP）
典型例子	读写本地代码仓库、操作本机浏览器、连本地数据库	公司的订单查询服务、SaaS 厂商提供的官方 Server

stdio：最简单的本地形态

Host 与本地 Server 的关系如下：

图 1 · stdio：一个 Host、一个子进程，stdout 只能写 MCP 消息

规范对 stdio 有几条硬性规则，实现时最容易踩坑的是第一条：

Server 的 stdout 只能写合法的 MCP 消息。 调试时随手一个 console.log 或 print，就会把协议流弄乱，Host 直接断开连接。日志要写到 stderr。
消息以换行分隔，消息内部不能包含换行。
关闭时，Host 先关闭子进程的输入流，等它退出；超时再强制终止。Server 应在 stdin 关闭时及时退出。
Server 意外退出时，Host 应当重启它。

stdio 的优点是零网络暴露：只有启动它的 Host 能和它通信。缺点是每个用户都要在本机安装和配置，版本难以统一，而且 Server 以用户的权限运行，能访问用户能访问的一切。

Streamable HTTP：可共享的远程形态

多个客户端共享同一个远程端点：

图 2 · Streamable HTTP：一个端点服务任意数量的客户端，任意请求可落到任意实例

2026-07-28 版规范下的要点：

单一端点：Server 提供一个支持 POST 的 MCP 端点，客户端发送的每条 JSON-RPC 消息都是一次新的 POST。
两种响应形态：Server 可以直接返回一个 JSON 对象，也可以为这个请求开一个 SSE 流，先推送进度等通知，最后给出结果。客户端两种都必须支持。
请求头镜像：每个请求都要带 MCP-Protocol-Version、Mcp-Method；调用工具、读取资源、获取提示模板时还要带 Mcp-Name。这样网关、限流器、WAF 不用解析请求体就能按方法和工具名做路由与计量。Server 必须校验请求头与请求体一致。
无会话：这一版去掉了协议级会话（早期版本的 Mcp-Session-Id）和独立的 GET 通知流，任意请求可以落到任意实例。需要接收变化通知时，客户端发 subscriptions/listen 请求打开一个长连接流。
取消：客户端关闭某个请求的响应流，即视为取消该请求。

安全方面，规范要求 Server 校验所有请求的 Origin 头以防 DNS 重绑定攻击；在本机运行时应只绑定 127.0.0.1 而不是所有网卡；并且应当对所有连接实施认证。DNS 重绑定是本地 HTTP Server 特有的风险：恶意网页可以让浏览器把请求发到你本机的 MCP 端口上。

新旧版本的兼容

现实中新旧版本会长期共存。截至 2026 年 9 月，常见组合是：

你遇到的	说明	建议
2026-07-28 版 Streamable HTTP	无会话、请求头镜像、MRTR	新建远程 Server 的首选
2025-03-26 至 2025-11-25 版 Streamable HTTP	有会话 ID、可用 GET 打开通知流、流可恢复	大量存量 Server 与 Host 仍在使用
HTTP+SSE（2024-11-05 版）	自 2025-03-26 版起弃用	不要新建；存量应迁移

官方 TypeScript 与 Python SDK 的当前主版本（v2）都同时支持 2026-07-28 版和更早的规范版本，其中 TypeScript SDK 的文档写明默认用同一套 Server 代码服务新旧两代客户端，这能大幅降低迁移成本。Host 一侧也在逐步支持新版本，比如 Claude Code 的文档中已将 SSE 传输标注为弃用、推荐使用 HTTP。

在 Host 中怎么配置

以 Claude Code 为例（命令以官方文档为准）：

# 本地 stdio Server：-- 之后是启动命令，原样传给 Server
claude mcp add orders -- npx tsx /path/to/orders-server/src/index.ts

# 需要环境变量（如内部 API 的只读密钥）
claude mcp add --env ORDER_API_TOKEN=xxx orders -- npx tsx /path/to/src/index.ts

# 远程 Streamable HTTP Server
claude mcp add --transport http orders https://mcp.example.com/mcp

# 团队共享：写入项目根目录的 .mcp.json，随仓库提交
claude mcp add --transport http orders --scope project https://mcp.example.com/mcp

项目级配置生成的 .mcp.json 形如：

{
  "mcpServers": {
    "orders": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Claude Code 对项目级配置里的 Server 会在交互会话中先请用户确认信任，这是防止“克隆一个仓库就自动运行陌生 Server”的保护。其他 Host（VS Code、Cursor 等）的配置文件位置和格式略有差异，但核心信息相同：本地给“命令 + 参数”，远程给“URL”。

部署形态怎么选

可以按下面三个问题依次判断：

图 3 · 三个问题决定部署形态：数据在哪、谁来用、要不要集中管控

三个贯穿场景的典型选择：

Coding Agent 读写本地仓库：stdio。数据就在本机，不需要网络暴露。
内部订单查询给全公司使用：Streamable HTTP 部署在内网，接入公司统一登录，按用户权限过滤数据，所有调用集中审计。
SEO 工具厂商开放给客户：Streamable HTTP 公网部署，配合 OAuth 让客户授权自己的站点数据，也便于接入各家 AI 产品的连接器目录。

常见误区

“本地 Server 没有安全问题。” stdio Server 以用户权限运行，能读 SSH 密钥、执行任意命令。安装一个来源不明的本地 Server，风险和运行一个陌生脚本一样。
“远程 Server 绑定 0.0.0.0 方便调试。” 本地调试也应只绑定 127.0.0.1，并校验 Origin。
“SSE 和 Streamable HTTP 是一回事。” Streamable HTTP 在响应中可以使用 SSE 流，但它和已弃用的 HTTP+SSE 传输不是一回事。新项目不要再选后者。

产品经理检查清单

Server 需要访问的数据在哪里：用户本机，还是公司系统？
目标用户是谁？他们能自己安装和配置本地 Server 吗？
版本升级怎么推送？旧版本客户端要支持多久？
远程部署时，认证、限流、审计、监控由谁负责？
目标 Host 支持哪种传输方式与哪个规范版本？

练习

为三个 Server 选择部署形态并写出理由（30 分钟）：

让 Coding Agent 读取本地日志文件、定位报错的 Server。
让全公司客服 Agent 查询订单与支付状态的 Server。
让销售团队在 Claude 或 ChatGPT 里查询 CRM 数据的 Server。

每个 Server 写出：传输方式、凭据从哪里来、谁负责升级、最大的安全风险是什么。

下一步

远程 Server 一旦对外开放，最关键的问题就变成“谁能用、能用到什么程度”。下一课「MCP 的认证与安全」讲 OAuth 授权和常见攻击。

本地与远程 MCP