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

У меня несколько проектов на Windows-серверах. Стандартная история: services.msc, Event Viewer, Task Scheduler, порты, процессы. Каждый раз одно и то же: открываешь пять окон, ищешь ошибки, проверяешь зависимости, смотришь кто занял порт. Рутина, которая съедает время.

У меня уже стоит Claude Desktop с MCP, я через него работаю с GitHub и базами. Подумал: а почему бы не дать ему доступ к Windows? Написал MCP-сервер, который делает всю эту рутину за меня. Получилось 42 инструмента в 8 модулях. TypeScript, MIT, опубликован на npm.

В статье покажу, что внутри, как устроено и зачем каждый модуль. Буду рад фидбеку: что добавить, что лишнее, где можно сделать лучше. Если найдёте баги или захотите дополнить, PR приветствуются.

Установка

Одна команда:

npx windows-admin-mcp

Конфиг Claude Desktop (%APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "windows-admin": {
      "command": "npx",
      "args": ["-y", "windows-admin-mcp"]
    }
  }
}

Для Cursor, Windsurf, Claude Code аналогично. Требования: Windows 10/11 или Server 2016+, Node.js 18+, PowerShell 5.1+, права админа.

Можно установить и с GitHub напрямую:

git clone https://github.com/devladpopov/windows-admin-mcp.git
cd windows-admin-mcp
npm install && npm run build

Модули

Services (6 инструментов)

Стандартный набор: services_list, services_get, services_start, services_stop, services_restart, services_set_startup. Обертка над Get-Service / Set-Service с JSON-выводом.

Интереснее diagnose_service из модуля Diagnostics. Это цепочка из 4-5 проверок за один вызов:

1. Статус и конфигурация службы (Get-Service + Win32_Service)

2. Проверка порта, если указан (Get-NetTCPConnection)

3. Последние ошибки из Event Log по имени службы

4. Состояние всех зависимостей

5. Гипотеза на основе собранных данных

Пример вывода:

Служба: Spooler (Print Spooler)
Статус: Stopped
Тип запуска: Automatic
Аккаунт: LocalSystem

Порт 9100: занят процессом hp_print_service.exe (PID 4521)

Зависимости:
  RPCSS: Running
  HTTP: Stopped  <-- проблема

Последние ошибки (3 за час):
  Event 7031: Service terminated unexpectedly

Гипотеза: зависимость HTTP остановлена, Spooler не может запуститься.
Рекомендация: запустить HTTP, затем Spooler.

На ручную диагностику того же самого уходит 5-7 минут и три разных консоли. Здесь это одна команда.

Event Viewer (5 инструментов)

• events_query: запрос событий с фильтрацией по логу, уровню, источнику, времени, ключевым словам

• events_logs_list: список доступных логов с количеством записей

• events_sources_list: источники для конкретного лога

• events_explain: встроенная база из 23 Event ID (7031, 7034, 7036, 1000, 41 и др.) с причинами и решениями

• events_summary: сводка за период, группировка по уровню

Под капотом используется Get-WinEvent с XPath-фильтрами. Даты нормализуются, XML парсится, на выходе структурированный JSON.

events_explain работает без интернета. База зашита в код:

{
  id: 7031,
  source: "Service Control Manager",
  description: "Service terminated unexpectedly, recovery triggered",
  commonCauses: [
    "Unhandled exception in service",
    "Memory leak / OOM",
    "Dependency service unavailable",
    "Corrupted binary"
  ],
  suggestedFixes: [
    "Check Application log for Event 1000",
    "Review recovery settings in services.msc",
    "Update or reinstall the service",
    "Check memory with Performance Monitor"
  ]
}

Task Scheduler (8 инструментов)

Полный CRUD: scheduler_list, scheduler_get, scheduler_create, scheduler_delete, scheduler_enable, scheduler_disable, scheduler_run, scheduler_history.

scheduler_history достает историю запусков конкретной задачи из лога Microsoft-Windows-TaskScheduler/Operational. Полезно для дебага: видно, когда задача запускалась, с каким результатом завершилась, сколько длилась.

Processes (4 инструмента)

• processes_list: список с сортировкой по CPU/Memory/Name

• processes_get: детали (CPU, память, путь к бинарю, потоки, handles)

• processes_kill: завершение по имени или PID

• processes_ports: какой процесс слушает на каком TCP-порту

processes_ports под капотом делает Get-NetTCPConnection | Join с Get-Process. Банально, но когда нужно узнать кто занял 8080, удобнее чем netstat -ano | findstr.

Network (4 инструмента)

network_ping, network_check_port, network_dns, network_connections. Стандартная сетевая диагностика через Test-Connection, Test-NetConnection, Resolve-DnsName.

Observability (5 инструментов)

Этот модуль уже не просто обертка.

events_watch: поллинг с watermark. При первом вызове возвращает текущие Critical/Error события и запоминает метку времени. При повторном вызове показывает только новые. Полезно для мониторинга: AI может периодически дергать этот инструмент и сообщать о новых ошибках.

error_trends: анализ трендов. Группирует ошибки за N часов по часам, считает средний рейт для первой и второй половины периода, определяет тренд:

System log: 47 ошибок за 24ч
Тренд: GROWING (рейт вырос с 1.2 до 2.8/час)
Пик: 14:00-15:00 (8 ошибок)
Топ источники: Service Control Manager (23), DCOM (12)
Топ Event ID: 7036 (18), 10016 (9), 7031 (5)

Логика определения тренда: если средний рейт второй половины больше первой в 1.5+ раз, то GROWING. Меньше в 2+ раза, SHRINKING. Иначе STABLE.

system_changes: показывает что изменилось за N часов. Парсит Event ID 7045 (новая служба установлена), 7036 (смена состояния службы) и ищет свежие задачи в планировщике.

services_watch: ищет службы с StartType=Automatic, которые сейчас остановлены. Помогает быстро найти то, что должно работать, но не работает.

service_restarts: частота перезапусков и крашей. Парсит Event ID 7036/7031/7034, группирует по именам служб, считает рестарты и краши отдельно.

Safety (6 инструментов)

Деструктивные операции (kill, stop, restart, delete, bulk-операции) защищены confirmation flow:

1. Инструмент возвращает превью действия и confirmationId (UUID)

2. Пользователь видит, что именно произойдет

3. Действие выполняется только после вызова confirm_action(confirmationId)

4. Таймаут 5 минут, после чего confirmationId протухает

Критические процессы в блок-листе по умолчанию:

lsass, csrss, svchost, winlogon, smss,
services, wininit, TrustedInstaller

Даже с подтверждением их нельзя убить через MCP. Блок-лист настраивается через конфиг.

Bulk-операции ограничены: по умолчанию максимум 20 за один вызов. Защита от случайного services_bulk(action: "stop", filter: "*").

Audit

Каждый вызов инструмента логируется в JSONL:

{
  "timestamp": "2026-05-17T14:23:01.456Z",
  "tool": "services_stop",
  "params": {"name": "Spooler"},
  "result": "success",
  "durationMs": 1240
}

Лог можно запросить через audit_query с фильтрацией по инструменту и результату.

MCP Resources

Три ресурса, которые AI-клиент может читать автоматически:

• system://info: ОС, CPU, RAM, uptime, hostname, часовой пояс

• system://health: загрузка CPU/RAM/дисков, остановленные auto-start службы, свежие ошибки, общий статус

• system://services: количество служб по статусу и типу запуска

Resources работают как пассивный контекст: клиент читает их при старте и понимает, с какой системой работает, без дополнительных запросов.

Конфигурация

Файл config.json рядом с пакетом или через переменную WINDOWS_ADMIN_MCP_CONFIG:

{
  "modules": {
    "services": true,
    "events": true,
    "scheduler": true,
    "processes": true,
    "network": true,
    "diagnostics": true,
    "safety": true,
    "observability": true
  },
  "safety": {
    "requireConfirmation": true,
    "confirmationTimeoutMs": 300000,
    "blocklist": ["lsass", "csrss", "svchost", "winlogon", "smss"],
    "allowlist": []
  },
  "limits": {
    "maxProcessesToKill": 5,
    "maxEventsToReturn": 500,
    "maxBulkOperations": 20
  },
  "audit": {
    "enabled": true,
    "path": "./windows-admin-mcp-audit.jsonl",
    "maxSizeMB": 50
  }
}

Ненужные модули можно отключить. Для автоматизации в доверенной среде можно снять requireConfirmation. Блок-лист расширяется, allowlist работает как исключение из блок-листа.

Архитектура

Claude Desktop / Cursor / Claude Code
        |
        | JSON-RPC (stdin/stdout)
        |
   windows-admin-mcp (Node.js)
        |
        |-- config.ts       (загрузка конфига, блок-лист)
        |-- safety.ts        (confirmation flow)
        |-- audit.ts         (JSONL-логирование)
        |-- resources.ts     (MCP resources)
        |-- modules/
        |     |-- services/
        |     |-- events/
        |     |-- scheduler/
        |     |-- processes/
        |     |-- network/
        |     |-- diagnostics/
        |     |-- observability/
        |     |-- safety/
        |-- data/
              |-- event-ids.ts  (база Event ID)

Каждый модуль регистрирует свои инструменты через server.tool() из @modelcontextprotocol/sdk. Внутри вызывает PowerShell через child_process.exec, парсит JSON-вывод. Все строковые параметры экранируются для предотвращения инъекций.

Производительность

PowerShell-вызовы занимают основное время. Типичные замеры:

• services_list: ~200-400мс

• events_query (100 событий): ~500-800мс

• diagnose_service (цепочка из 5 шагов): ~1.5-3с

• system_health: ~2-4с

Для интерактивного использования через AI-ассистента вполне приемлемо. Для real-time мониторинга нет, но это и не цель.

Что хочу добавить

Проект на GitHub и npm под MIT.

Ближайшие планы:

• Расширить базу Event ID (сейчас 23, хочу хотя бы 100 самых частых)

• TUI для Event Viewer (терминальная альтернатива GUI)

• TUI для Task Scheduler

• Интеграция с Ollama для офлайн-анализа логов

Если администрируете Windows и пользуетесь MCP, попробуйте. Буду рад issues, PR и просто обратной связи в комментариях: что не хватает, что лишнее, где криво. Дополню и доработаю.

npx windows-admin-mcp