OpenClaw как MCP-сервер — доступ к мессенджерам и системным действиям из других агентов

У OpenClaw есть два режима работы с MCP (Model Context Protocol, протокол контекста модели): предоставлять внешнему MCP-клиенту доступ к уже маршрутизируемым разговорам через Gateway и управлять сохранёнными определениями сторонних MCP-серверов для сред выполнения, которые OpenClaw запускает или настраивает. Эти режимы решают разные задачи и настраиваются разными командами.

Проверено по официальной документации и релизам OpenClaw 8 сентября 2026 года; в официальном списке релизов Latest отмечена версия 2026.9.2.

Что это такое: две роли OpenClaw в MCP

У команды openclaw mcp есть два независимых назначения:

1. OpenClaw как MCP-сервер: openclaw mcp serve позволяет внешнему клиенту читать разговоры каналов, которые Gateway уже умеет маршрутизировать, и отправлять в них текстовые ответы.
2. OpenClaw как MCP-клиент: команды mcp add, set, configure, tools, login и другие управляют сохранёнными определениями сторонних MCP-серверов, которые затем могут использоваться подходящими средами выполнения OpenClaw.

Настройки mcp.servers и фильтр toolFilter относятся ко второй роли. Они не превращают openclaw mcp serve в универсальный шлюз к файлам, командной оболочке (shell), браузеру или всем установленным навыкам.

Как устроен мост к каналам

openclaw mcp serve запускает MCP-сервер по stdio. Клиент владеет дочерним процессом и поддерживает с ним соединение. Сам мост соединяется с локальным или удалённым OpenClaw Gateway по WebSocket.

flowchart LR
    A[MCP-клиент] -->|stdio| B[openclaw mcp serve]
    B -->|WebSocket| C[OpenClaw Gateway]
    C --> D[Telegram, Discord и другие каналы]

Разговор появляется в MCP только тогда, когда в состоянии Gateway уже сохранён маршрут: канал, получатель или назначение, а при необходимости также accountId и threadId. Мост не создаёт маршруты самостоятельно.

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

Инструменты, доступные MCP-клиенту

Текущая официальная поверхность openclaw mcp serve включает:

• conversations_list — список недавних разговоров с сохранёнными маршрутами;
• conversation_get — получение одного разговора по session_key;
• messages_read — чтение недавней истории;
• attachments_fetch — метаданные нетекстовых блоков и сохранённых медиа; это представление метаданных, а не отдельное долговременное хранилище файлов;
• events_poll — получение новых событий после указанного курсора;
• events_wait — ожидание следующего события;
• messages_send — отправка текста по уже сохранённому маршруту;
• permissions_list_open — список запросов подтверждения, замеченных после подключения моста;
• permissions_respond — ответ allow-once, allow-always или deny на такой запрос.

messages_send принимает только текст и требует существующий маршрут. Инструмент повторно использует канал, адресата, аккаунт и ветку исходного разговора.

Локальное подключение по stdio

Для Gateway с локальной конфигурацией достаточно команды:

openclaw mcp serve

Пример конфигурации MCP-клиента:

{
  "mcpServers": {
    "openclaw": {
      "command": "openclaw",
      "args": ["mcp", "serve"]
    }
  }
}

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

Подключение к удалённому Gateway

Сам MCP-клиент по-прежнему общается с мостом через stdio. Удалённым становится соединение между мостом и Gateway:

openclaw mcp serve --url wss://gateway.example.com:18789 --token-file /path/to/gateway.token

Вместо токена Gateway поддерживает пароль:

openclaw mcp serve --url wss://gateway.example.com:18789 --password-file /path/to/gateway.password

Официальная документация рекомендует по возможности передавать секрет через --token-file или --password-file, а не указывать его прямо в аргументах процесса. Для защищённого удалённого соединения используйте wss://.

Пример клиентской конфигурации:

{
  "mcpServers": {
    "openclaw": {
      "command": "openclaw",
      "args": [
        "mcp",
        "serve",
        "--url",
        "wss://gateway.example.com:18789",
        "--token-file",
        "/path/to/gateway.token"
      ]
    }
  }
}

В актуальном справочнике для serve нет флагов --http и --port. Streamable HTTP и SSE поддерживаются для сторонних серверов, которые OpenClaw сохраняет в mcp.servers, но это другая сторона интеграции.

Режим уведомлений для Claude Code

Помимо стандартных MCP-инструментов, мост умеет отправлять специальные уведомления Claude:

• notifications/claude/channel;
• notifications/claude/channel/permission.

Режим задаётся флагом:

openclaw mcp serve --claude-channel-mode on

Доступны значения auto, on и off. На дату проверки auto ведёт себя как on; автоматического определения возможностей клиента пока нет. Для обычного MCP-клиента можно отключить расширение:

openclaw mcp serve --claude-channel-mode off

Стандартные клиенты должны использовать events_poll или events_wait и не рассчитывать на Claude-специфичные уведомления.

Полезные сценарии

Агент разработки отправляет статус в рабочий чат

Условие запуска: Gateway уже знает маршрут рабочего разговора. Агент находит его через conversations_list, при необходимости читает контекст через messages_read и вызывает messages_send.

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

Подтверждение рискованного действия из канала

Пока мост подключён, MCP-клиент может получить запрос подтверждения выполнения команды или плагина, созданный Gateway и замеченный мостом. Клиент показывает запрос оператору и отвечает через permissions_respond.

Наблюдаемый результат: запрос получает решение allow-once, allow-always или deny. Мост не предоставляет долговременную историю таких запросов.

Почти моментальная реакция на входящее сообщение

Клиент вызывает events_wait с последним курсором. Запрос завершается при появлении подходящего события или по тайм-ауту.

Наблюдаемый результат: клиент получает новое событие без частого опроса. Для пропущенной или старой истории всё равно нужен messages_read.

Проверка результата подключения

После запуска проверьте результат через MCP-клиент:

1. В списке инструментов должны появиться conversations_list, messages_read, events_wait и messages_send.
2. Если маршрут рабочего разговора уже настроен, conversations_list должен вернуть хотя бы один разговор с сохранённым маршрутом.
3. messages_read должен показать его недавнюю историю.
4. Тестовое сообщение через messages_send должно появиться в том же канале и треде.

Если список разговоров пуст, сначала проверьте состояние Gateway. Обычно причина заключается в отсутствующих метаданных канала или получателя, а не в MCP-конфигурации.

Для проверки из исходного репозитория OpenClaw также предоставляет Docker smoke test:

pnpm test:docker:mcp-channels

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

Границы безопасности

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

• Защищайте удалённый Gateway токеном или паролем и используйте wss://.
• Предпочитайте файлы секретов аргументам командной строки.
• Настройте pairing, списки разрешённых отправителей и правила доверия на уровне каналов.
• Не выдавайте allow-always, пока не проверили конкретный инструмент и клиента.
• Учитывайте, что оперативные события и список подтверждений не сохраняются мостом после отключения.
• Ограничивайте права самого Gateway и его каналов независимо от MCP.

Песочница OpenClaw уменьшает область последствий для выполняемых инструментов, но по умолчанию выключена и не является полной границей безопасности. Gateway остаётся на хосте, а доступ плагинов и MCP-инструментов дополнительно регулируется общей политикой инструментов и параметром tools.sandbox.tools.

Ограничения

• Серверный режим работает по stdio; собственной удалённой HTTP-точки у openclaw mcp serve в актуальной документации нет.
• Мост показывает только разговоры с уже известными Gateway-маршрутами.
• messages_send отправляет только текст.
• Очередь событий ограничена и хранится в памяти.
• Мост не предоставляет долговременную историю подтверждений.
• Claude push работает только пока MCP-сессия жива и только в совместимом клиенте.
• Интерфейсы OpenClaw активно меняются, поэтому перед настройкой стоит сверять команды с документацией своей зафиксированной версии.

Официальные ссылки

• Документация openclaw mcp
• Конфигурация MCP, skills и plugins
• Песочница OpenClaw
• Релизы OpenClaw
• Репозиторий OpenClaw

Следующий шаг

Подробнее о модели угроз, prompt injection и подтверждении вызовов: MCP и безопасность — prompt injection, tool poisoning и как защититься.

Связанные материалы

• Статья: Два агента лучше одного — как связать OpenClaw и Hermes Agent в единую систему
• База знаний: OpenClaw — open-source персональный ИИ-агент для мессенджеров
• База знаний: MCP Apps — интерактивный UI для MCP

Если вы проектируете связку агента разработки с каналами OpenClaw и хотите разделить права, маршруты и подтверждения, эту схему полезно проверить до подключения рабочих аккаунтов.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov