Подключите MCP-клиент, поддерживающий только локальные (stdio) серверы, к удалённому MCP-серверу с поддержкой аутентификации:

Почему это необходимо?

На данный момент большинство MCP-серверов в дикой природе устанавливаются локально, используя stdio transport. Это имеет некоторые преимущества: и клиент, и сервер могут неявно доверять друг другу, так как пользователь предоставил им обоим разрешение на запуск. Добавление секретов, таких как API-ключи, можно выполнять с помощью переменных среды и никогда не покидать ваш компьютер. А разработка на npx и uvx позволила пользователям избежать явных этапов установки.

Но есть причина, почему большинство программ, которые могли можно было бы перенести в веб, действительно перемещаются в веб: гораздо проще находить и исправлять баги и дорабатывать новые функции, когда можно отправлять обновления всем пользователям одним развертыванием.

С последней спецификацией авторизации MCP у нас теперь есть безопасный способ делиться нашими MCP-серверами с миром _без_запуска кода на ноутбуках пользователей. Или, по крайней мере, вы бы это сделали, если бы все популярные MCP client уже поддерживали это. Большинство из них работают только со stdio, а те, что _поддерживают HTTP+SSE, пока не поддерживают требуемые потоки OAuth.

Вот тут и появляется mcp-remote.

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