P
punkpeye/mcp-proxy
HTTP and SSE proxy for MCP servers that speak stdio
在 GitHub 查看 ↗链接已于 2026-11-12 核查 · HTTP 200 · 打开的是厂商自己的官网
安装与配置
- 复制上面的命令
- 粘成
claude_desktop_config.json里mcpServers的一项（本地服务器用 command + args，示例见 客户端接法） - 重启客户端
客户端配置（取自该仓库的安装命令）
{
"mcpServers": {
"punkpeye-mcp-proxy": {
"command": "npx",
"args": ["mcp-proxy"]
}
}
}解析自我们于 2026-11-04 抓取的该仓库 README；我们未执行过。
command/args 来自仓库写明的安装命令；不确定时请以该项目 README 为准。
VS Code（.vscode/mcp.json —— 键名是 servers）
{
"servers": {
"punkpeye-mcp-proxy": {
"command": "npx",
"args": ["mcp-proxy"]
}
}
}VS Code 顶层键是 <code>servers</code>，其余与上面那份相同。
Claude Code（命令行）
claude mcp add --transport stdio punkpeye-mcp-proxy -- npx mcp-proxy
Claude Code 不收 JSON 文件，用这条命令直接加。
配置项的键名以你的客户端为准：客户端与 CLI
- 来源明细
- 收录自 abordage/awesome-mcp 榜单（我们从中收集的条目之一） · 条目类型：MCP 服务
- 收录与活跃
- 收录于 2026-11-05 · 最近见到 2026-11-14 · 共见到 10 次 · 被 10 个来源列出
- 评分构成
- 综合分 1,003 · 10 个来源 · mcp
- 安装
npx mcp-proxy
常见问题（答案都来自我们的记录）
怎么安装？
该仓库给出的安装命令是
npx mcp-proxy。我们的记录里它是仓库自己提供的；不保证在你的客户端上直接可用。它适合谁 / 用来做什么？
我们把它归在这些标签下: MCP 服务。标签来自条目自身，不是我们强加的分类。
谁维护它、还在更新吗？
我们收录于 2026-11-05；最近见到 2026-11-14。这里没有"官方认证"或"质量评级"——我们只记录来源与时间。
# MCP Proxy
以下摘录自该仓库的 README（片段） · 在 GitHub 读完整 README →
A TypeScript streamable HTTP and SSE proxy for MCP servers that use stdio transport.
> [!NOTE]
> CORS is enabled by default with configurable options. See CORS Configuration for details.
> [!NOTE]
> For the inverse — giving a stdio-only client access to a remote MCP server, including the interactive OAuth flow — see mcp-remote.
> [!NOTE]
> MCP Proxy is what FastMCP uses to enable streamable HTTP and SSE.
## Protocol revisions
MCP Proxy serves protocol revision 2026-07-28 and the 2025-era revisions
(2024-10-07 through 2025-11-25) from the same endpoint. Every POST to the
streamable HTTP endpoint is classified by its own content — the 2026-07-28
revision puts a meta envelope on every request, and requests without one are
served by the 2025-era session machinery — so old and new clients share one URL
and neither has to know the other exists.
| | 2025-era clients | 2026-07-28 clients |
| /mcp (streamable) | yes, sessionful | yes, per-request |
| /sse (HTTP+SSE) | yes | n/a — no SSE transport exists |
| stdio (startStdioServer) | yes | not yet — see below |
| Change notifications | unsolicited | subscriptions/listen stream |
Progress notifications and cancellation cross the proxy in both eras: a
forwarded call carries the caller's abort signal, and relayed progress is
re-tagged with the token the caller sent.
Use --no-modern to serve only 2025-era clients; a 2026-07-28 client is then
answered by the 2025-era machinery, which does not recognise its request. The
modern leg lives on the streamable HTTP endpoint, so it is also absent when that
endpoint is disabled (--server sse, or streamEndpoint: null).
The upstream connection — the server MCP Proxy spawns — negotiates its own
revision independently, so any combination works. It uses the 2025 initialize
handshake by default; pass --upstreamProtocol auto to probe with
server/discover first (needed to front a 2026-07-28 server) or
--upstreamProtocol modern to require it.
bash
# front a 2026-07-28 stdio server, serving both eras downstream
npx mcp-proxy --upstreamProtocol auto -- my-modern-mcp-server
### What does not cross the proxy
These are consequences of one design decision — the proxy multiplexes every
downstream connection onto a single upstream connection — and are called out
rather than half-solved.
Anything that asks the client for input (elicitation, sampling, roots).
A 2025-era server pushes its request out of band, carrying nothing that says
which caller it belongs to, so relaying it means guessing whose screen to put
the prompt on. A 2026-07-28 upstream is not ambiguous that way — the request
comes back as the inputrequired result of the call the proxy forwarded —
so that direction is a question of scope, not correlation. Not implemented
yet.
Log messages, on both sides of a 2026-07-28 connection. That revision
carries logs per request: the client asks in a request's meta, the server
answers on that request's stream. The proxy can do neither half — downstream
it has no per-request log callback and its notification handlers are passed
nothing to attribute a log to; upstream it cannot ask for logs at all, so a
2026-07-28 server's per-request logging never fires. 2025-era clients still
> [!NOTE]
> CORS is enabled by default with configurable options. See CORS Configuration for details.
> [!NOTE]
> For the inverse — giving a stdio-only client access to a remote MCP server, including the interactive OAuth flow — see mcp-remote.
> [!NOTE]
> MCP Proxy is what FastMCP uses to enable streamable HTTP and SSE.
## Protocol revisions
MCP Proxy serves protocol revision 2026-07-28 and the 2025-era revisions
(2024-10-07 through 2025-11-25) from the same endpoint. Every POST to the
streamable HTTP endpoint is classified by its own content — the 2026-07-28
revision puts a meta envelope on every request, and requests without one are
served by the 2025-era session machinery — so old and new clients share one URL
and neither has to know the other exists.
| | 2025-era clients | 2026-07-28 clients |
| /mcp (streamable) | yes, sessionful | yes, per-request |
| /sse (HTTP+SSE) | yes | n/a — no SSE transport exists |
| stdio (startStdioServer) | yes | not yet — see below |
| Change notifications | unsolicited | subscriptions/listen stream |
Progress notifications and cancellation cross the proxy in both eras: a
forwarded call carries the caller's abort signal, and relayed progress is
re-tagged with the token the caller sent.
Use --no-modern to serve only 2025-era clients; a 2026-07-28 client is then
answered by the 2025-era machinery, which does not recognise its request. The
modern leg lives on the streamable HTTP endpoint, so it is also absent when that
endpoint is disabled (--server sse, or streamEndpoint: null).
The upstream connection — the server MCP Proxy spawns — negotiates its own
revision independently, so any combination works. It uses the 2025 initialize
handshake by default; pass --upstreamProtocol auto to probe with
server/discover first (needed to front a 2026-07-28 server) or
--upstreamProtocol modern to require it.
bash
# front a 2026-07-28 stdio server, serving both eras downstream
npx mcp-proxy --upstreamProtocol auto -- my-modern-mcp-server
### What does not cross the proxy
These are consequences of one design decision — the proxy multiplexes every
downstream connection onto a single upstream connection — and are called out
rather than half-solved.
Anything that asks the client for input (elicitation, sampling, roots).
A 2025-era server pushes its request out of band, carrying nothing that says
which caller it belongs to, so relaying it means guessing whose screen to put
the prompt on. A 2026-07-28 upstream is not ambiguous that way — the request
comes back as the inputrequired result of the call the proxy forwarded —
so that direction is a question of scope, not correlation. Not implemented
yet.
Log messages, on both sides of a 2026-07-28 connection. That revision
carries logs per request: the client asks in a request's meta, the server
answers on that request's stream. The proxy can do neither half — downstream
it has no per-request log callback and its notification handlers are passed
nothing to attribute a log to; upstream it cannot ask for logs at all, so a
2026-07-28 server's per-request logging never fires. 2025-era clients still
收录徽章（可选）
想把收录标记放进 README 就复制这行，可选，不影响收录。
[](https://anclum.com/zh/s/punkpeye-mcp-proxy/)
- 来源
- awesome · https://github.com/punkpeye/mcp-proxy
- 按领域浏览
- MCP 服务
- 收录来源
- 10 个独立来源
- 收录于
- 今天
同类推荐
所属领域与标签
每个标签都能点进去看同类的全部条目。数字是当前库里的真实条数。