Repository files navigation

Connect 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 consideredexperimental.

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 onnpx anduvx has allowed users to avoid explicit install steps, too.

But there's a reason most software thatcould be moved to the webdid 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 MCPAuthorization specification, we now have a secure way of sharing our MCP servers with the worldwithout running code on user's laptops. Or at least, you would, if all the popular MCPclients supported it yet. Most are stdio-only, and those thatdo support HTTP+SSE don't yet support the OAuth flows required.

That's wheremcp-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-example": {"command":"npx","args": ["mcp-remote","https://remote.mcp.server/sse","--header","Authorization: Bearer ${AUTH_TOKEN}"      ],"env": {"AUTH_TOKEN":"..."      }    },  }}

Note: Cursor and Claude Desktop (Windows) have a bug where spaces insideargs aren't escaped when it invokesnpx, 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 <auth-token>"// spaces OK in env vars  }},

To run multiple instances of the same remote server with different configurations (e.g., different Atlassian tenants), use the--resource flag to isolate OAuth sessions:

{"mcpServers": {"atlassian_tenant1": {"command":"npx","args": ["mcp-remote","https://mcp.atlassian.com/v1/sse","--resource","https://tenant1.atlassian.net/"      ]    },"atlassian_tenant2": {"command":"npx","args": ["mcp-remote","https://mcp.atlassian.com/v1/sse","--resource","https://tenant2.atlassian.net/"      ]    }  }}

Each unique combination of server URL, resource, and custom headers will maintain separate OAuth sessions and token storage.

• Ifnpx is producing errors, consider adding-y as the first argument to auto-accept the installation of themcp-remote package.

"command":"npx","args": ["-y","mcp-remote","https://remote.mcp.server/sse"      ]

• To forcenpx to always check for an updated version ofmcp-remote, add the@latest flag:

"args": ["mcp-remote@latest","https://remote.mcp.server/sse"      ]

• To change which portmcp-remote listens for an OAuth redirect (by default3334), add an additional argument after the server URL. Note that whatever port you specify, if it is unavailable an open port will be chosen at random.

"args": ["mcp-remote","https://remote.mcp.server/sse","9696"      ]

• To change which hostmcp-remote registers as the OAuth callback URL (by defaultlocalhost), add the--host flag.

"args": ["mcp-remote","https://remote.mcp.server/sse","--host","127.0.0.1"      ]

• To allow HTTP connections in trusted private networks, add the--allow-http flag. Note: This should only be used in secure private networks where traffic cannot be intercepted.

"args": ["mcp-remote","http://internal-service.vpc/sse","--allow-http"      ]

• To enable detailed debugging logs, add the--debug flag. This will write verbose logs to~/.mcp-auth/{server_hash}_debug.log with timestamps and detailed information about the auth process, connections, and token refreshing.

"args": ["mcp-remote","https://remote.mcp.server/sse","--debug"      ]

• To suppress default logs, add the--silent flag. This will prevent logs from being emitted, except in the case where--debug is also passed.

"args": ["mcp-remote","https://remote.mcp.server/sse","--silent"      ]

• To enable an outbound HTTP(S) proxy for mcp-remote, add the--enable-proxy flag. When enabled, mcp-remote will use the proxy settings from common environment variables (for exampleHTTP_PROXY,HTTPS_PROXY, andNO_PROXY).

"args": ["mcp-remote","https://remote.mcp.server/sse","--enable-proxy"    ],"env": {"HTTPS_PROXY":"http://127.0.0.1:3128","NO_PROXY":"localhost,127.0.0.1"    }

• To ignore specific tools from the remote server, add the--ignore-tool flag. This will filter out tools matching the specified patterns from bothtools/list responses and blocktools/call requests. Supports wildcard patterns with*.

"args": ["mcp-remote","https://remote.mcp.server/sse","--ignore-tool","delete*","--ignore-tool","remove*"      ]

You can specify multiple--ignore-tool flags to ignore different patterns. Examples:

• delete* - ignores all tools starting with "delete" (e.g.,deleteTask,deleteUser)
• *account - ignores all tools ending with "account" (e.g.,getAccount,updateAccount)
• exactTool - ignores only the tool named exactly "exactTool"

• To change the timeout for the OAuth callback (by default30 seconds), add the--auth-timeout flag with a value in seconds. This is useful if the authentication process on the server side takes a long time.

"args": ["mcp-remote","https://remote.mcp.server/sse","--auth-timeout","60"      ]

MCP Remote supports different transport strategies when connecting to an MCP server. This allows you to control whether it uses Server-Sent Events (SSE) or HTTP transport, and in what order it tries them.

Specify the transport strategy with the--transport flag:

npx mcp-remote https://example.remote/server --transport sse-only

Available Strategies:

• http-first (default): Tries HTTP transport first, falls back to SSE if HTTP fails with a 404 error
• sse-first: Tries SSE transport first, falls back to HTTP if SSE fails with a 405 error
• http-only: Only uses HTTP transport, fails if the server doesn't support it
• sse-only: Only uses SSE transport, fails if the server doesn't support it

MCP Remote supports providing static OAuth client metadata instead of using the mcp-remote defaults.This is useful when connecting to OAuth servers that expect specific client/software IDs or scopes.

Provide the client metadata as a JSON string or as a@ prefixed filepath with the--static-oauth-client-metadata flag:

npx mcp-remote https://example.remote/server --static-oauth-client-metadata'{ "scope": "space separated scopes" }'# uses node readfile, so you probably want to use absolute paths if you're not sure what the cwd isnpx mcp-remote https://example.remote/server --static-oauth-client-metadata'@/Users/username/Library/Application Support/Claude/oauth_client_metadata.json'

Per thespec,servers are encouraged but not required to supportOAuth dynamic client registration.

For these servers, MCP Remote supports providing static OAuth client information instead.This is useful when connecting to OAuth servers that require pre-registered clients.

Provide the client metadata as a JSON string or as a@ prefixed filepath with the--static-oauth-client-info flag:

export MCP_REMOTE_CLIENT_ID=xxxexport MCP_REMOTE_CLIENT_SECRET=yyynpx mcp-remote https://example.remote/server --static-oauth-client-info"{\"client_id\":\"$MCP_REMOTE_CLIENT_ID\",\"client_secret\":\"$MCP_REMOTE_CLIENT_SECRET\" }"# uses node readfile, so you probably want to use absolute paths if you're not sure what the cwd isnpx mcp-remote https://example.remote/server --static-oauth-client-info'@/Users/username/Library/Application Support/Claude/oauth_client_info.json'

Official Docs

In order to add an MCP server to Claude Desktop you need to edit the configuration file located at:

• macOS:~/Library/Application Support/Claude/claude_desktop_config.json
• Windows:%APPDATA%\Claude\claude_desktop_config.json

If it does not exist yet,you may need to enable it under Settings > Developer.

Restart Claude Desktop to pick up the changes in the configuration file.Upon restarting, you should see a hammer icon in the bottom right cornerof the input box.

Official Docs. The configuration file is located at~/.cursor/mcp.json.

As of version0.48.0, Cursor supports unauthed SSE servers directly. If your MCP server is using the official MCP OAuth authorization protocol, you still need to add a"command" server and callmcp-remote.

Official Docs. The configuration file is located at~/.codeium/windsurf/mcp_config.json.

For instructions on building & deploying remote MCP servers, including acting as a valid OAuth client, see the following resources:

• https://developers.cloudflare.com/agents/guides/remote-mcp-server/

In particular, see:

• https://github.com/cloudflare/workers-oauth-provider for defining an MCP-comlpiant OAuth server in Cloudflare Workers
• https://github.com/cloudflare/agents/tree/main/examples/mcp for defining anMcpAgent using theagents framework.

For more information about testing these servers, see also:

• https://developers.cloudflare.com/agents/guides/test-remote-mcp-server/

Know of more resources you'd like to share? Please add them to this Readme and send a PR!

mcp-remote stores all the credential information inside~/.mcp-auth (or wherever yourMCP_REMOTE_CONFIG_DIR points to). If you're having persistent issues, try running:

rm -rf~/.mcp-auth

Then restarting your MCP client.

Make sure that the version of Node you have installed is18 orhigher. ClaudeDesktop will use your system version of Node, even if you have a newerversion installed elsewhere.

When modifyingclaude_desktop_config.json it can helpful to completely restart Claude

You may run into issues if you are behind a VPN, you can try setting theNODE_EXTRA_CA_CERTSenvironment variable to point to the CA certificate file. If usingclaude_desktop_config.json,this might look like:

{"mcpServers": {"remote-example": {"command":"npx","args": ["mcp-remote","https://remote.mcp.server/sse"      ],"env": {"NODE_EXTRA_CA_CERTS":"{your CA certificate file path}.pem"      }    }  }}

• Follow Claude Desktop logs in real-time
• MacOS / Linux:
  tail -n 20 -F ~/Library/Logs/Claude/mcp*.log
• For bash on WSL:
  tail -n 20 -f "C:\Users\YourUsername\AppData\Local\Claude\Logs\mcp.log"
• Powershell:
  Get-Content "C:\Users\YourUsername\AppData\Local\Claude\Logs\mcp.log" -Wait -Tail 20

For troubleshooting complex issues, especially with token refreshing or authentication problems, use the--debug flag:

"args": ["mcp-remote","https://remote.mcp.server/sse","--debug"]

This creates detailed logs in~/.mcp-auth/{server_hash}_debug.log with timestamps and complete information about every step of the connection and authentication process. When you find issues with token refreshing, laptop sleep/resume issues, or auth problems, provide these logs when seeking support.

If you encounter the following error, returned by the/callback URL:

Authentication ErrorToken exchange failed: HTTP 400

You can runrm -rf ~/.mcp-auth to clear any locally stored state and tokens.

Run the following on the command line (not from an MCP server):

npx -p mcp-remote@latest mcp-remote-client https://remote.mcp.server/sse

This will run through the entire authorization flow and attempt to list the tools & resources at the remote URL. Try this after runningrm -rf ~/.mcp-auth to see if stale credentials are your problem, otherwise hopefully the issue will be more obvious in these logs than those in your MCP client.