Nieoficjalny serwer MCP do CRM Livespace

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.

Asystenci AI, których używam na co dzień, poradziliby sobie z większością 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.

Można podać modelowi 80 metod API i liczyć, że sobie poradzi. Nie poradzi sobie, z trzech konkretnych powodów.

API Livespace nie ma sortowania ani agregacji. Pytanie „pokaż moje największe otwarte szanse" wymaga pobrania listy, przefiltrowania jej i posortowania po stronie klienta. Model, który robi to sam, przy większym zbiorze podaje wynik ucięty, nie wiedząc o tym.

Nie ma też operacji „ustaw etap szansy". Etap wynika z najdalszego zaznaczonego kroku procesu, więc przesunięcie szansy to seria zaznaczeń i odznaczeń. Model wymyślający tę sekwencję samodzielnie potrafi cofnąć historię procesu.

Trzeci powód to identyfikatory. Te z API różnią się od widocznych w interfejsie Livespace, więc zgadnięte ID trafia w cudzy rekord.

Osobno stoi problem, którego nie naprawi lepszy prompt. Treść w CRM pisali ludzie z zewnątrz, więc notatka albo e-mail mogą zawierać zdanie udające polecenie dla agenta.

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.

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.

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.

Zabezpieczenia siedzą w kodzie serwera i nie da się ich obejść rozmową:

• 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.

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 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.