Chatwoot через MCP: разговоры, ответы и отчёты поддержки без переключения окна
Разбираем Application API Chatwoot — self-hosted и облачной платформы поддержки клиентов: как устроены разговоры и их барьер записи, что значит self-hosted для безопасности запроса, и как всё это работает через MCP-сервер Mira: обзор нагрузки на поддержку, ответ клиенту, отчёты по скорости ответа — без переключения в отдельную вкладку Chatwoot.
Обзор
Chatwoot — открытая платформа поддержки клиентов: разговоры со всех каналов (email, чат на сайте, WhatsApp, Telegram, Instagram и другие) в одном месте, с командами, метками, заготовленными ответами и отчётами по скорости и качеству ответов. Ставят её и как облачный сервис (app.chatwoot.com), и — чаще — на свой сервер: у платформы открытый исходный код, и self-hosted инсталляция для бизнеса, который не хочет держать переписку с клиентами на чужом хосте, встречается едва ли не чаще облака.
Это и делает Chatwoot особым коннектором. Большинство API в этом блоге живут по одному фиксированному адресу — у Chatwoot адрес сервера называет владелец проекта сам, и он может указывать куда угодно: на облако, на свой VPS, на инсталляцию во внутренней сети компании. Разница некритична для человека, открывающего браузер, но критична для системы, которая ходит по этому адресу от имени агента, — обычный HTTP-клиент без ограничений мог бы отправить запрос не туда, куда думает владелец.
Application API целиком
Официальная спецификация Chatwoot описывает три разных API под одним названием — Platform (создание аккаунтов и пользователей администратором всей инсталляции), Client (виджет на сайте, для гостя без учётной записи) и Application (данные ОДНОГО аккаунта — то, чем пользуется агент поддержки). Mira покрывает Application целиком — 117 операций, извлечённых из официальной OpenAPI-спецификации программно, а не выборкой по документации:
| Раздел | Что даёт |
|---|---|
| Разговоры и сообщения | список, фильтр, статус, приоритет, назначение, метки, отправка сообщений |
| Контакты | создание, поиск, слияние, привязка к каналам |
| Ящики (каналы) и агенты | настройка каналов, команды, кто на каком ящике |
| Метки, заготовленные ответы, кастомные атрибуты | классификация обращений |
| Правила автоматизации, вебхуки, интеграции | что происходит без участия агента |
| База знаний | порталы, категории, статьи |
| Отчёты | время первого ответа, нагрузка по агентам/ящикам/командам, CSAT |
Platform API (создание новых аккаунтов на инсталляции) и Client API (виджет для гостя) не входят намеренно — это другая роль и другой ключ доступа: не владелец проекта разговаривает с Chatwoot, а сам Chatwoot разговаривает с посетителем сайта.
Барьер записи: не любое действие проходит без спроса
Обращения к API делятся на две категории: те, что читают данные (список разговоров, отчёт по скорости ответа), и те, что их меняют. Меняющие действия Chatwoot требуют явного разрешения на запись у источника — подключение «только на чтение» не даёт агенту ничего создать, изменить или удалить, запрос физически не уходит.
Внутри меняющих действий есть особый случай — отправка сообщения. Публичное сообщение (не приватная заметка) уходит клиенту в его канал: письмом, уведомлением в виджете чата, сообщением в WhatsApp. Это не «правка записи в базе», а высказывание от имени компании, которое клиент увидит, — барьер здесь так же строг, как и на удалении. Похожая история — индикатор «печатает»: ничего не сохраняется в базе, но клиент видит его в реальном времени, и это делает действие таким же наблюдаемым, как отправка сообщения.
Отдельно стоит слияние контактов: перенос переписки одного контакта в другой уничтожает контакт-донор без возможности разделить обратно — необратимое действие, которое стоит того, чтобы про него напомнить явно, а не только пометить как «меняющее».
Self-hosted — не абстрактный риск
Адрес сервера, номер аккаунта и токен доступа образуют источник данных, но только адрес приходит от человека настолько свободно, что может указывать куда угодно — в том числе на внутреннюю сеть, где стоит сама система. Запрос к такому адресу проходит через защиту, которая проверяет цель запроса перед тем, как её достичь, — тот же принцип, что применяется к любому self-hosted или пользовательскому адресу в других коннекторах этого блога (1С, Bitrix24, RetailCRM). Разница между «система ходит туда, куда указал владелец аккаунта Chatwoot» и «система ходит туда, куда указало чужое значение» — это разница между удобной интеграцией и дырой, и она стоит отдельной строчки в описании любого API с адресом от пользователя.
Как это выглядит через MCP
MCP — открытый протокол, по которому Claude подключается к внешним данным и действиям. Вместо переключения в отдельную вкладку с Chatwoot можно спросить обычными словами:
Что там с нагрузкой на поддержку сейчас?
Claude смотрит счётчики открытых/отложенных разговоров и, если нужно, отчёт по среднему времени первого ответа — без ручного похода в раздел Reports.
Ответь клиенту в разговоре 128: заказ отправлен, трек-номер такой-то.
Действие, которое требует разрешения на запись у источника: сообщение уйдёт клиенту в его канал, и модель понимает разницу между этим и приватной заметкой для коллег.
Слей эти два контакта — это один и тот же человек.
Необратимое действие: Claude предупредит, что контакт-донор пропадёт, и попросит подтверждения там, где того требует настройка проекта.
Как подключить
- В своём Chatwoot (или app.chatwoot.com): аватар в правом верхнем углу → Profile Settings → Access Token — скопируйте значение.
- Номер аккаунта — число в адресе страницы, например
.../app/accounts/123/...→123. - В Mira: проект → источники → Chatwoot → адрес сервера, номер аккаунта, Access Token.
Дальше Chatwoot доступен и в чате Mira, и через MCP-сервер в Claude, Cursor или другом клиенте с поддержкой протокола.
Новости в Telegram
Подпишитесь на каналы — новые статьи и обзоры каждый день.
Источники
Ещё по теме «MCP-серверы»
1С через OData: как достать данные учётной базы без единой строки кода на встроенном языке
Разбираем стандартный OData-интерфейс 1С:Предприятие: чем он отличается от API конкретного сервиса, как узнать, что вообще опубликовано на конкретной базе, как проводить и отменять проведение документов и как всё это работает через MCP-сервер Mira без единой строки кода на встроенном языке.
3 сентября 2026 г.Boxberry через API и MCP: документация переехала в Яндекс, а API остался жив
Разбираем API Boxberry для интернет-магазинов: один эндпоинт на 34 действия, поле method вместо путей, отказ, который иногда приходит на HTTP 200, и документация, которая в 2026 году целиком переехала на хостинг Яндекс Доставки — а сам API остался работать. Как всё это доступно через MCP-сервер Mira без единой строки кода.
3 сентября 2026 г.СДЭК через API и MCP: 46 методов, «принято» ≠ «выполнено» и две формы отказа
Разбираем CDEK API v2 изнутри: 46 методов на заказы, курьера, калькулятор и печатные формы, асинхронную обработку, при которой «202 Accepted» не значит «готово», и две разные формы отказа — и как всё это работает через MCP-сервер Mira без единой строки кода.
3 сентября 2026 г.