# MCP-сервер на Windows: запуск по stdio и особенности

> Как MCP-серверы запускаются на Windows - локальный stdio из настроек клиента, пути и кавычки, WSL, завершение процесса и что известно о запуске HTTP-сервера службой

Страница: https://mcpdoc.ru/deployment/windows/
Указатель сайта: https://mcpdoc.ru/llms.txt

Локальный сервер stdio на Windows запускает клиент по команде из своих настроек, как и на других системах. Отличия Windows - запись путей в JSON, запуск файлов `.cmd` и принудительное завершение процесса без сигналов POSIX.

Для HTTP-сервера эта страница не советует конкретную обёртку для запуска службой: у Microsoft не найдено собственной страницы о том, как сделать службой процесс Node.js или Python.

описана редакция 2026-07-28, сверено со спецификацией и документацией Microsoft и Node.js 4 октября 2026

Совместимость Modern страница описывает редакцию 2026-07-28; отличия старых редакций названы в тексте

- **Страница описывает редакцию:** 2026-07-28

- **Затрагивает устаревшее:** нет

- **Затрагивает удалённое в редакции 2026-07-28:** нет

- **Проверено:** 2026-10-04

- **Источник:** [modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)

## Что протокол говорит про Windows

Спецификация упоминает Windows в одном месте - в правилах завершения сервера на странице [stdio](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio).

Порядок завершения одинаков для всех систем. Клиенту следует:

1. закрыть `stdin` дочернего процесса;
2. подождать, пока сервер выйдет;
3. если сервер не вышел за разумное время, завершить процесс принудительно тем способом, который принят в операционной системе.

Про третий шаг спецификация поясняет: в POSIX это обычно `SIGTERM`, затем `SIGKILL`, а в Windows, где сигналов POSIX нет, клиент может использовать `TerminateProcess` или Job Objects. Это пояснение, а не требование: слова «обязан» или «следует» при нём нет.

Серверу следует выходить сразу, как только `stdin` закрыт или чтение вернуло конец файла. Спецификация называет это основным и единственным переносимым сигналом завершения. Для Windows это особенно важно: мягкого сигнала вроде `SIGTERM` здесь нет, и сервер, который не следит за `stdin`, будет завершён принудительно.

Что стоит за двумя названными механизмами, по документации Microsoft:

- [`TerminateProcess`](https://learn.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminateprocess) безусловно завершает процесс и все его потоки. Процесс не получает возможности закончить работу сам.
- [Job Objects](https://learn.microsoft.com/windows/win32/procthread/job-objects) позволяют управлять группой процессов как одним целым, в том числе завершить все процессы задания сразу. Это способ не оставить после сервера его дочерние процессы.

Остальные правила stdio от системы не зависят: в `stdout` только сообщения MCP, журнал в `stderr`, одно сообщение на строку.

В Legacy порядок завершения описывался через `SIGTERM` и `SIGKILL` без оговорки про Windows. Упоминание `TerminateProcess` и Job Objects появилось в редакции `2026-07-28`.

## Локальный сервер stdio

Клиент хранит команду запуска в своих настройках и сам запускает сервер. Где лежат настройки и как их менять, у каждого клиента своё: смотрите страницы [Клиенты MCP](https://mcpdoc.ru/reference/clients/) и [Claude](https://mcpdoc.ru/clients/claude/).

Ниже - только то, что подтверждено первоисточниками. Источник здесь - [руководство по подключению локальных серверов](https://modelcontextprotocol.io/docs/2026-07-28/develop/connect-local-servers) на сайте MCP. Оно написано на примере Claude Desktop и к другим клиентам относится не обязательно.

### Пути в JSON

В JSON обратная косая черта - служебный знак, поэтому в путях Windows она удваивается.

```json title="Запись сервера с путями Windows"
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\username\\Desktop",
        "C:\\Users\\username\\Downloads"
      ]
    }
  }
}
```

Пример взят из руководства по подключению локальных серверов на сайте MCP (редакция документации 2026-07-28) и здесь не запускался.

По тому же руководству:

- Файл настроек Claude Desktop на Windows лежит по адресу `%APPDATA%\Claude\claude_desktop_config.json`.
- Пути в файле настроек должны быть существующими и абсолютными, а не относительными.
- Команда `npx` в этом примере записана как есть, без полного пути и без обёртки.

### Известные ловушки

Руководство описывает две неполадки именно на Windows.

**Ошибка ENOENT и `${APPDATA}` в пути.** Если сервер не загружается, а в его журнале видна ошибка с `${APPDATA}` внутри пути, руководство советует добавить раскрытое значение `%APPDATA%` в поле `env` записи сервера.

```json title="Переменная APPDATA в записи сервера"
{
  "brave-search": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-brave-search"],
    "env": {
      "APPDATA": "C:\\Users\\user\\AppData\\Roaming\\",
      "BRAVE_API_KEY": "..."
    }
  }
}
```

Пример взят из того же руководства и здесь не запускался.

**`npx` не срабатывает.** Руководство предупреждает: команда может не работать, если npm не установлен глобально. Признак глобальной установки - существующий каталог `%APPDATA%\npm`.

### Где смотреть журнал

По тому же руководству Claude Desktop на Windows пишет журналы в `%APPDATA%\Claude\logs`. Файл `mcp.log` содержит общие сведения о подключениях. Файлы вида `mcp-server-ИМЯ.log` содержат вывод `stderr` названного сервера. Так как серверы stdio могут вести в `stderr` весь свой журнал, записи в этих файлах - не обязательно ошибки.

Перед правкой настроек запустите сервер той же командой в PowerShell: так ошибка видна сразу. Другой способ - [MCP Inspector](https://mcpdoc.ru/tools/inspector/).

## Практика, не правило MCP

### Файлы `.cmd` и кавычки

Это относится к тем, кто пишет собственный клиент или сценарий запуска на Node.js, а не к настройке готового клиента.

По [документации Node.js о дочерних процессах](https://nodejs.org/api/child_process.html) файлы `.bat` и `.cmd` на Windows не исполняются сами по себе без терминала и не запускаются через `child_process.execFile()`. Их запускают через `child_process.exec()`, либо через `cmd.exe` с файлом в параметре, либо через `child_process.spawn()` с включённой оболочкой, что документация не рекомендует. Если в имени файла сценария есть пробелы, его нужно взять в кавычки.

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

### WSL

По [документации Microsoft](https://learn.microsoft.com/en-us/windows/wsl/about) Windows Subsystem for Linux позволяет запускать окружение Linux на машине с Windows без отдельной виртуальной машины и без двойной загрузки. WSL 2 запускает ядро Linux внутри лёгкой служебной виртуальной машины.

Для MCP это даёт два пути.

- **Сервер stdio внутри WSL, клиент в Windows.** По странице [о работе с файловыми системами](https://learn.microsoft.com/en-us/windows/wsl/filesystems) программы Linux запускаются из командной строки Windows командой `wsl` с нужной командой после неё. Такой процесс работает от имени пользователя WSL по умолчанию. В настройках клиента командой тогда становится `wsl`, а команда сервера уходит в параметры. Проверенного образца такой записи в документации клиентов для этой страницы не найдено.
- **Сервер Streamable HTTP внутри WSL как служба systemd.** WSL [поддерживает systemd](https://learn.microsoft.com/en-us/windows/wsl/systemd): он включается строкой `systemd=true` в разделе `[boot]` файла `/etc/wsl.conf`. Дальше применимо всё со страницы [Linux](https://mcpdoc.ru/deployment/ubuntu/).

### HTTP-сервер как служба Windows

По [документации Microsoft](https://learn.microsoft.com/en-us/windows/win32/services/services) служба - это приложение, которое соблюдает правила интерфейса диспетчера управления службами. Её можно запустить автоматически при загрузке системы, и она может работать, когда ни один пользователь не вошёл в систему.

Команда [`sc.exe create`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/sc-create) создаёт запись о службе в реестре и в базе диспетчера. Как выполнить правила диспетчера процессу Node.js или Python, документация Microsoft не описывает.

Собственной страницы Microsoft о том, как запустить службой процесс Node.js или Python, при подготовке этой страницы не найдено. Сторонние обёртки существуют, но рекомендовать одну из них без первоисточника значило бы выдать чужое мнение за проверенный факт.

Для сервера на .NET у Microsoft есть [руководство по созданию службы Windows](https://learn.microsoft.com/en-us/dotnet/core/extensions/windows-service). Для остальных проверенные пути - WSL с systemd или контейнер, смотрите страницу [Docker](https://mcpdoc.ru/deployment/docker/).

Требования протокола к HTTP-серверу на Windows те же, что и везде: сервер обязан проверять `Origin`, при локальном запуске ему следует слушать только `127.0.0.1`.

## Чего здесь нет и что неизвестно

- Способ запуска HTTP-сервера на Node.js или Python службой Windows, описанный самой Microsoft: не найден.
- Пути к настройкам клиентов, кроме Claude Desktop, здесь не приводятся. Они на страницах клиентов.
- Нужна ли какому-либо клиенту обёртка `cmd /c` перед `npx`: в проверенных первоисточниках для этой страницы такого требования не найдено, поэтому оно не утверждается и не опровергается.
- Какой из механизмов завершения, `TerminateProcess` или Job Objects, использует конкретный клиент и сколько он ждёт выхода сервера: поставщики этого не публикуют.
- Пакеты `.mcpb` и реестр агентов Windows на этой странице не разбираются.

## Что читать дальше

- [Клиенты MCP](https://mcpdoc.ru/reference/clients/)
- [Linux](https://mcpdoc.ru/deployment/ubuntu/)
- [Транспорты MCP](https://mcpdoc.ru/protocol/transports/)
- [Устранение неполадок](https://mcpdoc.ru/reference/troubleshooting/)