MCP Remote

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-conceptbut 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 onnpxanduvxhas allowed users to avoid explicit install steps, too.

But there's a reason most software thatcouldbe moved to the webdidget 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 worldwithoutrunning code on user's laptops. Or at least, you would, if all the popular MCPclientssupported it yet. Most are stdio-only, and those thatdosupport HTTP+SSE don't yet support the OAuth flows required.

{ "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--headerCLI 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 insideargsaren'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--resourceflag 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.

- Ifnpxis producing errors, consider adding-yas the first argument to auto-accept the installation of themcp-remotepackage.

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

- To forcenpxto always check for an updated version ofmcp-remote, add the@latestflag:

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

- To change which portmcp-remotelistens 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-remoteregisters as the OAuth callback URL (by defaultlocalhost), add the--hostflag.

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

- To allow HTTP connections in trusted private networks, add the--allow-httpflag. 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--debugflag. This will write verbose logs to~/.mcp-auth/{server_hash}_debug.logwith 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--silentflag. This will prevent logs from being emitted, except in the case where--debugis also passed.

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

- To enable an outbound HTTP(S) proxy for mcp-remote, add the--enable-proxyflag. 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-toolflag. This will filter out tools matching the specified patterns from bothtools/listresponses and blocktools/callrequests. Supports wildcard patterns with.

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

- 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"

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

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

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 is npx mcp-remote https://example.remote/server --static-oauth-client-metadata '@/Users/username/Library/Application Support/Claude/oauth_client_metadata.json'

export MCP_REMOTE_CLIENT_ID=xxx export MCP_REMOTE_CLIENT_SECRET=yyy npx 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 is npx mcp-remote https://example.remote/server --static-oauth-client-info '@/Users/username/Library/Application Support/Claude/oauth_client_info.json'

{ "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

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

This creates detailed logs in~/.mcp-auth/{server_hash}_debug.logwith 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/callbackURL:

Authentication Error Token exchange failed: HTTP 400

You can runrm -rf ~/.mcp-authto 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-authto see if stale credentials are your problem, otherwise hopefully the issue will be more obvious in these logs than those in your MCP client.

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

Tool platform by IBM to build, test and deploy tools for any data source

Decapod Intent Kernel is a paid hosted remote MCP for Decapod. It exposes Streamable HTTP tool calls, bearer-token access, public server-card metadata, usage logs, and receipt-oriented JSON