Asystent AI, który potrafi napisać ofertę, nie musi jeszcze wiedzieć, czy klient ma aktywną umowę i które produkty są dostępne. Te informacje są w CRM, ERP lub systemie magazynowym. MCP pomaga udostępnić je aplikacji AI przez opisane interfejsy. Najważniejszą decyzją wdrożeniową pozostaje jednak to, co asystent może odczytać, co może zmienić i kto zatwierdza wynik.
Czym jest MCP i do czego przydaje się w firmie?
Model Context Protocol to otwarty protokół komunikacji między aplikacjami AI a serwerami udostępniającymi dane i funkcje. Aplikacja pełni rolę hosta, a jej klient MCP łączy się z odpowiednim serwerem. Serwer może udostępniać narzędzia do wykonania określonej operacji, zasoby do odczytu oraz szablony pracy z modelem.
MCP porządkuje sposób komunikacji; nie zastępuje reguł biznesowych CRM ani nie nadaje automatycznie dostępu do wszystkich danych. Dokumentacja źródłowa.
Co zmieniło się w MCP w lipcu 2026?
Wydanie specyfikacji z 28 lipca 2026 wprowadziło bezstanowy rdzeń protokołu, zmiany routingu żądań, buforowanie list oraz zaostrzenie zasad autoryzacji. Dla zespołu wdrażającego integrację oznacza to konieczność sprawdzenia zgodności klienta, serwera i SDK. Nie warto zakładać, że przykład przygotowany dla starszej wersji zadziała bez zmian.
Przed rozpoczęciem projektu zapisz obsługiwane wersje protokołu i zaplanuj test aktualizacji na środowisku testowym. Dokumentacja źródłowa.
MCP czy zwykła integracja API?
Jeśli po opłaceniu zamówienia system ma zawsze wystawić dokument i przekazać dane do magazynu, zwykła integracja API z kolejką zdarzeń może być prostsza. Proces ma z góry określony przebieg. MCP warto rozważyć wtedy, gdy użytkownik zadaje różne pytania, a asystent musi wybrać właściwe źródła lub operacje w kilku systemach.
Oba rozwiązania mogą współistnieć. Serwer MCP może korzystać z istniejącego API, zamiast otrzymywać bezpośredni dostęp do bazy danych. Wtedy system źródłowy nadal odpowiada za walidację zamówień, uprawnienia i spójność zapisów. Zespół nie musi odtwarzać tych reguł w instrukcjach dla modelu.
Przykład: przygotowanie oferty z danych CRM i ERP
Załóżmy, że handlowiec prosi o projekt oferty dla wskazanego klienta. To przykład projektowy, a nie opis wdrożenia z deklarowanymi wynikami sprzedaży. Bezpieczny zakres pierwszej wersji można ograniczyć do następujących kroków:
- CRM zwraca dane wybranego klienta i historię kontaktu, do której handlowiec ma uprawnienia.
- ERP udostępnia aktualny cennik oraz dostępność wskazanych produktów. Każdy wynik ma czas pobrania.
- Asystent tworzy szkic z odnośnikami do danych źródłowych i oznacza brakujące informacje.
- Handlowiec sprawdza pozycje, rabat i warunki. Zapis lub wysyłka następują dopiero po zatwierdzeniu konkretnego dokumentu.
Samo zdanie „nie wysyłaj bez zgody” w instrukcji asystenta nie powinno być jedyną kontrolą. Rozdziel narzędzie tworzące szkic od narzędzia wysyłającego. To drugie powinno wymagać zatwierdzenia powiązanego z treścią dokumentu; zmiana kwoty lub odbiorcy po akceptacji powinna unieważniać zgodę.
Jak zaprojektować uprawnienia i ochronę danych?
Dla zdalnego MCP korzystającego z HTTP specyfikacja opisuje mechanizmy autoryzacji oparte na OAuth. Wymaga też właściwej walidacji tokenów i ich przeznaczenia. Token przeznaczony dla innej usługi nie powinien być po prostu przekazywany dalej jako uniwersalny klucz dostępu.
Szczegóły autoryzacji trzeba dopasować do wersji protokołu i sposobu udostępnienia serwera. Dokumentacja źródłowa.
W projekcie biznesowym proponujemy osobno sprawdzić sześć granic działania. Są to zalecenia projektowe, które należy dostosować do ryzyka procesu:
- Tożsamość: każda operacja ma przypisanego użytkownika lub jasno określone konto techniczne.
- Zakres danych: serwer sprawdza dostęp do konkretnej firmy, rekordu i pola, a nie tylko fakt zalogowania.
- Zapis: operacje zmieniające dane mają osobne uprawnienia i walidację po stronie systemu źródłowego.
- Powtórzenia: ponowienie żądania nie może tworzyć drugiej oferty lub drugiego zamówienia.
- Treści zewnętrzne: tekst wiadomości lub dokumentu jest danymi, a nie poleceniem nadania sobie większych uprawnień.
- Ślad operacji: zapisuj identyfikator działania, wynik i czas, ograniczając ilość danych osobowych w logach.
Co przetestować, zanim asystent trafi do zespołu?
Test „udało się przygotować ofertę” jest niewystarczający. Sprawdź klienta o podobnej nazwie, brak dostępu do rekordu, niedostępny ERP, nieaktualną cenę, cofniętą zgodę i próbę ponownego wysłania tego samego dokumentu. Asystent powinien jasno powiedzieć, czego nie udało się potwierdzić, zamiast uzupełniać luki prawdopodobną odpowiedzią.
W pilotażu mierz czas wykonania zadania, odsetek wyników wymagających poprawy, liczbę odrzuconych operacji i koszt jednego poprawnie zakończonego procesu. Uwzględnij pracę człowieka przy sprawdzaniu wyników. Sam krótki czas generowania odpowiedzi nie oznacza oszczędności całego zespołu.
Od czego zacząć integrację MCP w firmie?
Wybierz jeden częsty proces, wskaż właściciela danych i zacznij od odczytu oraz szkiców. Dopiero po ocenie jakości dodawaj operacje zapisu. Przy wycenie uwzględnij stan API, model uprawnień, środowisko testowe, obsługę błędów i utrzymanie integracji po zmianach protokołu. Gotowy serwer MCP może skrócić start, ale nie zastąpi sprawdzenia tych elementów.
Najczęściej zadawane pytania
Czy MCP zastępuje API systemu CRM?
Nie. Serwer MCP może korzystać z istniejącego API i udostępniać wybrane operacje aplikacji AI. Reguły biznesowe oraz kontrola dostępu nadal powinny być egzekwowane przez system źródłowy.
Czy agent MCP musi mieć możliwość zapisu danych?
Nie. Pierwszy etap może obejmować wyłącznie odczyt danych i przygotowanie szkiców. Zapis warto udostępniać oddzielnie, po testach oraz określeniu zasad zatwierdzania zmian.
Od czego zależy koszt integracji MCP?
Od liczby i jakości API, zakresu narzędzi, modelu uprawnień, wymaganych testów oraz utrzymania. Wycena powinna dotyczyć konkretnego procesu i uwzględniać obsługę wyjątków, a nie tylko podłączenie serwera.