`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-concept but should be considered experimental.

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 <auth-token>" // 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",
        "/path/to/headers.txt"
      ]

# credentials for the example server
Authorization: Bearer my-token
X-Custom-Header: custom-value

A file that cannot be read is an error rather than a warning, so a mistyped path fails immediately instead of sending the request unauthenticated.

Multiple Instances

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, custom headers, and --authorize-param values will maintain separate OAuth sessions and token storage.

The --resource value is sent as the RFC 8707 resource indicator on the authorization, token and refresh requests alike, so they always agree.

Extra authorization parameters

Some authorization servers require parameters of their own on the authorize call. Pass each as --authorize-param key=value, repeating the flag as needed:

      "args": [
        "mcp-remote",
        "https://remote.mcp.server/mcp",
        "--authorize-param",
        "access_type=offline",
        "--authorize-param",
        "prompt=consent"
      ]

Those two are what Google wants before it will part with a refresh token — it does not recognise the offline_access scope. Auth0 wants audience=https://your-api to issue a JWT rather than an opaque token. login_hint=user@example.com is also common.

These apply to the authorization request only. resource is the exception: RFC 8707 wants the same value on the token and refresh requests too, and only --resource puts it there. Parameters the flow derives per request — state, code_challenge, client_id, redirect_uri, response_type — are refused, because a value that disagrees with the real one surfaces as an opaque server error.

Changing these starts a new sign-in, since a parameter like audience decides which API the token is for and a token issued for one is not valid for another.

Some authorization servers reject the resource parameter outright — Microsoft Entra ID v2 answers AADSTS9010010, for example. Pass --disable-resource-parameter to omit it entirely:

{
  "mcpServers": {
    "entra-example": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://remote.mcp.server/mcp",
        "--disable-resource-parameter"
      ]
    }
  }
}

Flags

If npx is producing errors, consider adding -y as the first argument to auto-accept the installation of the mcp-remote package.

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

To force npx to always check for an updated version of mcp-remote, add the @latest flag:

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

To change which port mcp-remote listens for an OAuth redirect, add an additional argument after the server URL. By default the port is derived from the server URL, so every server gets a stable port of its own somewhere in 3335-49150, and mcp-remote walks up to 8 ports from there if it finds one taken. A port you pass explicitly is used as-is: it implies a redirect_uri the authorization server has already been given, so mcp-remote fails rather than quietly moving to a different one. --static-oauth-client-info pins the port the same way, for the same reason.

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

To change which host mcp-remote registers as the OAuth callback URL (by default localhost), add the --host flag.

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

To change the path mcp-remote serves the OAuth callback on (by default /oauth/callback), add the --callback-path flag. The path must start with /, and /wait-for-auth is reserved.

      "args": [
        "mcp-remote",
        "https://remote.mcp.server/sse",
        "--callback-path",
        "/custom/callback"
      ]

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 example HTTP_PROXY, HTTPS_PROXY, and NO_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 both tools/list responses and block tools/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 default 30 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"
      ]

To change the network timeouts, add --connect-timeout, --headers-timeout or --body-timeout, each with a value in seconds. These apply to every outbound request, including the OAuth ones.
- --connect-timeout bounds establishing the TCP connection (default 10). Lower it to fail faster on an unreachable server.
- --headers-timeout bounds waiting for response headers (default 300).
- --body-timeout bounds a gap between chunks of a response body (default 300). This is the one that closes an idle SSE stream after five minutes; pass 0 to disable it for servers that push infrequently.

      "args": [
        "mcp-remote",
        "https://remote.mcp.server/sse",
        "--connect-timeout",
        "30",
        "--body-timeout",
        "0"
      ]

To stop an idle connection being dropped, add the --keep-alive flag. The proxy then sends a ping every 30 seconds, which is enough traffic to keep a server — or a load balancer in front of one — from reaping a session that has been quiet for a few minutes. Use --ping-interval with a value in seconds to change the period; setting it turns keep-alive on, so the two flags are only both needed when you want the default period spelled out.

This is the opposite end of the problem from --body-timeout: that one governs how long we wait, whereas this keeps the other side from hanging up.

      "args": [
        "mcp-remote",
        "https://remote.mcp.server/sse",
        "--keep-alive",
        "--ping-interval",
        "60"
      ]

To connect over IPv4 only, add the --ipv4 flag. Useful when a hostname resolves to both IPv4 and IPv6 addresses but the IPv6 routes silently black-hole rather than being refused — connection attempts then time out instead of failing over, and the request never completes.

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

Transport Strategies

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

Static OAuth Client Metadata

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

Static OAuth Client Information

Per the spec, servers are encouraged but not required to support OAuth 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=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'

Claude Desktop

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 corner of the input box.

Cursor

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

As of version 0.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 call mcp-remote.

Windsurf

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

Building Remote MCP Servers

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 an McpAgent using the agents 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!

Troubleshooting

Clear your `~/.mcp-auth` directory

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

rm -rf ~/.mcp-auth

Then restarting your MCP client.

Credentials are stored under mcp-remote-v1, which names the layout of the store rather than the version of the package, so upgrading mcp-remote no longer signs you out. Releases before this change kept a separate directory per version — if you have ~/.mcp-auth/mcp-remote-0.x.y directories left over, they hold old tokens and can be deleted.

Check your Node version

Make sure that the version of Node you have installed is 18 or higher. Claude Desktop will use your system version of Node, even if you have a newer version installed elsewhere.

Restart Claude

When modifying claude_desktop_config.json it can helpful to completely restart Claude

VPN Certs

You may run into issues if you are behind a VPN, you can try setting the NODE_EXTRA_CA_CERTS environment variable to point to the CA certificate file. If using claude_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"
      }
    }
  }
}

Check the logs

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

Debugging

Debug Logs

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.

Authentication Errors

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

Authentication Error
Token exchange failed: HTTP 400

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

"Client" mode

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 running rm -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.

Acknowledgments

Glen Maddern is the original author of mcp-remote. He built mcp-remote into one of the most popular building blocks in the MCP ecosystem.

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
.husky		.husky
src		src
test		test
.gitignore		.gitignore
.oxfmtrc.json		.oxfmtrc.json
.oxlintrc.json		.oxlintrc.json
AGENT.md		AGENT.md
LICENSE		LICENSE
README.md		README.md
knip.json		knip.json
package.json		package.json
pnpm-lock.yaml		pnpm-lock.yaml
tsconfig.json		tsconfig.json
vitest.config.ts		vitest.config.ts

Navigation Menu

Repository files navigation

`mcp-remote`

Why is this necessary?

Usage

Custom Headers

Multiple Instances

Extra authorization parameters

Flags

Transport Strategies

Static OAuth Client Metadata

Static OAuth Client Information

Claude Desktop

Cursor

Windsurf

Building Remote MCP Servers

Troubleshooting

Clear your `~/.mcp-auth` directory

Check your Node version

Restart Claude

VPN Certs

Check the logs

Debugging

Debug Logs

Authentication Errors

"Client" mode

Acknowledgments

About

Releases

Used by

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

mcp-remote

Why is this necessary?

Usage

Custom Headers

Multiple Instances

Extra authorization parameters

Flags

Transport Strategies

Static OAuth Client Metadata

Static OAuth Client Information

Claude Desktop

Cursor

Windsurf

Building Remote MCP Servers

Troubleshooting

Clear your ~/.mcp-auth directory

Check your Node version

Restart Claude

VPN Certs

Check the logs

Debugging

Debug Logs

Authentication Errors

"Client" mode

Acknowledgments

About

Topics

Resources

Stars

Watchers

Forks

Releases

Used by

Contributors

Languages

`mcp-remote`

Clear your `~/.mcp-auth` directory