Szybka odpowiedź
Serwer MCP to program, który przez otwarty standard Model Context Protocol udostępnia asystentom i agentom AI dane oraz narzędzia: na przykład wyszukiwanie w dokumentach, odczyt zgłoszeń albo założenie zadania w systemie. Dzięki temu jedno połączenie z CRM czy bazą wiedzy działa w wielu aplikacjach AI, zamiast osobnej integracji dla każdej. Potrzebują go przede wszystkim firmy, które chcą, żeby AI pracowało na ich realnych systemach, a nie tylko na wiedzy ogólnej modelu.
Czym jest MCP (Model Context Protocol)?
MCP to otwarty protokół, który standaryzuje sposób, w jaki aplikacje oparte na modelach językowych łączą się z zewnętrznymi źródłami danych i narzędziami. Twórcy porównują go do portu USB-C: jeden standard złącza zamiast osobnej ładowarki do każdego urządzenia (dokumentacja MCP).
Anthropic opublikował MCP jako projekt open source 25 listopada 2024 r. (Anthropic, 2024). Rok później, 9 grudnia 2025 r., przekazał protokół do Agentic AI Foundation, funduszu działającego w ramach Linux Foundation, współzałożonego przez Anthropic, Block i OpenAI. W tym samym ogłoszeniu podano, że działa ponad 10 000 aktywnych publicznych serwerów MCP, a SDK dla Pythona i TypeScriptu notują ponad 97 mln pobrań miesięcznie (Anthropic, 2025).
Przed MCP każda aplikacja AI potrzebowała własnego konektora do każdego systemu. Przy trzech asystentach i pięciu systemach to piętnaście integracji do utrzymania. Z MCP każdy system wystawia jeden serwer, a każda aplikacja AI ma jednego klienta, który rozmawia z dowolnym serwerem.
Jak działa serwer MCP?
Serwer MCP opisuje, co potrafi, a aplikacja AI pyta o tę listę i przekazuje ją modelowi, który sam decyduje, czego użyć. Specyfikacja wyróżnia trzy role (specyfikacja MCP):
- Host: aplikacja AI, z której korzysta człowiek, na przykład Claude, ChatGPT, edytor kodu albo Twój własny agent.
- Klient MCP: komponent wewnątrz hosta. Host tworzy jednego klienta na każdy serwer, z którym się łączy.
- Serwer MCP: program udostępniający kontekst i możliwości konkretnego systemu.
Serwer może oferować trzy rodzaje rzeczy, tzw. prymitywy (architektura MCP):
| Prymityw | Co to jest | Kto o nim decyduje | Przykład w firmie |
|---|---|---|---|
| Narzędzia (tools) | Funkcje, które model może wywołać, żeby wykonać akcję | Model, za zgodą użytkownika | Wyszukaj w dokumentach, załóż zgłoszenie, pobierz status zamówienia |
| Zasoby (resources) | Dane dostarczane jako kontekst | Aplikacja lub użytkownik | Schemat bazy danych, treść umowy, regulamin |
| Prompty (prompts) | Gotowe szablony interakcji | Użytkownik | "Przygotuj tygodniowy raport sprzedaży" |
Komunikacja odbywa się komunikatami JSON-RPC 2.0. Typowy przebieg: klient pobiera listę narzędzi (tools/list), model wybiera narzędzie i argumenty, klient wywołuje je (tools/call), a wynik wraca do modelu jako kontekst kolejnego kroku.
W aktualnej wersji specyfikacji (2026-07-28) protokół stał się bezstanowy: każde żądanie niesie wersję protokołu i możliwości klienta, a serwer ogłasza swoje możliwości przez obowiązkowe wywołanie server/discover. Funkcje Sampling, Roots i Logging oznaczono jako przestarzałe, a długie operacje obsługuje opcjonalne rozszerzenie Tasks (zmiany w specyfikacji 2026-07-28). Dla firmy oznacza to prostsze skalowanie zdalnych serwerów za zwykłym load balancerem.
Serwer lokalny czy zdalny: co wybrać?
Serwer lokalny działa na komputerze użytkownika i rozmawia z aplikacją przez standardowe wejście i wyjście (transport stdio). Serwer zdalny działa na serwerze i przyjmuje żądania HTTP (transport Streamable HTTP). Starszy transport HTTP+SSE jest przestarzały (transporty MCP).
| Cecha | Serwer lokalny (stdio) | Serwer zdalny (Streamable HTTP) |
|---|---|---|
| Gdzie działa | Na komputerze użytkownika, uruchamiany przez aplikację | Na serwerze dostawcy lub w Twojej infrastrukturze |
| Ilu użytkowników | Zwykle jeden klient | Wielu klientów jednocześnie |
| Uwierzytelnianie | Uprawnienia lokalnego użytkownika | Tokeny, zalecany OAuth |
| Dobre zastosowanie | Pliki na dysku, lokalne repozytorium, narzędzia programisty | Systemy firmowe: CRM, ERP, baza dokumentów, helpdesk |
| Główne ryzyko | Kod uruchamiany z uprawnieniami użytkownika | Wyciek tokenów, zbyt szerokie uprawnienia |
Oryginalne opisy MCP często podkreślają, że "wszystko działa lokalnie". To uproszczenie. Nawet gdy serwer jest lokalny, wyniki narzędzi trafiają do modelu językowego, a ten zwykle działa w chmurze dostawcy. Jeśli dane osobowe w rozumieniu RODO albo tajemnica przedsiębiorstwa nie mogą opuścić firmy, lokalny musi być cały łańcuch: serwer MCP, agent i model. Jak wygląda AI na własnej infrastrukturze, pokazujemy na stronie Infrastruktura AI.
Kto potrzebuje serwera MCP?
Serwera MCP potrzebuje każda organizacja, która chce, żeby AI pracowało na jej systemach w więcej niż jednej aplikacji albo w agentach wykonujących zadania. W praktyce to trzy grupy.
Firmy z systemami wewnętrznymi. ERP, system zgłoszeń, baza produktów, dokumentacja techniczna. Jeden serwer MCP nad takim systemem sprawia, że korzysta z niego asystent w czacie, agent w tle i narzędzie programisty, bez trzech osobnych integracji.
Zespoły budujące agentów AI. Agent to model, który w pętli wybiera narzędzia i wykonuje kolejne kroki (więcej w artykule czym jest agentic AI). MCP daje mu standardowy sposób odkrywania i wywoływania tych narzędzi, a Tobie możliwość wymiany modelu bez przepisywania integracji.
Dostawcy oprogramowania. Producent SaaS, który wystawi serwer MCP, sprawia, że jego produkt jest dostępny z poziomu ChatGPT, Claude, Gemini czy Copilota, które według Anthropic obsługują już protokół (Anthropic, 2025).
Przykład z codziennej pracy: lider zespołu pyta, co zostało zrobione w zeszłym tygodniu. Bez integracji ktoś otwiera repozytorium, system zadań, komunikator i kalendarz, a potem skleja to z pamięci. Z serwerami MCP dla tych systemów asystent zbiera zamknięte zadania, scalone zmiany w kodzie i ustalenia ze spotkań, a człowiek dostaje szkic podsumowania do sprawdzenia.
Kiedy MCP to przesada?
Gdy masz jedną aplikację AI i jedno, stabilne połączenie z jednym systemem. Wtedy zwykłe wywołanie API w kodzie agenta jest prostsze w utrzymaniu niż osobny serwer. MCP zaczyna się zwracać, gdy rośnie liczba aplikacji, agentów albo systemów, które trzeba ze sobą połączyć.
Jak używamy MCP w naszych agentach?
W naszych agentach AI narzędzia agentów w standardzie MCP są częścią wspólnego rdzenia agent-core, na którym budujemy helpdesk, asystenta operacyjnego, agenta outreachowego i pentestera. Z tej pracy wynikają trzy zasady, które stosujemy przy każdym serwerze:
- Wąska allowlista narzędzi. Każdy agent ma tylko te narzędzia, których potrzebuje do swojej roli. Helpdesk nie ma dostępu do narzędzi pentestera.
- Zgoda człowieka na wrażliwe akcje. Reset MFA w helpdesku wykonuje się dopiero po kliknięciu "Zatwierdź", a wiadomość outreachowa nie wychodzi bez akceptacji.
- Dziennik audytu i lokalne modele. Każdy krok trafia do dziennika, do którego można tylko dopisywać, a model działa na naszych GPU, więc dane nie wychodzą na zewnątrz.
Jakie ryzyka niesie MCP i jak je ograniczyć?
Narzędzie MCP to wykonywanie kodu w Twoich systemach, więc ryzyka są takie jak przy każdym dostępie programowym, plus te specyficzne dla modeli językowych. Specyfikacja wprost wymaga, by host uzyskał wyraźną zgodę użytkownika przed wywołaniem narzędzia, i zaznacza, że opisy narzędzi z niezaufanego serwera należy traktować jako niezaufane (specyfikacja MCP).
Najważniejsze zagrożenia według dobrych praktyk bezpieczeństwa MCP:
- Zbyt szerokie uprawnienia. Token z zakresem "wszystko" po wycieku daje dostęp do wszystkiego. Zalecany jest model minimalnych uprawnień, rozszerzanych dopiero przy konkretnej akcji.
- Przekazywanie tokenów dalej (token passthrough). Serwer nie może przyjmować tokenów wystawionych dla innej usługi i przekazywać ich do kolejnych API.
- Niezaufane serwery lokalne. Konfiguracja "jednym kliknięciem" może uruchomić dowolne polecenie z uprawnieniami użytkownika. Klient musi pokazać pełne polecenie i poprosić o zgodę.
- Wstrzyknięcie poleceń. Agent czyta e-maile, zgłoszenia i strony WWW, a w nich mogą być ukryte instrukcje. Potrzebny jest strażnik na wejściu i zgoda człowieka na akcje nieodwracalne.
Szczegółowo omawiamy to w artykule o bezpieczeństwie agentów AI i serwerów MCP.
Od czego zacząć z MCP w firmie?
Od jednego procesu i jednego systemu, nie od podłączenia wszystkiego naraz.
- Wybierz zadanie, w którym ludzie dziś ręcznie zbierają informacje z kilku miejsc (status zamówień, raport tygodniowy, odpowiedzi na pytania klientów).
- Sprawdź, czy istnieje gotowy serwer dla danego systemu, najlepiej od samego dostawcy. Jeśli nie, zaplanuj własny.
- Zacznij od odczytu. Narzędzia tylko do czytania dają wartość przy małym ryzyku. Akcje zapisu dodawaj później, z zatwierdzaniem przez człowieka.
- Ustal granice danych: które dane mogą trafić do modelu w chmurze, a które wymagają modelu we własnej infrastrukturze.
- Mierz i loguj: które narzędzia agent wywołuje, jak często się myli, ile czasu oszczędza.
MCP nie robi z modelu lepszego modelu. Daje mu za to dostęp do kontekstu, którego wcześniej nie miał, a to właśnie brak kontekstu najczęściej odróżnia efektowną demonstrację od narzędzia, z którego ludzie korzystają na co dzień.
Źródła
- Model Context Protocol: What is MCP?
- Model Context Protocol: Specification (2026-07-28)
- Model Context Protocol: Key changes 2026-07-28
- Model Context Protocol: Architecture overview
- Model Context Protocol: Transports
- Model Context Protocol: Security Best Practices
- Anthropic: Introducing the Model Context Protocol (2024)
- Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (2025)
