--- title: "Nieoficjalny serwer MCP do CRM Livespace" description: "Serwer MCP do Livespace CRM: 11 narzędzi, tryb read-only, zapis po zgodzie człowieka i otwarty kod na licencji MIT. Zobacz techniczne case study." url: "https://www.kubamasztalski.pl/case-studies/livespace-crm-mcp" dateModified: "2026-08-07" author: "Kuba Masztalski" language: "pl" --- > Wersja Markdown strony https://www.kubamasztalski.pl/case-studies/livespace-crm-mcp > Indeks całej strony: https://www.kubamasztalski.pl/llms.txt # Nieoficjalny serwer MCP do CRM Livespace Projekt: Projekt własny. 11 narzędzi zamiast 80 metod API Livespace CRM MCP to nieoficjalny, otwartoźródłowy serwer, który daje asystentom AI dostęp do CRM Livespace bez oddawania im surowego API. Zrobiłem go we własnym zakresie, poza Livespace. Sześć narzędzi czyta dane, pięć je zmienia, a każdy zapis wymaga zgody człowieka. Wersja 0.1.0 jest publiczna na npm i w oficjalnym MCP Registry. ## Zobacz, co ten serwer zmienia w pracy z CRM-em - **11 narzędzi dla LLM-ów** - Livespace wystawia około 80 metod RPC. Serwer zbiera je w 11 operacji opisanych zadaniem, które agent ma wykonać, więc model nie składa wywołań API z pamięci. - **Zapis dopiero po zgodzie** - Każda zmiana zaczyna się od planu, który nic nie zapisuje. Potwierdzenie jest podpisane, jednorazowe i ważne pięć minut. Gdy rekord zmienił się w międzyczasie, serwer wstrzymuje zapis. - **Read-only jednym przełącznikiem** - Jedna zmienna środowiskowa usuwa wszystkie pięć narzędzi zapisu z listy i blokuje ich wywołanie. To zalecany tryb pierwszego uruchomienia. - **Publiczna wersja 0.1.0** - Kod na GitHubie na licencji MIT, paczka na npm, wpis w oficjalnym MCP Registry ze statusem active. Uruchomienie jedną komendą przez bunx. ## Szczegóły realizacji ### 1. Skąd wziął się projekt Livespace to polski CRM, w którym pracują zespoły sprzedaży kilku firm, z którymi współpracuję. Codzienna robota w takim systemie to setki drobnych ruchów: znajdź szansę, dopisz notatkę po rozmowie, przesuń etap, sprawdź, co stoi w lejku. Założyłem, że asystenci AI, których używam na co dzień, mogą obsłużyć większość tych ruchów. Brakowało im tylko bezpiecznej drogi do systemu. Protokół MCP daje taką drogę. Serwer wystawia agentowi zamkniętą listę narzędzi i agent nie może wyjść poza nią. Zbudowałem taki serwer dla Livespace i opublikowałem go na licencji MIT. Livespace tego serwera nie firmuje ani nie wspiera. Kod jest publiczny, więc zanim ktoś wpuści taki serwer do swojego CRM-a, może sprawdzić, co ten serwer robi z danymi. ### 2. Ryzyka bezpośredniego dostępu agenta do API Bezpośredni dostęp do około 80 metod API zostawia trzy konkretne ryzyka. API Livespace nie ma sortowania ani agregacji. Pytanie „pokaż moje największe otwarte szanse" wymaga pobrania listy, przefiltrowania jej i posortowania po stronie klienta. Przy większym zbiorze wynik może zostać ucięty przed sortowaniem, a model nie dostanie informacji, że widzi tylko fragment. Nie ma też operacji „ustaw etap szansy". Etap wynika z najdalszego zaznaczonego kroku procesu, więc przesunięcie szansy to seria zaznaczeń i odznaczeń. Samodzielnie ułożona sekwencja może cofnąć historię procesu. Trzeci powód to identyfikatory. Te z API różnią się od widocznych w interfejsie Livespace, więc użycie identyfikatora z interfejsu jak identyfikatora API może wskazać niewłaściwy rekord. Treść w CRM jest niezaufanym wejściem. Pisali ją ludzie z zewnątrz, więc notatka albo e-mail mogą zawierać zdanie udające polecenie dla agenta. ### 3. Jak zbudowany jest serwer Serwer stoi między klientem MCP a API Livespace. Klient rozmawia z użytkownikiem i wybiera narzędzie. Serwer sprawdza argumenty, pilnuje limitów, składa właściwe wywołania API i tłumaczy odpowiedź na dane, których model może użyć. Klucz API zostaje po stronie serwera. Nie jest argumentem narzędzia, nie trafia do rozmowy i nie wraca w odpowiedzi. Model nigdy nie widzi poświadczeń i nigdy nie rozmawia z Livespace bezpośrednio. O uprawnieniach decyduje Livespace. Klucz należy do konkretnego użytkownika CRM, więc agent widzi dokładnie to, co ten użytkownik, i nie zrobi nic ponad to. Transport to stateless Streamable HTTP ze specyfikacji MCP 2026-07-28. Domyślnie proces słucha na `127.0.0.1:3020`, czyli wyłącznie lokalnie. ### 4. 11 narzędzi zamiast odwzorowania API Każde narzędzie nosi nazwę zadania, które agent ma wykonać. Metody API Livespace zostają pod spodem. Sześć narzędzi czyta: sprawdzenie serwera, słowniki CRM (procesy, etapy, użytkownicy, grupy, źródła, produkty), wyszukiwanie osób, firm i szans, odczyt rekordów, odczyt aktywności oraz analizy lejka. Pięć zmienia dane: tworzenie i aktualizacja rekordów, dopisywanie notatek i rozmów telefonicznych, przesuwanie szans przez proces i powiadomienia w Livespace. Limity są twarde, bo egzekwuje je kod serwera. `get_records` bierze najwyżej 25 identyfikatorów, `create_records` i `update_records` po 10 pozycji, `log_activities` 15 aktywności, `notify_user` 5 powiadomień na 10 minut. Odczyty chodzą po ograniczonych oknach i mówią wprost, kiedy wynik został ucięty, żeby agent nie wziął fragmentu za całość. Kolejność pracy też jest wymuszona. Najpierw `crm_metadata`, dopiero potem cokolwiek, co potrzebuje identyfikatora procesu, etapu, użytkownika albo grupy. Żadnego zgadywania ID. ### 5. Jak wygląda bezpieczny zapis Zapis nie dzieje się po pierwszym wywołaniu. Serwer buduje plan i pokazuje go człowiekowi: 1. zwykłe wywołanie albo `dryRun: true` zwraca plan, a w Livespace nic się nie zmienia, 2. klient obsługujący elicitation wyświetla formularz potwierdzenia, którego argument `confirm: true` nie omija, 3. zgoda niesie podpisany `requestState`: jednorazowy, ważny pięć minut, związany z narzędziem, argumentami i podglądem, 4. jeśli rekord zmienił się między podglądem a zgodą, serwer wstrzymuje zapis i pokazuje nowy plan, 5. po zapisie serwer czyta rekord ponownie i porównuje pola, które wysłał. Wynik nie udaje pewności, której nie ma. `verified` znaczy, że kontrolny odczyt się zgadza. `unavailable` znaczy, że zapis się udał, ale sprawdzić go nie było jak. `unknown_outcome` znaczy, że nie wiadomo, czy żądanie doszło, i ponowna próba może zrobić duplikat. `not_attempted` oznacza pozycje, które w ogóle nie wyszły i można je wysłać później. Przesuwanie szans dostało osobne traktowanie, bo ruch wstecz odznacza ukończone kroki i zmienia historyczne znaczenie tych zaznaczeń. Cofnięcie wymaga jawnej listy dozwolonych identyfikatorów. ### 6. Bezpieczeństwo i granice wersji 1 Zabezpieczenia egzekwuje kod serwera, a rozmowa z modelem nie zmienia ich konfiguracji: - poświadczenia czytane z prywatnego pliku `.env`, nigdy z argumentów narzędzia, - nasłuch domyślnie na `127.0.0.1`, a bind poza loopbackiem serwer odrzuca, dopóki nie dostanie tokena o długości co najmniej 32 bajtów, listy dozwolonych hostów i klucza do podpisywania potwierdzeń, - brak operacji usuwania i scalania rekordów, więc model nie wywoła ich przez pomyłkę, - treść z CRM czytana jako dane, nawet gdy wygląda na polecenie, - zero trwałego magazynu: rekordy nie lądują na dysku, a cache słowników żyje w pamięci procesu i wygasa, - sanityzowane błędy i logi, bez odpowiedzi Livespace, stack trace'ów i tokenów, - trzy zależności runtime z dokładnie przypiętymi wersjami, CI z testami, auditem i skanem sekretów. Osobno wypisałem to, czego wersja 1 nie robi: nie zapisuje tagów ani pól dodatkowych, nie edytuje budżetu istniejącej szansy, nie linkuje tworzonych zadań do rekordów. W każdym z tych miejsc brakowało kontrolowanej próby na koncie testowym, a niesprawdzona operacja w narzędziu agenta jest gorsza niż jej brak. ### 7. Publikacja Wersja 0.1.0 leży w trzech miejscach i każde ma inną rolę. Repozytorium na GitHubie trzyma kod, historię, dokumentację i kontakt bezpieczeństwa. Paczka na npm to gotowy artefakt uruchamiany jedną komendą przez `bunx`. Wpis w oficjalnym [MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers/io.github.proAutomator%2Flivespace-crm-mcp/versions/0.1.0) opisuje, gdzie leży paczka, jakiego transportu używa i jakich zmiennych środowiskowych potrzebuje, żeby klienci MCP mogli ją znaleźć. Archiwum pobrane z npm zgadzało się bajt w bajt z audytowanym artefaktem i zawierało tylko sześć dozwolonych plików. Wdrożenie wersji 1 jest jednoosobowe: jedna para poświadczeń Livespace i serwer na komputerze użytkownika. Wersja dla wielu osób wymagałaby OAuth 2.1, magazynu poświadczeń i routingu per użytkownik. Taka przebudowa należy do kolejnej dużej wersji. Kod, zgłoszenia i instrukcja instalacji: [github.com/proAutomator/livespace-crm-mcp](https://github.com/proAutomator/livespace-crm-mcp). ## Kontakt - Bezpłatna konsultacja: https://www.kubamasztalski.pl/kontakt - Cennik pakietów i konsultacji: https://www.kubamasztalski.pl/ceny - O mnie: https://www.kubamasztalski.pl/o-mnie