TL;DR: Поставьте пять MCP-серверов в один чат Cursor: Whapi.Cloud — отправка, чтение и health WhatsApp; PostgreSQL — строки CRM; GitHub — хендлер webhook; Sentry — путь запроса; Playwright — UI на staging. Сначала проверьте каждый сценарий отдельно. Собирайте один общий промпт только когда все карточки уже работают. Не берите send-only обёртки Cloud API, которые не читают CRM, репозиторий, ошибки и браузер.
Пять MCP-серверов дают Python-разработчику одного AI-агента с WhatsApp, данными CRM, исходным кодом, ошибками продакшена и UI CRM. Интеграция WhatsApp идёт из одного чата, а не из пяти REST-клиентов. Whapi.Cloud в этом сценарии — MCP слоя WhatsApp API. PostgreSQL, GitHub, Sentry и Playwright — соседние слои.
Мы видели команды, которые подключали WhatsApp MCP только через Graph и всё равно держали psql, GitHub и Sentry в других окнах. Входящий чат, из которого так и не появляется лид в CRM, как раз показывает этот разрыв.
Model Context Protocol стандартизирует доступ к инструментам в одной сессии агента. Подключите канал, не копируйте сюда mcp.json, затем запускайте пять сценариев.
Что на самом деле стоит за запросом «лучшие MCP-серверы для WhatsApp API»
Поисковый запрос называет пять слоёв стека в одном чате агента, а не пять WhatsApp API. MCP Cloud API, который умеет только отправлять, всё равно оставляет CRM, GitHub, Sentry и браузер в других окнах.
Выдача по запросу «top mcp servers whatsapp api integration» — это send-обёртки Graph. Они вызывают Meta* Cloud API и на этом заканчиваются: нет строки лида, нет хендлера, нет issue в Sentry, нет скриншота CRM. Первая ошибка — поставить один WhatsApp MCP из поиска и удивляться, почему Cursor не доводит Python-интеграцию до конца.
Называйте это стеком из пяти MCP в одном чате. Whapi.Cloud — слой, который смотрит в WhatsApp. Остальные четыре сервера живут в той же сессии Cursor. Пять сценариев вы копируете из одного чата.
Каждая строка — отдельная работа. Соседние серверы не заменяют канал WhatsApp.
| MCP-сервер | Роль в стеке | Пример задачи агента |
|---|---|---|
| Whapi MCP (Whapi.Cloud) | слой WhatsApp API | Ответить, перечислить входящие, проверить существование номера, GET health канала |
| PostgreSQL MCP | данные CRM | Найти клиента по телефону, перечислить тикеты и сделки, вставить лид после одобрения |
GitHub MCP (github/github-mcp-server) |
исходники | Открыть хендлер webhook, посмотреть issues и pull request |
Sentry MCP (@sentry/mcp-server) |
ошибки продакшена | Проследить webhook → хендлер → CRM вдоль одного запроса |
Playwright MCP (@playwright/mcp) |
UI CRM | На staging создать контакт и проверить тред переписки |
Персональный WhatsApp Web MCP не занимает ни одну из этих строк как продакшен-CRM. Это десктопная сессия. Пять карточек ниже — задачи продакшен-формы.
Whapi MCP — слой WhatsApp API, а не весь стек
Send-only MCP Cloud API — это не WhatsApp-слой этого стека. Whapi MCP в том же чате агента закрывает живую отправку, чтение и health, а затем подключаются CRM, GitHub, Sentry и браузер.
Обёртка Cloud API MCP вызывает Graph send/receive и останавливается. Берите её только если вы уже живёте на Meta* Cloud API. Берите Whapi MCP, когда агент должен работать с подключённым номером WhatsApp и затем передавать задачу остальным четырём серверам.
| Измерение | MCP-обёртка Cloud API | MCP шлюза Whapi QR/сессии |
|---|---|---|
| Учётные данные | токен приложения Meta* + WABA | токен канала Whapi.Cloud после скана QR |
| Проверка Meta* | бизнес-верификация и одобрение шаблонов | не нужна, чтобы подключить номер |
| Модель входящих | только webhook; прямого запроса канала нет | webhook плюс живые запросы сообщений/контактов/чатов |
| Шаблоны / 24-часовое окно | нужны для большей части исходящих вне окна | на обычных переписках шаблонного гейта нет |
| Группы / каналы | ограничено или недоступно | полный API-доступ к группам, сообществам, каналам, статусам |
| Кто хостит webhook | ваш HTTPS endpoint, доступный извне | ваш HTTPS endpoint; состояние канала можно запросить, даже если webhook потерялся |
| Пригодность для агента | низкая: только Graph send/receive | высокая: слой WhatsApp, который стыкуется с серверами БД/кода/ошибок/UI |
В официальном WhatsApp Business API бизнес-верификация Meta* и одобрение шаблонов стоят перед большей частью исходящих. В Whapi.Cloud эти ворота не нужны, чтобы подключить номер, а обычные переписки не режутся шаблонами: канал работает на сокетах web-сессии.
Вы ещё и покупаете управляемый шлюз вместо того, чтобы самим хостить Graph-обёртку. Группы, каналы, статусы и проверка номеров остаются на этой поверхности WhatsApp. MCP Cloud API только под шаблоны их не отдаёт.
Не копируйте сюда mcp.json. Подключите Whapi MCP по гайду для Cursor, VS Code и GitHub Copilot, затем выполните HTTP-чтения ниже.
Живой канал: отправка, чтение и health
Whapi.Cloud отдаёт эти проверки по HTTP на https://gate.whapi.cloud/. Пишите REST на Python против этого хоста. GET /messages/list возвращает недавние сообщения. GET /messages/list/{ChatID} сужает выборку до одного чата. GET /messages/{MessageID} возвращает полный объект. HEAD /contacts/{ContactID} — только существование: берите HEAD, не GET, когда нужен ответ да/нет. GET возвращает метаданные контакта. HEAD отвечает, есть ли номер в WhatsApp.
GET /health сообщает статус канала. POST /messages/text отправляет текст на chat id; обязательные поля — to и body. Пустой массив messages в целевом окне значит, что номер до этого канала не дошёл. На CRM пеняйте позже.
import os
import requests
TOKEN = os.environ["WHAPI_TOKEN"]
headers = {"Authorization": f"Bearer {TOKEN}"}
# GET /health first. A dead channel makes every later MCP look like a CRM bug.
health = requests.get("https://gate.whapi.cloud/health", headers=headers)
health.raise_for_status()
# from_me=False keeps the list on inbound. An empty list here is a channel miss; look at CRM only after this returns rows.
inbound = requests.get(
"https://gate.whapi.cloud/messages/list",
headers=headers,
params={"count": 50, "from_me": False},
).json()
contact_id = "15551234567"
# HEAD 404 means this ContactID is not on WhatsApp. Do not INSERT a CRM lead from a guessed number.
# GET /contacts/{ContactID} returns metadata; existence-only is HEAD /contacts/{ContactID}.
exists = requests.head(
f"https://gate.whapi.cloud/contacts/{contact_id}",
headers=headers,
)
print(health.status_code, len(inbound.get("messages", [])), exists.status_code)
Whapi MCP собирает эту поверхность из OpenAPI, поэтому агент держит те же имена, что и HTTP-документация. URL webhook по-прежнему ваш. MCP смотрит состояние канала, если webhook потерялся. Этот endpoint за вас он не хостит.
PostgreSQL MCP ищет клиентов, тикеты, сделки и пишет лиды
Когда канал WhatsApp уже можно опрашивать, PostgreSQL MCP ищет клиентов по телефону, открывает тикеты, проверяет сделки, пишет лиды и ловит дубликаты строк.
Этой карточке дайте тот же вес, что и карточке WhatsApp. Спросите клиента по телефону E.164, затем тикеты, открытые сделки, upsert лида и дубликаты — до любой записи. Отправить WhatsApp легко. Надёжный приём и дедупликация при retry — вот сложное: повторный webhook вставляет того же человека дважды, если ключ только телефон, а message id вы игнорируете.
На практике команды, которые пропускают эту проверку, вставляют один и тот же лид дважды. PostgreSQL MCP на продакшен-лидах и контактах по умолчанию держите read-only. Предложите INSERT. Дождитесь человека. Записи в первый день — только в lookup-таблицы, которыми владеет оператор.
Полезный цикл — WhatsApp → AI → PostgreSQL → снова WhatsApp: входящий чат, действие в CRM, исходящий ответ с того же номера. Поиск по телефону и статус сделки всё равно окупаются в тихие дни. Фреймворк решений по интеграции WhatsApp и CRM трактует потерянные поля как проблему синхронизации данных — это как раз работа этой карточки.
Запрос «входящие за 24 часа без лида» вложен сюда нарочно. Он фильтрует таблицу сообщений по received_at. В официальном WhatsApp Business API 24-часовое окно переписки закрывает большую часть исходящих вне шаблонов. В Whapi.Cloud этот SQL — только гигиена CRM по received_at: у обычных переписок нет шаблонного окна.
-- Nested hygiene query: inbound phones in the last 24 hours with no lead row.
-- Skipping the join on message_id during webhook retries duplicates the same person.
SELECT m.phone_e164, m.received_at, m.message_id
FROM inbound_messages m
LEFT JOIN leads l ON l.phone_e164 = m.phone_e164
WHERE m.received_at >= NOW() - INTERVAL '24 hours'
AND l.id IS NULL
ORDER BY m.received_at DESC;
Назовите тот Postgres MCP, который у вас реально крутится. Единого канонического npm-идентификатора, который можно скопировать, нет. Когда можете — направляйте его на реплику. Агент должен вернуть id, phone_e164, created_at и флаг дубликата — и остановиться.
GitHub MCP связывает webhook JSON WhatsApp с хендлером CRM-коннектора
Когда лиды в CRM выглядят неправильно, GitHub MCP накладывает webhook JSON Whapi на хендлер коннектора, который должен был сохранить эти строки.
Whapi.Cloud доставляет webhook JSON на ваш HTTPS endpoint. Ваш сервер решает, какие поля станут колонками CRM: это webhook JSON, которым владеет разработчик. GitHub MCP (github/github-mcp-server) открывает этот сервер, не выходя из Cursor. Ищите по репозиторию, issues и pull request. Sentry хендлер не напишет.
Типичные точки:
-
Поиск по репо: найдите модуль CRM-коннектора и функцию, которая читает тело webhook.
-
Issues и PR: смотрите недавние изменения маппинга. Переименованное поле payload часто уезжает в пятничный PR без теста CRM. Прочитайте diff и остановитесь.
-
Вложенный пример: если коннектор обрабатывает
messages.postи никогда не пишетcontact_id, строка лида остаётся пустой, хотя канал выглядит здоровым. Почините маппинг, затем заново прогоните карточку PostgreSQL.
Формат входящих webhook документирует массивы вроде messages[], statuses[], chats[] и contacts[]. GitHub MCP держите read-only, пока человек не откроет PR. Спросите путь к файлу, имя функции и точный JSON-ключ, который читает коннектор. Если два хендлера совпадают по имени события, откройте оба файла и сравните запись в колонку.
Python-хендлеры, которые уже принимают webhook Whapi, можно начать с туториала Python WhatsApp-бота. Карточка GitHub отвечает, какой файл и какое поле.
Sentry MCP ведёт webhook через хендлер и CRM
Когда GitHub показал хендлер, Sentry MCP ведёт этот webhook через хендлер и CRM, пока stack trace не назовёт падающую строку.
Эту карточку используйте для разбора продакшена. Код хендлера она не пишет. @sentry/mcp-server тянет issue, стек, теги и breadcrumbs — и вы перестаёте спорить, что клиент «ничего не отправлял». Полезный ход — трассировка пути запроса: webhook пришёл, хендлер отработал, вызов CRM вернул 4xx или ушёл в timeout, исходящий ответ так и не вышел. Это тот же путь событие-реакция, по которому webhook и должен идти.
Проекты, которые не ставят тег телефона или message id на события Sentry, тратят инцидент на сравнение скриншотов. Коррелируйте по timestamp плюс тот же E.164, что использовали в PostgreSQL. Ищите ошибку валидации CRM, unique constraint на дубликатах или пустой contact_id после переименования payload, которое вы уже видели в GitHub.
Поиск issue держите read-only. Не давайте агенту закрывать или удалять issue в Sentry. После фикса человек отмечает issue выполненным. Стартуйте агента с полного issue: вставленные сниппеты прячут breadcrumbs. Если трасса чистая, а канал видел входящее, оставшийся баг — маппинг или UI. Отдайте это GitHub или Playwright. Если канал ведёт себя неожиданно, напишите в поддержку Whapi.Cloud через виджет чата на whapi.cloud.
Playwright MCP создаёт контакт в CRM и проверяет переписку
Когда Sentry назвал падающую строку, Playwright MCP всё равно создаёт контакт CRM на staging и проверяет переписку, которую реально видит поддержка.
Postman доказывает только HTTP-путь. Код 200 от POST /messages/text не значит, что панель переписки CRM отрисовала тред. @playwright/mcp открывает staging, создаёт контакт, запускает отправку (или ждёт webhook) и проверяет текст, который оператор отправил бы поддержке скриншотом. Коллекция Postman Whapi.Cloud — проверка HTTP. Playwright — проверка панели.
SPA-доски врут так, как REST-клиент не увидит. API лида возвращает 201, а вид переписки всё ещё биндится к старому contact_id и показывает пустой тред. Снимите дерево доступности: видимое имя, E.164, последний body. Если этого узла нет, сначала перепроверьте маппинг webhook, а не селекторы CSS.
- Откройте форму контакта CRM на staging и создайте контакт с тестовым E.164.
- Отправьте или получите одно сообщение WhatsApp через уже проверенный канал Whapi.
- Падайте, если треда нет, даже когда HTTP был 200. Строку Postgres подтверждайте только после того, как карточка PostgreSQL уже отработала.
Заведите тестовый номер на staging. Браузер держите там: продакшен-сессия, которая может удалить сделку, — не тот runtime. Если Playwright зелёный, а PostgreSQL пустой, у вас баг синхронизации. Если оба зелёные и Sentry молчит, хватит искать доставку.
Собирайте пять MCP в одном промпте только после отдельных сценариев
Собирайте пять MCP-инструментов в одном промпте только после того, как проверка переписки Playwright и остальные отдельные сценарии уже работают.
Цепочку считайте демо WhatsApp API MCP рядом с четырьмя соседними серверами. Она не заменяет пять карточек.
After each standalone workflow works:
1. Whapi: GET /health, GET /messages/list, HEAD /contacts/{ContactID}.
2. PostgreSQL: find client by phone; propose a lead insert and wait for approval.
3. Sentry: errors for this webhook timestamp.
4. GitHub: CRM connector that handles messages.post.
5. Playwright: staging contact plus conversation assert.
No production writes. Stop at the first broken layer.
Если слой падает, оставайтесь на этой карточке. Не прыгайте в Playwright, «чтобы глянуть, нормально ли выглядит».
Записи агента, область Sentry и браузер на staging всё ещё нужно ограничивать
Этому составному промпту всё ещё нужны ворота: продакшен-Postgres только на чтение, область org в Sentry, браузеры на staging и никакого персонального WhatsApp Web MCP в роли CRM.
Продакшен-лиды и контакты держите read-only. Запись ограничивайте lookup-таблицами оператора после человеческого «да». Playwright направляйте на staging. Sentry MCP ограничивайте org и проектом, который вы сознательно открываете. Не принимайте персональный WhatsApp Web MCP как продакшен-CRM: это десктопная сессия. Чаты WhatsApp, которые не синхронизируются в CRM, не попадают в воронку продаж — так отделы недвижимости теряют входящий инвентарь.
Пять MCP-серверов по-прежнему дают Python-разработчику WhatsApp, данные CRM, исходники, ошибки и UI из одного чата, а Whapi.Cloud в этом сценарии — MCP слоя WhatsApp API. Поставьте пять отдельных карточек, затем собирайте.
