
将只支持本地(stdio)服务器的MCP客户端连接到远程MCP服务器。
概览
将只支持本地(stdio)服务器的MCP客户端连接到支持认证的远程MCP服务器: 到目前为止,大多数 MCP 服务器都是本地安装的,使用 stdio 传输。这有一些好处:客户端和服务器都可以隐含地信任对方,因为用户都已授权运行。添加像 API 密钥这样的秘密可以通过环境变量完成,且无需离开你的机器。而且在 npx 和 uvx 上构建也允许用户避免显式安装步骤。 但大多数本可以迁移到网页的软件最终迁移到网页是有原因的:当你可以通过一次部署向所有用户推送更新时,发现和修复漏洞、迭代新功能就容易得多。 有了最新的MCP授权规范,我们现在有了一种安全的方式,可以与全世界共享MCP服务器,而无需在用户笔记本上运行代码。或者至少,如果所有流行的MCP客户端都支持它,你会这么做。
概述(AI 翻译)
将只支持本地(stdio)服务器的MCP客户端连接到支持认证的远程MCP服务器:
为什么有必要这样做?
到目前为止,大多数 MCP 服务器都是本地安装的,使用 stdio 传输。这有一些好处:客户端和服务器都可以隐含地信任对方,因为用户都已授权运行。添加像 API 密钥这样的秘密可以通过环境变量完成,且永远不会离开你的机器。基于 npx 和 uvx 的构建也允许用户避免显式安装步骤。
但大多数本可以迁移到网页上的软件最终都迁移到网页上是有原因的:当你可以通过一次部署向所有用户推送更新时,发现、修复漏洞、迭代新功能就容易得多。
有了最新的MCP授权规范,我们现在有了一种安全的方式,可以将MCP服务器与全世界共享,而无需在用户笔记本上运行代码。或者至少,如果所有流行的MCP客户端都支持它,你会支持。大多数客户端仅支持stdio,而那些支持HTTP+SSE的服务器还不支持所需的OAuth流程。
这正是mcp-remote发挥作用的地方。
本页由 AI 翻译,技术细节请以原文为准。
README
以下为原文 README 节选,完整内容请查看原文。
mcp-remote
Connect an MCP Client that only supports local (stdio) servers to a Remote MCP Server, with auth support:
Why is this necessary?
So far, the majority of MCP servers in the wild are installed locally, using the stdio transport. This has some benefits: both the client and the server can implicitly trust each other as the user has granted them both permission to run. Adding secrets like API keys can be done using environment variables and never leave your machine. And building on npx and uvx has allowed users to avoid explicit install steps, too.
But there’s a reason most software that could be moved to the web did get moved to the web: it’s so much easier to find and fix bugs & iterate on new features when you can push updates to all your users with a single deploy.
With the latest MCP Authorization specification, we now have a secure way of sharing our MCP servers with the world without running code on user’s laptops. Or at least, you would, if all the popular MCP clients supported it yet. Most are stdio-only, and those that do support HTTP+SSE don’t yet support the OAuth flows required.
That’s where mcp-remote comes in. As soon as your chosen MCP client supports remote, authorized servers, you can remove it. Until that time, drop in this one liner and dress for the MCP clients you want!
Usage
All the most popular MCP clients (Claude Desktop, Cursor & Windsurf) use the following config format:
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
]
}
}
}
Custom Headers
To bypass authentication, or to emit custom headers on all requests to your remote server, pass --header CLI arguments:
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization: Bearer ${AUTH_TOKEN}"
],
"env": {
"AUTH_TOKEN": "..."
}
},
}
}
Note: Cursor, Codex-Cli and Claude Desktop (Windows) have a bug where spaces inside args aren’t escaped when it invokes npx, which ends up mangling these values. You can work around it using:
{
// rest of config...
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header",
"Authorization:${AUTH_HEADER}" // note no spaces around ':'
],
"env": {
"AUTH_HEADER": "Bearer " // spaces OK in env vars
}
},
To keep a credential out of the process arguments — where any other user on the machine can read it from the process list — put the headers in a file instead and pass --header-file. One Name: value per line; # starts a comment.
"args": [
"mcp-remote",
"https://remote.mcp.server/sse",
"--header-file",
安装
npx mcp-remote https://remote.mcp.server/sse配置
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
]
}
}
}