MCP

openclaw mcp має два завдання:

• запускати OpenClaw як MCP-сервер за допомогою openclaw mcp serve
• керувати вихідними визначеннями MCP-серверів, що належать OpenClaw, за допомогою list, show, set і unset

Інакше кажучи:

• serve — це OpenClaw, що діє як MCP-сервер
• list / show / set / unset — це OpenClaw, що діє як клієнтський реєстр MCP для інших MCP-серверів, які його середовища виконання можуть споживати пізніше

Використовуйте openclaw acp, коли OpenClaw має самостійно розмістити сеанс кодового середовища й маршрутизувати це середовище виконання через ACP.

# OpenClaw як MCP-сервер

Це шлях openclaw mcp serve.

# Коли використовувати serve

Використовуйте openclaw mcp serve, коли:

• Codex, Claude Code або інший MCP-клієнт має напряму взаємодіяти з розмовами каналів, підтриманими OpenClaw
• у вас уже є локальний або віддалений OpenClaw Gateway із маршрутизованими сеансами
• вам потрібен один MCP-сервер, що працює з різними каналовими бекендами OpenClaw, замість запуску окремих мостів для кожного каналу

Натомість використовуйте openclaw acp, коли OpenClaw має сам розмістити кодове середовище виконання й утримувати сеанс агента всередині OpenClaw.

# Як це працює

openclaw mcp serve запускає stdio MCP-сервер. MCP-клієнт володіє цим процесом. Поки клієнт тримає stdio-сеанс відкритим, міст підключається до локального або віддаленого OpenClaw Gateway через WebSocket і надає маршрутизовані розмови каналів через MCP.

# Виберіть режим клієнта

Використовуйте той самий міст двома різними способами:

# Що надає serve

Міст використовує наявні метадані маршрутів сеансів Gateway, щоб надавати розмови, підтримані каналами. Розмова з’являється, коли OpenClaw уже має стан сеансу з відомим маршрутом, таким як:

• channel
• метадані одержувача або призначення
• необов’язковий accountId
• необов’язковий threadId

Це дає MCP-клієнтам одне місце, щоб:

• перелічувати нещодавні маршрутизовані розмови
• читати нещодавню історію стенограми
• чекати на нові вхідні події
• надсилати відповідь назад через той самий маршрут
• бачити запити на схвалення, що надходять, поки міст підключений

# Використання

openclaw mcp serve

openclaw mcp serve --url wss://gateway-host:18789 --token-file ~/.openclaw/gateway.token

openclaw mcp serve --url wss://gateway-host:18789 --password-file ~/.openclaw/gateway.password

openclaw mcp serve --verbose
openclaw mcp serve --claude-channel-mode off

# Інструменти мосту

Поточний міст надає такі MCP-інструменти:

# Модель подій

Міст утримує чергу подій у пам’яті, поки він підключений.

Поточні типи подій:

• message
• exec_approval_requested
• exec_approval_resolved
• plugin_approval_requested
• plugin_approval_resolved
• claude_permission_request

# Сповіщення каналу Claude

Міст також може надавати специфічні для Claude сповіщення каналу. Це еквівалент адаптера каналу Claude Code в OpenClaw: стандартні MCP-інструменти залишаються доступними, але живі вхідні повідомлення також можуть надходити як специфічні для Claude MCP-сповіщення.

Коли режим каналу Claude увімкнено, сервер оголошує експериментальні можливості Claude і може надсилати:

• notifications/claude/channel
• notifications/claude/channel/permission

Поточна поведінка мосту:

• вхідні повідомлення стенограми user пересилаються як notifications/claude/channel
• запити дозволів Claude, отримані через MCP, відстежуються в пам’яті
• якщо пов’язана розмова пізніше надсилає yes abcde або no abcde, міст перетворює це на notifications/claude/channel/permission
• ці сповіщення існують лише в живому сеансі; якщо MCP-клієнт відключиться, push-цілі не буде

Це навмисно специфічно для клієнта. Загальні MCP-клієнти мають покладатися на стандартні інструменти опитування.

# Конфігурація MCP-клієнта

Приклад конфігурації stdio-клієнта:

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

Для більшості загальних MCP-клієнтів почніть зі стандартної поверхні інструментів і ігноруйте режим Claude. Увімкніть режим Claude лише для клієнтів, які справді розуміють специфічні для Claude методи сповіщень.

# Параметри

openclaw mcp serve підтримує:

# Безпека та межа довіри

Міст не вигадує маршрутизацію. Він лише надає розмови, які Gateway уже вміє маршрутизувати.

Це означає:

• списки дозволених відправників, сполучення та довіра на рівні каналу все ще належать базовій конфігурації каналу OpenClaw
• messages_send може відповідати лише через наявний збережений маршрут
• стан схвалень є живим/у пам’яті лише для поточного сеансу мосту
• автентифікація мосту має використовувати ті самі засоби керування токеном або паролем Gateway, яким ви довіряли б для будь-якого іншого віддаленого клієнта Gateway

Якщо розмова відсутня в conversations_list, звичайна причина — не конфігурація MCP. Причина в тому, що в базовому сеансі Gateway відсутні або неповні метадані маршруту.

# Тестування

OpenClaw постачає детермінований Docker smoke-тест для цього мосту:

pnpm test:docker:mcp-channels

Цей smoke-тест:

• запускає контейнер Gateway із початковими даними
• запускає другий контейнер, який породжує openclaw mcp serve
• перевіряє виявлення розмов, читання стенограми, читання метаданих вкладень, поведінку живої черги подій і маршрутизацію вихідних надсилань
• перевіряє сповіщення каналу та дозволів у стилі Claude через справжній stdio MCP-міст

Це найшвидший спосіб довести, що міст працює, без підключення справжнього облікового запису Telegram, Discord або iMessage до тестового запуску.

Ширший контекст тестування див. у Тестування.

# Усунення несправностей

# OpenClaw як реєстр MCP-клієнта

Це шлях openclaw mcp list, show, set і unset.

Ці команди не відкривають OpenClaw через MCP. Вони керують визначеннями MCP-серверів, що належать OpenClaw, у mcp.servers у конфігурації OpenClaw.

Ці збережені визначення призначені для середовищ виконання, які OpenClaw запускає або налаштовує пізніше, як-от вбудований Pi та інші адаптери середовища виконання. OpenClaw зберігає визначення централізовано, щоб цим середовищам виконання не потрібно було підтримувати власні дублікати списків MCP-серверів.

Адаптери середовища виконання можуть нормалізувати цей спільний реєстр до форми, якої очікує їхній нижчий клієнт. Наприклад, вбудований Pi напряму споживає значення OpenClaw transport, тоді як Claude Code і Gemini отримують нативні для CLI значення type, як-от http, sse або stdio.

# Збережені визначення MCP-серверів

OpenClaw також зберігає полегшений реєстр MCP-серверів у конфігурації для поверхонь, яким потрібні MCP-визначення, керовані OpenClaw.

Команди:

• openclaw mcp list
• openclaw mcp show [name]
• openclaw mcp set <name> <json>
• openclaw mcp unset <name>

Примітки:

• list сортує імена серверів.
• show без імені виводить повний налаштований об’єкт MCP-сервера.
• set очікує одне значення JSON-об’єкта в командному рядку.
• Використовуйте transport: "streamable-http" для MCP-серверів Streamable HTTP. openclaw mcp set також нормалізує нативне для CLI type: "http" до тієї самої канонічної форми конфігурації для сумісності.
• unset завершується помилкою, якщо сервер із таким іменем не існує.

Приклади:

openclaw mcp list
openclaw mcp show context7 --json
openclaw mcp set context7 '{"command":"uvx","args":["context7-mcp"]}'
openclaw mcp set docs '{"url":"https://mcp.example.com","transport":"streamable-http"}'
openclaw mcp unset context7

Приклад форми конфігурації:

{
  "mcp": {
    "servers": {
      "context7": {
        "command": "uvx",
        "args": ["context7-mcp"]
      },
      "docs": {
        "url": "https://mcp.example.com",
        "transport": "streamable-http"
      }
    }
  }
}

# Транспорт stdio

Запускає локальний дочірній процес і взаємодіє через stdin/stdout.

# Транспорт SSE / HTTP

Підключається до віддаленого MCP-сервера через HTTP Server-Sent Events.

Приклад:

{
  "mcp": {
    "servers": {
      "remote-tools": {
        "url": "https://mcp.example.com",
        "headers": {
          "Authorization": "Bearer <token>"
        }
      }
    }
  }
}

Чутливі значення в url (userinfo) і headers редагуються в журналах і виводі стану.

# Транспорт Streamable HTTP

streamable-http — це додатковий варіант транспорту поряд із sse і stdio. Він використовує потокове передавання HTTP для двонапрямної взаємодії з віддаленими MCP-серверами.

Конфігурація OpenClaw використовує transport: "streamable-http" як канонічне написання. Нативні для CLI значення MCP type: "http" приймаються під час збереження через openclaw mcp set і виправляються openclaw doctor --fix в існуючій конфігурації, але саме transport напряму споживає вбудований Pi.

Приклад:

{
  "mcp": {
    "servers": {
      "streaming-tools": {
        "url": "https://mcp.example.com/stream",
        "transport": "streamable-http",
        "connectionTimeoutMs": 10000,
        "headers": {
          "Authorization": "Bearer <token>"
        }
      }
    }
  }
}

# Поточні обмеження

Ця сторінка документує міст у тому вигляді, у якому він постачається сьогодні.

Поточні обмеження:

• виявлення розмов залежить від наявних метаданих маршруту сеансу Gateway
• немає загального push-протоколу поза адаптером, специфічним для Claude
• інструментів редагування повідомлень або реакцій поки немає
• транспорт HTTP/SSE/streamable-http підключається до одного віддаленого сервера; мультиплексованого upstream поки немає
• permissions_list_open включає лише схвалення, спостережені, поки міст підключений

# Пов’язане

• Довідник CLI
• Plugins