MCP czy webhook: czego naprawdę potrzebujesz
MCP działa na zasadzie żądania i odpowiedzi: asystent wywołuje narzędzie, gdy prosi go o to użytkownik. Webhook działa odwrotnie: Meta dostarcza zdarzenie, a Twój system decyduje, co zrobić. Nic, co reaguje automatycznie, nie powstanie na samym MCP.
Ścieżki integracji oferowane przez połączony numer: MCP i webhook.
Sposoby, w jakie przychodząca wiadomość może uruchomić serwer MCP.
Narzędzie MCP konfigurujące drugą ścieżkę.
Dlaczego MCP nie może automatycznie odpowiedzieć klientowi?
Ponieważ protokół nie ma mechanizmu wybudzania.
Serwer MCP udostępnia narzędzia, które wywołuje klient. Wywołanie pochodzi od asystenta, który sam odpowiada użytkownikowi. Nie ma kierunku przychodzącego: nic w wysłaniu wiadomości WhatsApp przez klienta nie może dotrzeć do asystenta i spowodować jego działania. Dotyczy to każdego serwera MCP w każdym produkcie, a nie tylko naszego rozwiązania.
Dlatego na pytanie, które prędzej czy później zadaje każdy kupujący, czyli czy AI może odpowiadać klientom w nocy, odpowiada webhook, a nie MCP. Meta dostarcza wiadomość do systemu, który uruchamiasz, a ten system decyduje, co zrobić, w tym także może wywołać model.
Do czego naprawdę dobrze służy każda ścieżka?
MCP służy do pracy wykonywanej przez człowieka. Który z moich numerów działa nieprawidłowo, wyślij temu klientowi potwierdzenie, utwórz szablon aktualizacji zamówienia, skieruj numer tego klienta na mój serwer. Każda z tych czynności zaczyna się od czyjejś prośby i każdą szybciej wykonasz przez asystenta niż w panelu.
Webhook służy do wszystkiego, co musi wydarzyć się bez obecności człowieka. Pierwsza odpowiedź po godzinach pracy, przekierowanie do właściwej osoby, zapis w CRM, uruchomienie przepływu pracy.
Najważniejsze jest to, że MCP może skonfigurować webhooka. get_connect_link tworzy link otwierany przez klienta, a set_webhook_destination kieruje jego numer do Twojego systemu, więc agent może przeprowadzić konfigurację ścieżki, której sam nie obsługuje.
Które narzędzia obsługują którą ścieżkę?
Asystenci obsługują MCP: Claude, ChatGPT, Cursor, Claude Code. Platformy automatyzacji przeważnie tego nie robią, a różnica nie jest taka, jakiej ludzie się spodziewają.
Make i Zapier uruchamiają własne serwery MCP, udostępniając asystentom swoje działania. Żaden z nich nie działa jako klient MCP, więc żaden nie może wywoływać naszych narzędzi. Dla nich integracja oznacza webhook i wywołanie HTTP.
Wyjątkiem jest n8n. Jego MCP Client Tool łączy się ze zdalnym serwerem i obsługuje OAuth2, więc węzeł agenta w przepływie pracy n8n może bezpośrednio wywoływać nasze narzędzia. Nawet wtedy przepływ pracy zaczyna się od webhooka, bo tylko on reaguje.
Typowe błędy
- Kupowanie MCP z myślą o automatycznych odpowiedziach. Działa na żądanie, a o 3:00 nikt go nie wywołuje.
- Założenie, że platforma z serwerem MCP może taki serwer obsługiwać. Make i Zapier udostępniają, ale nie korzystają.
- Budowanie obu ścieżek do tego samego zadania. Służą różnym połowom tego samego systemu.
Łącznik zawiera set_webhook_destination, więc ścieżka asystenta może skonfigurować ścieżkę automatyzacji bez otwierania panelu.
Najczęściej zadawane pytania
Czy asystent może obserwować mojego WhatsAppa?
Nie. Nic nie może wysłać zdarzenia do serwera MCP. Obserwowanie to zadanie webhooka, który może następnie wywołać model.
Czy potrzebuję obu?
Większość rzeczywistych systemów używa obu: MCP do pracy wykonywanej przez ludzi, a webhooka do wszystkiego, co dzieje się bez ich udziału.
Czy Zapier może korzystać z Waszego serwera MCP?
Nie. Zapier jest serwerem MCP, a nie klientem, więc nie może wywoływać naszych narzędzi.
A n8n?
Tak, przez MCP Client Tool z OAuth2. To jedyna z tych trzech platform automatyzacji, która może to zrobić.
Czytaj dalej
Gotowy, aby zacząć?
Skonfiguruj WhatsApp Coexistence w kilka minut, nie miesięcy. Aplikacja nadal działa na telefonie.
Rozpocznij bezpłatny okres próbnyZweryfikowano w