Serwer MCP dla firmy: bezpieczne połączenie AI z systemami firmowymi

Serwer MCP to usługa, za pośrednictwem której asystent AI może odczytywać wybrane dane firmowe i uruchamiać ściśle określone działania w Państwa systemach, na przykład w CRM, ERP lub sklepie internetowym. Według oficjalnej dokumentacji Model Context Protocol (MCP) to otwarty standard łączenia aplikacji AI z systemami zewnętrznymi; obsługują go m.in. Claude, ChatGPT, Visual Studio Code i Cursor (dokumentacja MCP).

Dla firmy serwer MCP ma sens wtedy, gdy pracownicy mają korzystać z danych firmowych bezpośrednio w asystencie AI. Jeśli potrzebują Państwo jedynie regularnie przenosić dane między dwoma systemami, MCP nie jest potrzebny. Jedna rzecz jest ważna od samego początku: bezpieczeństwa nie zapewnia sam protokół, lecz to, jakie narzędzia Państwo udostępnią, jak uwierzytelniają Państwo użytkowników i które działania musi zatwierdzić człowiek.

Czym jest serwer MCP i co może udostępnić

Specyfikacja MCP rozróżnia trzy role. Host to aplikacja AI, która nawiązuje połączenie, klient to konektor wewnątrz tej aplikacji, a serwer to usługa dostarczająca kontekst i możliwości. Wymieniają one komunikaty w formacie JSON-RPC 2.0 (specyfikacja MCP).

Serwer może oferować trzy rodzaje funkcji:

Zasoby (resources) – kontekst i dane dla użytkownika lub modelu AI, na przykład cennik albo wewnętrzna procedura.
Prompty (prompts) – gotowe szablony wiadomości i procedur dla użytkowników, na przykład „podsumuj sytuację klienta”.
Narzędzia (tools) – funkcje uruchamiane przez model AI, na przykład wyszukanie zamówienia albo utworzenie projektu oferty.

Najwięcej uwagi wymagają narzędzia. Zgodnie ze specyfikacją model może je sam wykryć i wywołać na podstawie kontekstu i polecenia użytkownika (MCP: narzędzia). Specyfikacja ostrzega też, że narzędzia oznaczają wykonywanie dowolnego kodu, host przed ich wywołaniem musi uzyskać wyraźną zgodę użytkownika, a sam protokół nie jest w stanie wymusić tych zasad (specyfikacja MCP).

Kiedy wybrać serwer MCP, integrację API, a kiedy własną aplikację

Serwer MCP nie zastępuje każdej integracji. O wyborze decyduje to, kto uruchamia proces i jak dokładnie musi on przebiegać.

Sytuacja	Odpowiednie rozwiązanie	Dlaczego
Pracownicy chcą w asystencie AI wyszukiwać dane z kilku systemów i na nich pracować.	Serwer MCP	Z jednej ustandaryzowanej warstwy mogą korzystać różni klienci obsługujący MCP.
Dwa systemy mają regularnie wymieniać dane bez udziału człowieka, na przykład zamówienia ze sklepu do ERP.	Integracja API	Stały, powtarzalny przepływ danych nie potrzebuje modelu językowego, który sam podejmuje decyzje.
Proces ma ustalone kroki, akceptacje i jasną odpowiedzialność, na przykład obsługa reklamacji.	Własna aplikacja lub kontrolowany workflow AI	Statusy, uprawnienia i ślad audytowy pozostają pod kontrolą we własnym interfejsie.
Potrzebują Państwo jednorazowej analizy eksportu danych.	Eksport bez stałego połączenia	Przy zadaniu jednorazowym nie opłaca się serwer, który trzeba zabezpieczać i utrzymywać.

Zgodnie ze specyfikacją narzędzia serwera MCP mogą na przykład wywoływać API lub odpytywać bazy danych (MCP: narzędzia). W przypadku systemów firmowych zalecamy połączenie przez API z osobnymi, ograniczonymi uprawnieniami. Jeśli system nie ma użytecznego API, warto zacząć właśnie od tego: dobra integracja API to podstawa, na której później można zbudować warstwę MCP.

Bezpieczeństwo: czego wymaga specyfikacja, a co trzeba dodać samodzielnie

Serwer lokalny czy zdalny

Zgodnie ze specyfikacją serwer lokalny, z którym klient komunikuje się przez standardowe wejście i wyjście (STDIO), powinien pobierać dane dostępowe ze środowiska. Dla serwerów dostępnych przez HTTP specyfikacja definiuje autoryzację opartą na OAuth 2.1 (MCP: autoryzacja).

Praktyczna rekomendacja: serwer lokalny z kluczem API na laptopie pracownika wystarczy do prac programistycznych lub osobistego testu. Dla zespołu lepszy jest serwer zdalny, w którym każdy użytkownik działa pod własną tożsamością, a dostęp można odebrać centralnie.

Autoryzacja i tokeny

Autoryzacja jest w MCP formalnie opcjonalna, ale przy danych firmowych należy traktować ją jako obowiązkową. Chroniony serwer MCP działa jako serwer zasobów (resource server) w rozumieniu OAuth 2.1. Tokeny wydaje serwer autoryzacji, który może działać razem z serwerem MCP lub osobno (MCP: autoryzacja).

Do założeń projektu powinny trafić przede wszystkim te wymagania specyfikacji:

serwer musi sprawdzić, czy token dostępu został wydany właśnie dla niego, i nie może przyjmować ani przekazywać dalej innych tokenów,
na nieprawidłowy lub wygasły token odpowiada kodem HTTP 401,
token jest przesyłany w nagłówku Authorization, nigdy w parametrach adresu URL,
klient powinien prosić tylko o uprawnienia (scopes), których naprawdę potrzebuje; przy niewystarczających uprawnieniach serwer powinien odpowiedzieć kodem HTTP 403 z błędem insufficient_scope, a klient może poprosić o szerszy dostęp.

Przydatne jest również to, że serwer może zwracać listę narzędzi zależnie od uprawnień wywołującego. Handlowiec może więc widzieć inne narzędzia niż kierownik sprzedaży (MCP: narzędzia).

Narzędzia, dane wejściowe i wyniki

Zgodnie ze specyfikacją serwery muszą walidować wszystkie dane wejściowe narzędzi, kontrolować dostęp, ograniczać częstotliwość wywołań i oczyszczać wyniki. Klientom specyfikacja zaleca potwierdzanie operacji wrażliwych, pokazywanie danych wejściowych przed wysłaniem do serwera, limity czasu oraz logowanie wywołań na potrzeby audytu (MCP: narzędzia).

Zatwierdzenie przez człowieka

Zgodnie ze specyfikacją przy narzędziach zawsze powinien być człowiek, który może odrzucić wywołanie. Protokół nie narzuca jednak konkretnego modelu interakcji z użytkownikiem, więc forma potwierdzenia zależy od klienta (MCP: narzędzia). Działania zapisujące warto więc projektować tak, aby pozostały bezpieczne nawet po pochopnym zatwierdzeniu, na przykład jako projekt, który człowiek finalizuje w systemie źródłowym.

Przykład: handlowiec przygotowuje się do spotkania

Przykład ilustracyjny, a nie rzeczywisty projekt klienta. Firma dystrybucyjna korzysta z CRM i ERP. Przed spotkaniem handlowiec chce napisać do asystenta AI: „Przygotuj mi materiały na jutrzejsze spotkanie z klientem ABC”.

W pilotażu serwer MCP udostępnia cztery wąskie narzędzia:

find_customer – wyszukuje klienta, ale tylko wśród klientów przypisanych do zalogowanego handlowca,
list_recent_orders – zwraca zamówienia z ostatnich 12 miesięcy bez wewnętrznych notatek o marżach,
list_open_invoices – zwraca kwotę, termin płatności i status faktur bez danych bankowych,
create_quote_draft – tworzy w ERP wyłącznie projekt oferty, który do klienta wysyła człowiek.

Pierwsze trzy narzędzia służą tylko do odczytu. Czwarte widzą wyłącznie użytkownicy z uprawnieniem do ofert; przed jego uruchomieniem handlowiec musi w kliencie zatwierdzić wyświetlone dane wejściowe, a serwer zapisuje w logu, kto, kiedy i z jakimi parametrami użył narzędzia. Jeśli asystent AI źle zrozumie polecenie, w najgorszym razie powstanie błędny projekt, a nie wysłana oferta.

Wdrożenie w siedmiu krokach

Kroki zakładają, że system ma API lub inny interfejs, z którym można się bezpiecznie połączyć.

Jedno zadanie na początek. Na przykład przygotowanie do spotkania albo sprawdzenie statusu zamówienia. Zadania „połącz AI ze wszystkim” nie da się przetestować.
Spis danych i działań. Przy każdej danej trzeba zdecydować, czy AI może ją odczytać, a przy każdym działaniu, czy może je uruchomić. Dane osobowe i wrażliwe należy zwracać tylko wtedy, gdy są niezbędne do zadania.
Wąskie narzędzia. Żadnego uniwersalnego narzędzia typu „wykonaj SQL” albo „wywołaj dowolne API”. Każde narzędzie ma precyzyjny schemat wejściowy, limity, a przy wynikach strukturalnych także schemat wyjściowy, z którym odpowiedź serwera musi być zgodna (MCP: narzędzia).
Autoryzacja. Serwer zdalny z tożsamością użytkownika, uprawnieniami według ról i kontrolą, czy token należy właśnie do tego serwera. Do wywołań CRM lub ERP serwer powinien używać osobnych, ograniczonych danych dostępowych.
Zabezpieczenia operacyjne. Walidacja danych wejściowych, limity częstotliwości wywołań, limity czasu, oczyszczanie wyników i log audytowy.
Zatwierdzanie. Narzędzia zapisujące wymagają zatwierdzenia, a w pilotażu nie mogą niczego usuwać ani wysyłać poza firmę.
Pilotaż z małą grupą. Czas trwania i kryteria oceny warto ustalić z góry. Należy monitorować logi, błędy i pytania, na które narzędzia nie wystarczyły, a dopiero potem dodawać kolejne narzędzia lub użytkowników.

Kompromisy, które trzeba przyjąć świadomie

Elastyczność kosztem przewidywalności. Model sam decyduje, które narzędzie wywoła. Przy pytaniach, których nie da się przewidzieć, to zaleta. Przy procesach, które zawsze muszą przebiegać tak samo, to wada i tam potrzebny jest kontrolowany workflow.

Jedna integracja, różni klienci. Dokumentacja MCP podaje, że dzięki szerokiemu wsparciu integrację można zbudować raz i używać jej w różnych aplikacjach (dokumentacja MCP). To, jak konkretny klient wyświetla narzędzia i potwierdzenia, trzeba jednak sprawdzić dla każdego klienta, którego chcą Państwo dopuścić.

Protokół się rozwija. Wersje MCP oznacza się datą ostatniej zmiany niezgodnej wstecz; w chwili pisania aktualna jest wersja 2026-07-28. Przestarzałe funkcje pozostają w specyfikacji co najmniej 12 miesięcy, a w trybie przyspieszonego usunięcia co najmniej 90 dni (MCP: wersjonowanie). Należy więc zaplanować regularne utrzymanie serwera.

Dane trafiają do modelu AI. Wyniki narzędzi przetwarza model, z którego korzysta klient. Przed uruchomieniem warto sprawdzić warunki przetwarzania danych u dostawcy klienta i zwracać tylko dane, których zadanie naprawdę wymaga.

Częste błędy

Uniwersalne narzędzie z kluczem administratora, które pozwala modelowi niemal na wszystko.
Jedno wspólne konto serwisowe dla wszystkich, przez co brakuje zarówno osobistych uprawnień, jak i śladu audytowego.
Akceptowanie dowolnego tokenu z firmowego logowania bez sprawdzenia, czy został wydany dla tego serwera.
Tokeny w adresach URL lub w logach.
Automatyczne zatwierdzanie narzędzi zapisujących bez kontroli człowieka.
Pełne rekordy z danymi osobowymi tam, gdzie wystarczy podsumowanie.
Podłączenie serwera MCP innej firmy bez weryfikacji. Opisy działania narzędzi pochodzące z niezaufanych serwerów należy traktować jako niezaufane (specyfikacja MCP).

Lista kontrolna przed uruchomieniem

Zanim udostępnią Państwo serwer pierwszym użytkownikom, powinni Państwo móc potwierdzić każdy z poniższych punktów:

Mamy jedno konkretne zadanie i wiemy, jak ocenimy pilotaż.
Każde narzędzie ma właściciela, opis, schemat wejściowy i limity.
Odczyt i zapis są w osobnych narzędziach; usuwania i wysyłania poza firmę nie ma w pilotażu.
Serwer weryfikuje tożsamość użytkownika oraz to, że token został wydany dla niego.
Lista narzędzi i zwracane dane odpowiadają roli użytkownika.
Narzędzia zapisujące wymagają zatwierdzenia i tworzą wyłącznie projekty.
Wywołania są logowane, mają limit czasu i ograniczoną częstotliwość.
Potrafimy szybko odebrać dostęp pojedynczemu użytkownikowi i całemu klientowi.
Znamy warunki przetwarzania danych u dostawcy klienta AI.
Wiemy, kto aktualizuje serwer po wydaniu nowej wersji protokołu.

Najczęstsze pytania

Czy potrzebujemy serwera MCP, jeśli mamy już API?

Tylko wtedy, gdy chcą Państwo pracować z danymi z poziomu asystenta AI. API pozostaje podstawą, a serwer MCP tworzy nad nim warstwę narzędzi z opisami, schematami i uprawnieniami, z którą klient AI potrafi pracować. Jeśli asystent AI nie jest potrzebny, wystarczy samo API.

Czy AI może przez serwer MCP coś usunąć lub wysłać bez naszej wiedzy?

Tylko jeśli udostępnią Państwo takie narzędzie, a klient pozwoli na jego uruchomienie. Specyfikacja zaleca, aby człowiek zawsze mógł odrzucić wywołanie narzędzia. Najbezpieczniej jest w ogóle nie oferować w pilotażu narzędzi do usuwania i wysyłania.

Lepszy jest serwer MCP lokalny czy zdalny?

Serwer lokalny sprawdza się przy pracach programistycznych i do użytku osobistego, ponieważ dane dostępowe pobiera ze środowiska komputera. Dla zespołu lepszy jest serwer zdalny z autoryzacją przez OAuth 2.1, osobistymi uprawnieniami i możliwością centralnego odebrania dostępu.

Czy serwer MCP będzie działał z dowolnym asystentem AI?

Tylko z klientami obsługującymi MCP; dokumentacja wymienia wśród nich na przykład Claude, ChatGPT, Visual Studio Code i Cursor. Protokół nie określa sposobu wyświetlania narzędzi i potwierdzeń, dlatego wybrany klient powinien zostać objęty pilotażem.

Następny krok

Jeśli rozważają Państwo udostępnienie CRM, ERP lub sklepu internetowego asystentom AI, warto zacząć od jednego zadania i kilku narzędzi tylko do odczytu. W zaprojektowaniu narzędzi, autoryzacji i pilotażu pomożemy w ramach usługi agenci AI na zamówienie. Prosimy o kontakt przez stronę kontaktową z opisem systemu i zadania, które chcą Państwo uprościć. Więcej praktycznych poradników znajdą Państwo na blogu Webiant.

Źródła

What is the Model Context Protocol (MCP)? – wprowadzenie w oficjalnej dokumentacji MCP
Specification (2026-07-28) – role, funkcje serwera i zasady bezpieczeństwa
Tools – narzędzia, nadzór człowieka i wymagania bezpieczeństwa
Authorization – autoryzacja serwerów MCP dostępnych przez HTTP
Versioning – oznaczanie wersji i cykl życia funkcji