geelen/mcp-remote
Platform-specific configuration:
{
"mcpServers": {
"mcp-remote": {
"command": "npx",
"args": [
"-y",
"mcp-remote"
]
}
}
}Add the config above to .claude/settings.json under the mcpServers key.
mcp-remoteConnect an MCP Client that only supports local (stdio) servers to a Remote MCP Server, with auth support:
Note: this is a working proof-of-concept but should be considered experimental.
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!
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"
]
}
}
}To bypass authentication, or to emit custom headers on all requests to your remote server, pass --header CLI arguments:
{
"mcpServers": {
"remote-exampleLoading reviews...