Supergateway

Name: Supergateway
Author: supercorp-ai

本地服务

github.com/supercorp-ai开发工具2.9k2 天前更新

代码仓库

关于 Supergateway

Supergateway 可用一条命令把仅支持 stdio 的 MCP 服务通过 SSE、WebSocket 或 Streamable HTTP 对外提供，也可反向将远程 SSE 或 Streamable HTTP 服务转为本地 stdio。适用于远程访问、调试以及需要特定传输协议的客户端。项目支持 API Key 鉴权、健康检查和多服务配置文件。

主要功能

01stdio 服务转换为 SSE、WS 或 Streamable HTTP
02远程 SSE 或 Streamable HTTP 服务转为 stdio
03支持 API Key、Bearer Token 与自定义请求头
04提供健康检查端点与会话超时设置
05支持通过配置文件同时托管多个服务
06可限制对外暴露的工具列表并添加前缀

适用场景

01让仅支持 stdio 的 MCP 服务可被远程客户端访问
02在本地命令行环境中接入远程 MCP 服务
03调试 MCP 服务的传输与协议行为

MCP 相关

Supergateway 是 MCP 传输层的网关：它把 stdio 服务暴露为 SSE、WS 或 Streamable HTTP 端点，也能把远程 MCP 服务接入本地 stdio 客户端。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

{
  "mcpServers": {
    "supergateway": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway"
      ]
    }
  }
}

启动命令npx -y supergateway

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

npmsupergatewaystdio

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具，维护者暂未提供工具列表。

详细介绍

Supergateway：通过 SSE 和 WS 运行 stdio MCP 服务

Supergateway 只需一条命令，即可通过 SSE（服务器发送事件） 或 WebSockets（WS） 运行 基于 MCP stdio 的服务。当你的 MCP 服务只支持 stdio 时，这对于远程访问、调试或连接客户端很有帮助。

有问题、想法，或只是想聊聊？加入 Discord 社区。

支持方：

Supercov — 为编码 Agent 和软件工厂提供覆盖率 🌙
Superinterface
Supercorp

安装与使用

通过 npx 运行 Supergateway：

npx -y supergateway --stdio "uvx mcp-server-git"

--stdio "command"：通过 stdio 运行 MCP 服务的命令
--sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"：要连接的 SSE URL（SSE→stdio 模式）
--streamableHttp "https://mcp-server.example.com/mcp"：要连接的 Streamable HTTP URL（StreamableHttp→stdio 模式）
--outputTransport stdio | sse | ws | streamableHttp：输出 MCP 传输方式（默认值：--stdio 时为 sse，--sse 或 --streamableHttp 时为 stdio）。通过 --sse 或 --streamableHttp 指定的远程服务也可以通过 sse、ws 或 streamableHttp 提供服务；参见远程服务 → SSE、WS 或 Streamable HTTP
--port 8000：监听端口（stdio→SSE、stdio→WS 或 stdio→Streamable HTTP 模式，默认值：8000）
--host 127.0.0.1：监听地址，例如 127.0.0.1 或 ::1（[::1] 也可用）（stdio→SSE、stdio→WS 或 stdio→Streamable HTTP 模式，默认值：所有接口）。--baseUrl 不控制绑定：只有 --host 才能限制接受连接的地址。在 SSE→stdio 和 Streamable HTTP→stdio 模式下不允许使用，这两种模式不会监听任何地址
--baseUrl "http://localhost:8000"：SSE 客户端使用的基本 URL（stdio→SSE 模式；可选）
--ssePath "/sse"：SSE 订阅路径（stdio→SSE 模式，默认值：/sse）
--messagePath "/message"：消息路径（stdio→SSE 或 stdio→WS 模式，默认值：/message）
--streamableHttpPath "/mcp"：Streamable HTTP 路径（stdio→Streamable HTTP 模式，默认值：/mcp）
--stateful：以有状态模式运行 stdio→Streamable HTTP
--sessionTimeout 60000：会话超时时间，单位为毫秒（仅适用于有状态的 stdio→Streamable HTTP 模式）
--protocolVersion "2025-06-18"：网关自行初始化服务，且客户端请求未指定协议版本时使用的协议版本（无状态 stdio→Streamable HTTP 模式，默认值：2024-11-05）
--header "x-user-id: 123"：添加一个或多个标头（stdio→SSE、stdio→Streamable HTTP、SSE→stdio 或 Streamable HTTP→stdio 模式；可多次使用）。使用本地服务时，标头会添加到网关的响应中；使用远程服务（--sse、--streamableHttp）时，标头会发送给远程服务
--oauth2Bearer "some-access-token"：使用提供的 Bearer 令牌添加 Authorization 标头
--logLevel debug | info | none：控制日志级别（默认值：info）。使用 debug 可输出更详细的日志，使用 none 可禁止所有日志。
--logFormat text | json：日志行格式（默认值：text）。json 会逐行写入一个 JSON 对象，其中包含 time、level、msg，如果日志调用带有值，还会包含 data，适用于 ELK 及类似的日志管道。日志会输出到与 text 相同的流，因此 stdio 输出仍只包含 MCP 消息。
--cors：启用 CORS（stdio→SSE 或 stdio→WS 模式）。不带值使用 --cors 时允许所有来源，也可以提供一个或多个允许的来源（例如，使用 --cors "http://example.com"，或使用 --cors "/example\\.com$/" 进行正则匹配）。
--healthEndpoint /healthz：注册一个或多个端点（除 stdio 输出外的所有模式；可多次使用），这些端点会返回 "ok"
--healthCheck gateway | server：健康检查端点检查的对象（默认值：gateway）。gateway 在网关运行时返回 "ok"。server 还会检查 MCP 服务：启动一个服务（对于 --sse/--streamableHttp，则与远程服务建立会话），对其进行初始化并发送 ping，然后停止它。如果服务在 10 秒内响应，则返回 "ok"；否则返回 503 和原因（例如，unhealthy: the server exited (code=1, signal=null)）。结果会复用 10 秒，因此每秒轮询时，每 10 秒最多启动一个服务。启动日志会说明健康状态何时变差以及何时恢复
--toolPrefix "github_"：在服务列出的每个工具名称前添加此前缀，因此 search 会变为 github_search（所有模式）。客户端使用此名称调用工具，服务仍会收到原本的名称。前缀会按提供的内容直接使用，因此请自行添加分隔符。工具名称可包含字母、数字、_、- 和 .，长度最多为 128 个字符；如果前缀或名称超出此范围，网关会发出警告
--tools search --tools get_issue：仅公开这些工具，名称使用服务自身的名称（所有模式）。其他工具会从 tools/list 中省略，调用时会被拒绝并返回 -32602 Unknown tool，就像服务拒绝不存在的工具一样；请求不会到达服务。单独使用 --tools 时不会公开任何工具
--apiKey "some-key"：要求客户端提供此密钥，可使用 Authorization: Bearer <key> 或 X-API-Key: <key>（stdio→SSE、stdio→WS 或 stdio→Streamable HTTP 模式；可多次使用）。也可设置 SUPERGATEWAY_API_KEY=some-key。参见要求使用 API 密钥
--apiKeyFile /run/secrets/keys：接受此文件中的密钥，每行一个（跳过空行）。也可设置 SUPERGATEWAY_API_KEY_FILE=/run/secrets/keys
--exitWithProcess <pid>：当进程 <pid> 退出时关闭网关并停止 MCP 服务（所有模式）。传入启动器的 PID（例如 $$）；它不必是直接父进程，因此通过 npx 启动时也能正常工作。大约每秒检查一次。如果启动器通过 stdin 管道启动 Supergateway，则无需使用此选项：从 4.0 版起，Supergateway 会在 stdin 关闭时退出。
--config servers.json：从配置文件读取服务和设置，而非使用服务标志。参见从配置文件加载多个服务
--checkConfig：与 --config 配合使用时，检查文件，列出每个服务的路径和输出，然后退出
--printConfig：打印解析后的配置，然后退出。密钥、Bearer 令牌、所有 env 值、每个 URL 的查询参数以及名称敏感的标头都会被替换；命令行（args、stdio）会按原样打印，因此分享前请先检查。未使用 --config 时，会打印与给定命令行等效的文件内容

stdio → SSE

将 MCP stdio 服务端作为 SSE 服务端公开：

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --port 8000 --baseUrl http://localhost:8000 \
    --ssePath /sse --messagePath /message

订阅事件：GET http://localhost:8000/sse
发送消息：POST http://localhost:8000/message
每个 SSE 连接都会获得独立的服务端进程。

SSE → stdio

连接到远程 SSE 服务端，并通过 stdio 在本地公开：

npx -y supergateway --sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"

适用于将远程 SSE MCP 服务端集成到本地命令行环境中。

发送请求时也可以传递标头，适用于身份验证：

npx -y supergateway \
    --sse "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app" \
    --oauth2Bearer "some-access-token" \
    --header "X-My-Header: another-header-value"

Streamable HTTP → stdio

连接到远程 Streamable HTTP 服务端，并通过 stdio 在本地公开：

npx -y supergateway --streamableHttp "https://mcp-server.example.com/mcp"

此模式适用于连接使用较新 Streamable HTTP 传输协议的 MCP 服务端。与 SSE 模式一样，也可以传递标头进行身份验证：

npx -y supergateway \
    --streamableHttp "https://mcp-server.example.com/mcp" \
    --oauth2Bearer "some-access-token" \
    --header "X-My-Header: another-header-value"

stdio → Streamable HTTP

将 MCP stdio 服务端作为 Streamable HTTP 服务端公开。

当客户端和 stdio 服务端支持共同的协议版本时，支持旧版 MCP 和 2026-07-28。支持自动协商的客户端可以在服务端要求时回退到旧版协议。

--stateful 会保留旧版会话。MCP 2026-07-28 使用独立请求，不会创建传输会话。

交互式 MCP 2026-07-28 操作可以跨请求继续。在最多五分钟的不活动时间内，可以继续操作并显式重试，最多保存 64 个继续状态。达到此上限时，较早的状态可能会更早过期。

无状态模式

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp \
    --port 8000

有状态模式

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp --stateful \
    --sessionTimeout 60000 --port 8000

Streamable HTTP 端点默认为 http://localhost:8000/mcp（可通过 --streamableHttpPath 配置）。

stdio → WS

将 MCP stdio 服务端作为 WebSocket 服务端公开：

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --port 8000 --outputTransport ws --messagePath /message

WebSocket 端点：ws://localhost:8000/message
每个 WebSocket 连接都会获得独立的服务端进程。

远程服务端 → SSE、WS 或 Streamable HTTP

为需要使用其他传输方式的客户端提供远程 MCP 服务端，或在其前面加上自己的 API 密钥：

npx -y supergateway \
    --streamableHttp "https://mcp.example.com/mcp" \
    --oauth2Bearer "$UPSTREAM_TOKEN" \
    --outputTransport streamableHttp --stateful --apiKey "$MCP_API_KEY"

每个客户端会话都会与远程服务端建立独立会话；会话会在客户端会话结束时以及服务关闭时终止。
--header 和 --oauth2Bearer 会发送到远程服务端。客户端自身的 Authorization 和 API 密钥不会发送过去。
远程服务端向客户端发出的请求（sampling、roots、elicitation）会透传。
远程服务端宕机、拒绝客户端连接或中途断开，只会导致该会话失败。
2026-07-28 协议的无状态请求会转发到支持该版本的远程 Streamable HTTP 服务端。网关每分钟向其查询一次（server/discover）。不支持该版本的服务端，以及任何远程 SSE 服务端，仍按原有方式提供服务：客户端会收到版本不受支持的通知，并回退到较早版本进行协商。

要求使用 API 密钥

默认情况下，任何能够访问该端口的人都可以使用此服务。使用 --apiKey 后，发送到 stdio→SSE、stdio→WS 或 stdio→Streamable HTTP 的每个请求都必须携带密钥：

npx -y supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem ./my-folder" \
    --outputTransport streamableHttp --apiKey "$MCP_API_KEY"

curl -H "Authorization: Bearer $MCP_API_KEY" ...   # or: -H "X-API-Key: $MCP_API_KEY"

未提供有效密钥的请求会收到 401 Unauthorized。--healthEndpoint 路径以及启用 --cors 时的浏览器预检请求不受限制。
--apiKey、--apiKeyFile、SUPERGATEWAY_API_KEY 和 SUPERGATEWAY_API_KEY_FILE 中的密钥都会同时接受，因此可以先添加新密钥，再移除旧密钥来完成轮换。
如果密钥为空、密钥文件不可读或文件中没有密钥，网关会在启动时停止，而不是在未启用身份验证的情况下运行。
密钥绝不会被记录到日志中。请使用 HTTPS（例如通过反向代理），避免以明文形式发送密钥。
若要从 SSE→stdio 或 Streamable HTTP→stdio 向远程服务端发送密钥，请使用 --header 或 --oauth2Bearer；此处不允许使用 --apiKey。

从配置文件启动多个服务

--config 会读取 Claude Desktop 和其他 MCP 客户端使用的 mcpServers 文件，因此客户端的文件可以直接使用。每个服务都通过同一个端口上的 /<name> 提供服务：

{
  "port": 8000,
  "mcpServers": {
    "git": { "command": "uvx", "args": ["mcp-server-git"] },
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./my-folder"],
      "outputTransport": "streamableHttp",
      "apiKey": "${FILES_KEY}",
    },
  },
}

npx -y supergateway --config servers.json

git 通过 SSE 在 http://localhost:8000/git/sse 和 /git/message 上提供服务；files 则通过 Streamable HTTP 在 http://localhost:8000/files/mcp 上提供服务。
服务可以是 command + args（不通过 shell 运行，与客户端运行方式相同）、stdio（shell 命令行，与 --stdio 相同），或 url + type（sse 或 http）。env 和 cwd 用于设置其环境和目录。
上方列表中的任何选项都可以按其标志名称（outputTransport、stateful、cors、headers、apiKey、healthEndpoint、toolPrefix、tools 等）设置在某个服务上。在顶层设置时，该值会作为每个服务的默认值。默认值与命令行相同：本地服务通过 SSE 提供服务，url 服务则通过 stdio 提供服务。
path 可让服务在 /<name> 以外的路径上提供服务。无法作为 URL 一部分的名称必须设置此项。如果某个服务的 URL 会由另一个服务或网关自身的 healthEndpoint 响应，网关将拒绝启动。
port、host、logLevel、logFormat、exitWithProcess 和顶层的 healthEndpoint 属于网关自身。顶层的 healthEndpoint 会响应整个网关；服务上的 healthEndpoint 则位于该服务的路径下。设置 "healthCheck": "server" 后，服务自身的健康检查端点会检查该服务；只要网关仍在运行，网关的健康检查端点就会保持 "ok"，因此单个服务故障不会导致整个网关检查失败。
服务上的 apiKey 只会锁定该服务，并会覆盖顶层的 apiKey。空列表会被拒绝；若要让某个服务无需密钥，请仅在需要密钥的服务上设置 apiKey，不要在顶层设置。通过 --apiKey、--apiKeyFile 或 SUPERGATEWAY_API_KEY 设置的密钥会锁定所有服务。
"disabled": true 会跳过某个服务。仅客户端使用的密钥（autoApprove、timeout、disabledTools 等）会触发警告并被忽略。其他任何未知密钥都会导致错误，并提示最接近的已知密钥。
${VAR}、${VAR:-default} 和 ${env:VAR} 会在每个值中替换为环境变量，但 stdio 命令行除外，因为该命令行由 shell 自行展开。未设置的变量会导致错误。$$ 表示字面字符 $。
--config 旁边的标志可以是网关自身的标志（--port、--host、--logLevel、--logFormat、--exitWithProcess、--healthEndpoint、--apiKey、--apiKeyFile）。这些标志会覆盖文件中的设置，启动日志也会说明这一点。诸如 --stateful 这样的服务标志会被拒绝，因为无法确定它指的是哪个服务。
有多个服务时，每条与服务有关的日志行都会以其名称开头（[git]），JSON 日志也会包含 server 字段。
在 Windows 上，"command": "npx" 的运行方式与其他客户端相同：像 npx.cmd 这样的脚本命令会通过 cmd.exe 运行，且每个参数仍会按原样传给服务。stdio 则通过 shell 运行。
支持注释和尾随逗号（JSONC）。编辑后请运行 --checkConfig。

url 服务的输出传输方式不是 stdio 时，其提供服务的方式与本地服务相同（参见远程服务 → SSE、WS 或 Streamable HTTP）：例如，设置 "outputTransport": "streamableHttp"。

一个 url 服务可以与端口上的其他服务共存，并使用 stdio 输出。这适用于通过配置文件启动 Supergateway 的客户端，例如 Claude Desktop：客户端通过 stdin 和 stdout 与该服务通信，其他客户端则通过 HTTP 访问其余服务。此时，所有日志都会输出到 stderr。该进程归启动它的客户端所有。当 stdin 关闭、收到信号，或 stdio 服务停止时（例如其远程服务拒绝了首次连接），所有服务都会停止，退出代码则由 stdio 服务决定。

在同一个 URL 上组合多个服务

带有自身 mcpServers 的条目会将这些服务作为一个 MCP 服务提供，使用该条目的 URL：

{
  "port": 8000,
  "outputTransport": "streamableHttp",
  "mcpServers": {
    "dev": {
      "mcpServers": {
        "git": { "command": "uvx", "args": ["mcp-server-git"] },
        "files": {
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-filesystem", "."],
        },
        "docs": {
          "url": "https://docs.example.com/mcp",
          "type": "http",
          "toolPrefix": "docs_",
        },
      },
    },
  },
}

客户端访问 http://localhost:8000/dev/mcp 时，可以看到这三个服务的工具、提示词和资源。

名称不会更改。 请求会发送到提供所指定工具、提示词或资源的服务。如果两个服务提供同名项，则列表中排在前面的服务优先，另一个服务中的同名项会被隐藏；日志中会提示一次。为服务设置 toolPrefix 可保留两者，并通过 tools 选择要显示的服务工具。在一个 URL 后提供过多工具会增加模型选择的难度，因此只组合彼此相关的内容。
每个会话都有自己的服务， 在客户端初始化时启动。无法启动的服务会被排除，日志中会记录一行；只有在没有任何服务启动时，会话才会失败。某个服务之后停止时，对该服务的调用会失败，客户端会收到列表已更改的通知，其他服务则继续运行。
服务向客户端发送的请求（采样、根目录、引导）与单个服务的情况相同，适用于支持这些请求的输出（SSE、WebSocket、有状态 Streamable HTTP）。
协议版本是所有服务能够响应的最低版本；能力则包含所有服务所具备的全部能力；每个服务的 instructions 会合并在一起，并分别置于对应服务名称之下。
列表以单页返回， 服务顺序与列表顺序一致。
URL 的设置（outputTransport、apiKey、cors、healthEndpoint 等）应放在条目上。组合服务可使用 command/args/env/cwd、stdio，或 url/type/headers/oauth2Bearer，以及 toolPrefix/tools。组合仅支持一层。
使用 stdio 时（"outputTransport": "stdio"），桌面客户端可启动组合条目，通过其自身配置中的一个条目访问多个服务。它可以与端口上的其他服务同时运行，就像单个远程服务一样。
只有当所有组合服务都支持 2026-07-28 时， 才会响应此版本（网关每分钟询问一次）。此时，每个请求只会启动其目标服务；server/discover 和列表请求会发送给所有服务。如果某个服务不支持此版本，该条目会响应较早的版本，进行版本协商的客户端会回退。
暂不支持： 任务。组合服务共享同一个模型上下文，因此只组合彼此信任对方结果的服务。

无需 Node：独立可执行文件

每个版本也会提供内置 Node 的 Supergateway 单文件可执行程序，因此可在未安装 Node 的环境中运行。它接受相同的标志。

Homebrew（macOS 和 Linux）：

brew install supercorp-ai/tap/supergateway

macOS（Apple Silicon）和 Linux：下载并解压。根据需要，将 darwin-arm64 替换为 linux-x64、linux-arm64、linux-musl-x64 或 linux-musl-arm64。

curl -fsSL https://github.com/supercorp-ai/supergateway/releases/latest/download/supergateway-darwin-arm64.tar.gz | tar -xz

./supergateway --stdio "uvx mcp-server-time" --port 8000

Windows（PowerShell）：

Invoke-WebRequest https://github.com/supercorp-ai/supergateway/releases/latest/download/supergateway-win-x64.zip -OutFile supergateway.zip; Expand-Archive supergateway.zip .

.\supergateway.exe --stdio "uvx mcp-server-time" --port 8000

须知：

你封装的 MCP 服务仍需要自己的运行时：--stdio "npx -y ..." 需要 Node，--stdio "uvx ..." 需要 uv。
Linux 需要 glibc 2.28 或更高版本。在 Alpine 上，请使用 linux-musl 版本，并先运行 apk add libstdc++。
Intel Mac 没有独立构建版本；brew install 会在 Homebrew 的 Node 上安装 npm 包。
这些可执行文件没有经过付费证书签名。通过浏览器下载后，macOS Gatekeeper 和 Windows SmartScreen 会在首次运行前发出询问；使用 curl、PowerShell 和 Homebrew 安装则不受影响。
每个压缩包都列在版本的 SHA256SUMS 中；你可以使用 gh attestation verify supergateway-darwin-arm64.tar.gz -R supercorp-ai/supergateway 检查它是否由此仓库的 CI 构建。

关闭

请预留超过 5 秒以便优雅关闭。通过 Ctrl-C 停止网关时，子服务应处理 SIGTERM。

对于网络输出网关，关闭连接到 stdin 的管道也会停止网关。若以忽略 stdin 或将 stdin 重定向至 /dev/null 的方式启动，网关会继续运行。

使用 MCP Inspector 的示例（stdio → SSE 模式）

运行 Supergateway：

npx -y supergateway --port 8000 \
    --stdio "npx -y @modelcontextprotocol/server-filesystem /Users/MyName/Desktop"

使用 MCP Inspector：

npx @modelcontextprotocol/inspector

现在，你可以通过 Supergateway 列出工具和资源，或执行 MCP 操作。

与 ngrok 搭配使用

使用 ngrok 将本地 MCP 服务公开分享：

npx -y supergateway --port 8000 --stdio "npx -y @modelcontextprotocol/server-filesystem ."

# In another terminal:
ngrok http 8000

ngrok 会提供一个用于远程访问的公共 URL。

MCP 服务将在类似以下的 URL 上提供： https://1234-567-890-12-456.ngrok-free.app/sse

使用 Docker 运行

基于 Docker 的工作流无需在本地配置 Node.js。此处提供可直接运行的 Docker 镜像： supercorp/supergateway。也可在 GHCR 上获取：ghcr.io/supercorp-ai/supergateway

使用官方镜像

docker run -it --rm -p 8000:8000 supercorp/supergateway \
    --stdio "npx -y @modelcontextprotocol/server-filesystem /" \
    --port 8000

Docker 会自动拉取镜像。MCP 服务在容器的根目录（/）中运行。如有需要，你可以挂载主机目录。

包含依赖项的镜像

拉取以下任一预构建的 Supergateway 镜像，以获取你可能需要的各种依赖项。

uvx Supergateway + uv/uvx，可直接调用 uvx：

docker run -it --rm -p 8000:8000 supercorp/supergateway:uvx \
  --stdio "uvx mcp-server-fetch"

deno Supergateway + Deno，可直接运行基于 Deno 的 MCP 服务：

docker run -it --rm -p 8000:8000 supercorp/supergateway:deno \
  --stdio "deno run -A jsr:@omedia/mcp-server-drupal --drupal-url https://your-drupal-server.com"

自行构建镜像

从此检出版本构建：

npm ci
npm run pack:release
docker build -f docker/base.Dockerfile -t supergateway \
  --build-arg VERSION="$(node -p "require('./.release/manifest.json').version")" \
  --build-arg PACKAGE_SHA256="$(node -p "require('./.release/manifest.json').sha256")" .

docker run -it --rm -p 8000:8000 supergateway --stdio "npx -y @modelcontextprotocol/server-filesystem ."

在 Claude Desktop 中使用（SSE → stdio 模式）

Claude Desktop 可以使用 Supergateway 的 SSE→stdio 模式。

基于 NPX 的 MCP 服务示例

{
  "mcpServers": {
    "supermachineExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

基于 Docker 的 MCP 服务示例

{
  "mcpServers": {
    "supermachineExampleDocker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "supercorp/supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

在 Cursor 中使用（SSE → stdio 模式）

Cursor 也可以在 SSE→stdio 模式下与 Supergateway 集成。配置与 Claude Desktop 类似。

Cursor 的基于 NPX 的 MCP 服务示例

{
  "mcpServers": {
    "cursorExampleNpx": {
      "command": "npx",
      "args": [
        "-y",
        "supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

Cursor 的基于 Docker 的 MCP 服务示例

{
  "mcpServers": {
    "cursorExampleDocker": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "supercorp/supergateway",
        "--sse",
        "https://mcp-server-ab71a6b2-cd55-49d0-adba-562bc85956e3.supermachine.app"
      ]
    }
  }
}

注意： 虽然此配置支持通过 --header 标志发送标头，但如果需要传递 Authorization 标头（通常包含空格，例如 "Bearer 123"），则必须使用 --oauth2Bearer 标志，因为 Cursor 存在一个已知错误：命令行参数中含有空格时会出问题。

故障排除

未使用 `--baseUrl` 主机

在 stdio→SSE 模式下，只有 --baseUrl 的路径会传递给客户端：--baseUrl https://mcp.example.com/gateway 会使消息端点变为 /gateway/message，而客户端会向其连接的主机发送请求。需要绝对端点 URL 的客户端（例如 Copilot Studio）应使用 --outputTransport streamableHttp。

为什么选择 MCP？

Model Context Protocol 对 AI 工具交互进行了标准化。Supergateway 可将 MCP stdio 服务转换为 SSE 或 WS 服务，从而简化与基于 Web 或远程客户端的集成和调试。

其他资源

Superargs - 在运行时向 MCP 服务提供参数。

贡献者

贡献

欢迎提交问题和 PR：请参阅 CONTRIBUTING.md。如需帮助，请在 Discord 上提问（SUPPORT.md）；请私下报告安全问题（SECURITY.md）。无障碍访问：ACCESSIBILITY.md。

测试

Supergateway 使用 Node Test Runner 进行测试。

要在本地运行测试套件，需要 Node 24+。使用 nvm 可以通过以下命令安装并启用它：

nvm install 24
nvm use 24
npm install
npm run build
npm test

tests/helpers/mock-mcp-server.js 脚本会提供一个本地 MCP 服务，因此所有测试都可以在不访问网络的情况下运行。

还有两项检查会将此版本与上一个发行版进行比较，需要联网获取该版本。CI 会在每个拉取请求上运行这两项检查：

npm run test:versions   # the same client against the release and this build, side by side
npm run test:released   # the release's own end-to-end tests, run against this build

预期的差异会在 tests/crossVersion.intended.ts 或 tests/releasedTests.intended.json 中注明原因；其他任何差异都会导致检查失败。

许可证

MIT 许可证

支持 Markdown

登录后评论

第一次接触 MCP？

从协议是什么，到在客户端里装上第一个服务，这几条回答覆盖了大多数入门问题。

阅读入门指南

一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。