Windows

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

Спецификация упоминает Windows в одном месте - в правилах завершения сервера на странице stdio.

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

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

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

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

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

• TerminateProcess безусловно завершает процесс и все его потоки. Процесс не получает возможности закончить работу сам.
• Job Objects позволяют управлять группой процессов как одним целым, в том числе завершить все процессы задания сразу. Это способ не оставить после сервера его дочерние процессы.

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

Клиент хранит команду запуска в своих настройках и сам запускает сервер. Где лежат настройки и как их менять, у каждого клиента своё: смотрите страницы Клиенты MCP и Claude.

Ниже - только то, что подтверждено первоисточниками. Источник здесь - руководство по подключению локальных серверов на сайте MCP. Оно написано на примере Claude Desktop и к другим клиентам относится не обязательно.

В JSON обратная косая черта - служебный знак, поэтому в путях 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 записи сервера.

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

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

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

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

По документации Microsoft Windows Subsystem for Linux позволяет запускать окружение Linux на машине с Windows без отдельной виртуальной машины и без двойной загрузки. WSL 2 запускает ядро Linux внутри лёгкой служебной виртуальной машины.

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

• Сервер stdio внутри WSL, клиент в Windows. По странице о работе с файловыми системами программы Linux запускаются из командной строки Windows командой wsl с нужной командой после неё. Такой процесс работает от имени пользователя WSL по умолчанию. В настройках клиента командой тогда становится wsl, а команда сервера уходит в параметры. Проверенного образца такой записи в документации клиентов для этой страницы не найдено.
• Сервер Streamable HTTP внутри WSL как служба systemd. WSL поддерживает systemd: он включается строкой systemd=true в разделе [boot] файла /etc/wsl.conf. Дальше применимо всё со страницы Linux.

По документации Microsoft служба - это приложение, которое соблюдает правила интерфейса диспетчера управления службами. Её можно запустить автоматически при загрузке системы, и она может работать, когда ни один пользователь не вошёл в систему.

Команда sc.exe create создаёт запись о службе в реестре и в базе диспетчера. Как выполнить правила диспетчера процессу Node.js или Python, документация Microsoft не описывает.

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

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

• Клиенты MCP
• Linux
• Транспорты MCP
• Устранение неполадок