Artykuł · MCP w firmie

Czym jest MCP i kiedy firma go nie potrzebuje

MCP to otwarty protokół łączący aplikacje AI z narzędziami i danymi. Firma z jednym asystentem i dwoma API zwykle go nie potrzebuje. Opłaca się przy wielu aplikacjach i wielu systemach.

Dla: CTO, architekci, szefowie IT i bezpieczeństwa · Stan na 02.11.2026 · Autor: Karol Krawczyk

Jak działa protokół MCP?

Model Context Protocol opisuje, jak aplikacja z modelem językowym rozmawia z zewnętrznym programem, który udostępnia dane i funkcje. Specyfikacja rozróżnia trzy role. Host to aplikacja, na przykład Claude Desktop albo agent w IDE. Klient to łącznik wewnątrz hosta, zawsze przypisany do jednego serwera. Serwer wystawia możliwości systemu, z którym chcesz się połączyć: repozytorium, bazy, CRM-u. Host może uruchomić wielu klientów, więc jeden asystent korzysta jednocześnie z wielu serwerów, a pełna historia rozmowy zostaje po stronie hosta.

Wiadomości mają format JSON-RPC 2.0. Serwer może oferować narzędzia (funkcje, które model wywołuje), zasoby (dane do kontekstu) i prompty (szablony dla użytkownika). Działania w systemach wykonują narzędzia. Specyfikacja nazywa je sterowanymi przez model: model sam je wykrywa i wybiera na podstawie kontekstu i polecenia użytkownika, a wobec tego opis narzędzia działa jak instrukcja dla modelu.

Specyfikacja definiuje dwa standardowe transporty, a każdy ma inne skutki dla firmy. Przy stdio klient uruchamia serwer jako podproces na komputerze użytkownika. Streamable HTTP to samodzielna usługa z jednym adresem, zwykle zdalna. Pierwszy wariant oznacza cudzy kod działający z uprawnieniami pracownika, drugi przypomina integrację SaaS. Przegląd bezpieczeństwa każdego z nich zadaje inne pytania.

Czym MCP różni się od zwykłego wywoływania funkcji?

Zwykłe wywoływanie funkcji różni się od MCP miejscem, w którym żyje narzędzie: API modeli od dawna pozwala zdefiniować je bezpośrednio w aplikacji. W dokumentacji Anthropic wygląda to tak: model zwraca ustrukturyzowane wywołanie, a kod aplikacji je wykonuje i odsyła wynik. Narzędzie żyje wtedy w twoim kodzie i działa tylko w tej aplikacji.

MCP przenosi narzędzie poza aplikację. Ten sam serwer obsłuży asystenta w IDE, aplikację desktopową i agenta w potoku CI, o ile każdy z nich ma klienta MCP. Przykład hipotetyczny, bez danych z żadnej firmy: pięć aplikacji i osiem systemów to bez wspólnego protokołu nawet 40 połączeń do napisania i utrzymania, a z protokołem osiem serwerów i pięciu klientów, których część dostajesz gotowych w produktach. Opłacalność MCP zależy od takiego rachunku zrobionego dla konkretnej firmy.

Aktualna wersja specyfikacji MCP w listopadzie 2026

Aktualna rewizja MCP nosi datę 2026-07-28 i jest poważną przebudową: usunęła handshake initialize oraz sesje protokołu, więc każde żądanie niesie własną wersję i możliwości klienta. Serwer da się teraz postawić za zwykłym load balancerem, ale twórcy opierający się na identyfikatorach sesji muszą przepisać ten fragment. Roots, Sampling i Logging są oznaczone jako wycofywane, a najwcześniejsze usunięcie przypada na pierwszą rewizję wydaną 2027-07-28 lub później.

W dniu wydania rewizję obsługiwały SDK dla TypeScriptu, Pythona, Go i C#, a Rust miał ją w wersji beta. Klienty i serwery aktualizują się jednak we własnym tempie. Specyfikacja opisuje współpracę ze starszymi wersjami, więc w jednej firmie mogą działać różne rewizje, a pytanie o obsługiwaną wersję trzeba zadawać przy każdym zakupie.

W grudniu 2025 Anthropic przekazał MCP do Agentic AI Foundation działającej przy Linux Foundation, więc standardu nie kontroluje już formalnie jeden dostawca modeli. Anthropic podawał 9 grudnia 2025 ponad 10 tysięcy aktywnych publicznych serwerów i ponad 97 milionów miesięcznych pobrań SDK dla Pythona i TypeScriptu. To liczby własne, bez opublikowanej metody, i nie mówią nic o jakości serwerów. Oficjalny rejestr serwerów nadal ma status preview, a jego regulamin każe zakładać minimalną moderację albo jej brak.

Koszty MCP, które pojawiają się po wdrożeniu

Pierwszy koszt MCP po wdrożeniu to kontekst modelu, czyli tokeny zużywane na definicje narzędzi i wyniki pośrednie. Anthropic w tekście inżynierskim z listopada 2025 pisze, że większość klientów ładuje definicje wszystkich narzędzi od razu, a wyniki pośrednie przechodzą przez model. Przykład z tego tekstu: transkrypcja dwugodzinnego spotkania sprzedażowego może dać 50 tysięcy dodatkowych tokenów. To przykład bez pomiaru, a Anthropic jest tu stroną, bo proponuje własne obejście przez wykonywanie kodu. Sam mechanizm łatwo jednak sprawdzić u siebie, licząc tokeny w logach kilku typowych zadań przed podłączeniem serwera i po nim.

Drugi koszt to utrzymanie. Między rewizjami 2025-11-25 i 2026-07-28 minęło osiem miesięcy, a zmieniło się działanie transportu HTTP. Własny serwer to komponent, który ktoś musi aktualizować, przeglądać i wyłączać, gdy przestaje być potrzebny. Trzeci koszt to bezpieczeństwo, które specyfikacja zostawia wdrażającym. Tekst standardu mówi wprost, że MCP nie może wymusić swoich zasad bezpieczeństwa na poziomie protokołu, a autoryzacja jest opcjonalna. Host ma pytać użytkownika o zgodę na wywołanie narzędzia, opis narzędzia z niezaufanego serwera nie jest wiarygodny, a samo narzędzie trzeba traktować jak wykonanie dowolnego kodu.

Kiedy MCP się opłaca w firmie

Najsilniejszy argument za MCP, według oceny tego tekstu, to kilka aplikacji AI w firmie, które mają sięgać do tych samych systemów. Przykład hipotetyczny: programiści pracują w dwóch narzędziach, dział wsparcia ma własnego asystenta, a w tle działają agenci. Wspólny serwer daje jedno miejsce na uprawnienia i logi tego dostępu.

Drugi przypadek jest prostszy: kupione narzędzie obsługuje rozszerzenia tylko przez MCP, a dostawca systemu ma własny, utrzymywany serwer zdalny. Podłączenie oficjalnego serwera może być wtedy tańsze niż własna integracja. Trzeci to wystawienie własnego produktu klientom, którzy pracują z różnymi asystentami: serwer MCP jest wówczas kolejnym interfejsem produktu obok API.

Własnego serwera nie zawsze trzeba pisać. Azure API Management wystawia REST API jako serwer MCP, zamieniając operacje na narzędzia, a Amazon Bedrock AgentCore Gateway robi to ze specyfikacji OpenAPI. Mechaniczne przełożenie dużego API może dać dziesiątki lub setki narzędzi, a każda definicja zajmuje kontekst modelu. Wystaw kilka operacji odpowiadających zadaniom użytkowników, a resztę zostaw poza zasięgiem agenta.

Kiedy firma nie potrzebuje MCP?

Firma nie potrzebuje MCP, gdy nowy komponent dokłada pracy, a korzyść z wielu klientów się nie pojawia. Lista poniżej to propozycja tego tekstu, nie wynik badania.

Jedna własna aplikacja, jeden dostawca modelu, kilka funkcji. Narzędzia zdefiniowane w kodzie wystarczą i nie dokładają osobnego procesu do wdrożenia, monitorowania i autoryzacji.
Integracja bez decyzji modelu. Przykład ilustracyjny: nocny eksport z ERP do hurtowni ma znane wejście i wyjście, więc wystarczy ETL albo zwykłe wywołanie API.
Zadania na dużych wolumenach danych, gdzie każdy wynik pośredni przechodziłby przez model. Przetwórz dane poza modelem i podaj mu wynik.
Brak właściciela. Jeśli nikt nie odpowie za aktualizacje, przegląd uprawnień i wyłączenie serwera, odłóż wdrożenie.
Dane, do których agent nie powinien mieć dostępu bez nadzoru, gdy nie ma jeszcze procesu zatwierdzania wywołań.

Co zrobić w firmie

Spisz aplikacje AI i systemy, które mają się łączyć, i policz połączenia z MCP oraz bez niego
Dla każdej integracji rozstrzygnij: narzędzie w kodzie aplikacji, oficjalny serwer dostawcy albo własny serwer
Wyznacz właściciela każdego serwera, zanim trafi do użytku
Zmierz tokeny na kilku typowych zadaniach przed podłączeniem serwera i po nim
Sprawdź, jak wybrany klient pyta o zgodę na wywołania i czy administrator może to narzucić

Powiązane materiały

Źródła

Chcesz przełożyć to na swój zespół?

Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.

Umów rozmowę Oferta dla firm

Więcej: MCP w firmie

← Wszystkie artykuły