VPSSpark Блог
← Вернуться к дневнику

2026: OpenClaw как MCP Server в процессе разработки — от openclaw mcp serve к токенам, белому списку инструментов и изоляции сессий

Заметки о сервере · 2026.04.14 · ~7 мин чтения

Рабочее место разработчика: интеграция OpenClaw как MCP-сервера в ежедневный цикл

С помощью openclaw mcp serve MCP-клиент поднимает stdio-мост к Gateway по WebSocket: список диалогов, чтение транскриптов, live-события, ответы и вспомогательные действия вокруг разрешений оформлены как инструменты MCP — без отдельного «клея» под каждый канал. Дальше важны три слоя: токен/пароль к удалённому Gateway, белые списки инструментов (и на стороне клиента, и на стороне каналов OpenClaw) и изоляция stdio-сессий с их live-очередями.

3
Слоя allowlist: клиент · openclaw mcp · канал
stdio
Один процесс моста на сессию IDE/агента
live
Очередь событий в памяти на stdio-сессию

С чего начать до первого успешного вызова инструмента

Сначала стабилизируйте хост: на Linux VPS — наш runbook по curl/Docker и типовым ошибкам (2026: OpenClaw на Linux VPS — curl vs Docker, проверка окружения и FAQ по типовым ошибкам). Если сразу подключать MCP без живого Gateway, пустые ответы в conversations_list чаще означают неполные маршруты сессий, а не «сломанный» JSON протокола.

Что на самом деле запускает openclaw mcp serve

Клиент стартует мост; пока открыт stdio, процесс держит WebSocket к локальному или удалённому Gateway и отражает уже снабжённые маршрутами метаданных разговоры в набор MCP-инструментов. Для discovery нужны корректные маршруты Gateway — пустые строки в conversations_list чаще указывают на незавершённую маршрутизацию, а не на дефект MCP. Старые сообщения читайте через messages_read; events_poll и events_wait видят только события, пришедшие после установления соединения моста.

Типовые схемы запуска
# Локальный Gateway (значение по умолчанию)
openclaw mcp serve

# Удалённый Gateway + токен из файла (секрет не попадает в history shell)
openclaw mcp serve --url wss://gateway-host:18789 \
  --token-file ~/.openclaw/gateway.token

# Подробные логи моста в stderr
openclaw mcp serve --verbose

IDE, headless-агент CI и песочница для экспериментов — три разных класса клиентов; для macOS runner в CI полезно заранее согласовать узлы и кэши: Короткие пики CI в 2026: self-hosted GitHub Actions на macOS — эластичный пул облачных Mac или постоянные узлы?.

Топология Когда удобна Где спотыкаются
Локальный Gateway + локальный клиент Итерации на ноутбуке, воспроизводимые тесты Разрешения и отправки сообщений всё равно трактуйте как почти продовые действия
Удалённый Gateway + --token-file Командный Gateway на облачном Mac или VPS Ротация токена как у SSH-ключа; права на путь к файлу максимально узкие
Режим канала Claude активен Клиенты в стиле Claude Code с push-уведомлениями Универсальным клиентам чаще нужен poll; уведомления только при живой сессии
Официальная документация
Набор флагов и инструментов меняется между минорными версиями OpenClaw — при обновлении сверяйтесь с upstream-документацией MCP/CLI как с источником истины.

Токены и пароли без утечек в логи

Удалённый Gateway принимает привычные переключатели: --token / --token-file или --password / --password-file. Предпочитайте файловые флаги, чтобы секрет не оказался в истории shell. В CI монтируйте токен только для чтения и не смешивайте WebSocket-URL с общими логами. В конфигурации MCP указывайте пути, а не inline-секреты; POSIX-права — только на пользователя агента.

На macOS удобно сочетать файловый токен с Keychain для вспомогательных секретов, а в облаке — с секрет-хранилищем раннера. В бою можно добавить внешний прокси с mTLS, но помните: мост показывает ровно те разговоры, которые Gateway уже умеет маршрутизировать; «подлатать» дыры доверия на уровне каналов самим MCP нельзя.

Граница доверия
Allowlist каналов, pairing и политика «кто может писать» остаются свойствами конфигурации OpenClaw. MCP-слой не заменяет эти решения задним числом.

Белые списки инструментов: три слоя, которые легко перепутать

Слой один: мост публикует фиксированную поверхность инструментов — allow/deny в профиле MCP-клиента это первый заслон. Слой два: команды openclaw mcp list|set|unset пишут исходящие определения MCP для других рантаймов OpenClaw; эти записи не зондируют удалённый сервер сами по себе. Слой три: allowlist каналов и pairing решают, кто может говорить; messages_send следует только уже существующему маршруту сессии. При «пропавших инструментах» отлаживайте в порядке: профиль клиента → маршруты Gateway → политика канала.

Изоляция сессий: очереди, разрешения и push Claude

У каждой stdio-сессии своя live-очередь в памяти; при обрыве соединения живое состояние теряется — для устойчивой истории используйте messages_read. permissions_list_open также эфемерен, а уведомления канала Claude существуют только пока стоит мост. Долгие IDE-сессии документируйте иначе, чем короткие CI-зонды, особенно вокруг таймаутов разрешений.

Для нескольких репозиториев задайте префиксы рабочим каталогам и ограничьте наследование интерактивного shell: агенту нужен минимальный PATH, иначе «работает у меня в терминале и падает у бота» маскируется как баг MCP.

Дымовой тест без реальных мессенджеров
В upstream есть Docker-смок для MCP-каналов (например, pnpm test:docker:mcp-channels) — разумно прогнать его до подключения продовых маршрутов Telegram или Discord.

FAQ из постмортемов

Почему conversations_list пустой?

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

Почему events_wait «пропустил» более старое входящее?

Так и задумано: live-очереди начинаются с момента подключения моста. Старые строки читайте через messages_read, затем poll или wait.

Включать ли режим канала Claude везде?

auto сейчас ведёт себя как «включено», но push имеет смысл только для клиентов, которые их реально обрабатывают; прочие агенты должны опираться на polling.

Как удержать опасные permissions_respond подальше от CI?

Относитесь к permissions_respond как к sudo: узкий auto-approver, человек в контуре при новых плагинах, без путаницы между состоянием моста и code review.

Куда деть секреты на macOS под launchd?

Keychain с ACL на конкретный бинарник, не кладите сырой токен в plist. Для CI — секреты раннера; локально — временный файл с правами 600 и очисткой после сессии.

На облачном Mac mini всё это стыкуется спокойнее

MCP-слой любит предсказуемую ОС: нативный Unix-стек, Homebrew и SSH без сюрпризов WSL, плюс стабильный график обновлений инструментов. Mac mini на Apple Silicon даёт высокую пропускную памяти для параллельных агентов и тихий простой порядка 4 Вт, что удобно для суточных воркеров. macOS с Gatekeeper и SIP снижает класс типовых компрометаций по сравнению с распространёнными Windows-рабочими станциями, а компактный корпус без шума вентиляторов уменьшает совокупную стоимость владения для команд, которым нужен постоянный узел под OpenClaw.

Если вы выносите MCP ближе к коду и логам, VPSSpark с облачным Mac mini M4 — прагматичная базаознакомьтесь с тарифами и закрепите инструменты за железом, которое не отвлекает от задачи.

Акция

MCP у рабочего стола: безопасность по слоям

Токены, белые списки и изоляция сессий — без надежды, что «никто не найдёт порт»

На главную
Акция Смотреть тарифы