Model Context Protocol daje aplikacjom AI wspólny sposób korzystania z narzędzi i danych. Dla firmy oznacza to szansę na udostępnienie jednej integracji kilku asystentom, bez pisania od początku osobnego połączenia dla każdego z nich. MCP może działać nad istniejącym API. Nadal potrzebuje systemu, który sprawdzi uprawnienia, odczyta zamówienie albo zapisze zmianę. Specyfikacja MCP.
W Lazarus Systems oceniamy MCP jako mocnego kandydata na standard integracji aplikacji AI. Przewidujemy jego współistnienie z REST, GraphQL i wewnętrznymi usługami firm. Zakres adopcji pozostaje otwarty: wspólny protokół pomaga podłączyć narzędzie, ale o użyteczności decyduje też jego projekt i obsługa w konkretnym kliencie.
Jak działa MCP
Użytkownik pracuje w aplikacji pełniącej rolę hosta. Jej klient MCP komunikuje się z serwerem udostępniającym funkcje. Serwer może działać na tym samym komputerze albo zdalnie. Dokumentacja opisuje dwa transporty: stdio dla lokalnych procesów oraz Streamable HTTP dla komunikacji przez sieć. Architektura MCP.
Serwer może udostępnić trzy rodzaje elementów: tools, czyli wykonywalne narzędzia; resources, czyli dane do wykorzystania jako kontekst; oraz prompts, czyli szablony interakcji. Narzędziem może być wyszukiwanie zamówienia, zasobem dokumentacja produktu, a szablonem instrukcja przygotowania raportu. Aplikacja sprawdza dostępne narzędzia przez tools/list, a wywołuje wybrane przez tools/call. Narzędzia w MCP.
MCP, API i OpenAPI pełnią różne funkcje
API określa sposób komunikacji z danym systemem. OpenAPI opisuje interfejsy HTTP w formacie, który mogą odczytywać ludzie i programy: ich operacje, parametry i odpowiedzi. Dzięki temu opisowi można m.in. tworzyć dokumentację i klientów API. Specyfikacja OpenAPI.
MCP określa wspólny sposób komunikacji aplikacji AI z dostawcą narzędzi i kontekstu. Serwer MCP może wywoływać istniejące API CRM, bazę danych lub lokalny program. Z punktu widzenia architektury to często dodatkowy interfejs do już działających usług. Nie ma powodu przepisywać całego backendu tylko po to, żeby podłączyć asystenta.
Rozważmy przykładową integrację obsługi zamówień. API sklepu ma kilkadziesiąt operacji. Dla asystenta reklamacyjnego zaprojektowalibyśmy trzy wąskie narzędzia: odczyt statusu, sprawdzenie warunków zwrotu i utworzenie szkicu zgłoszenia. Każde miałoby określone argumenty i wynik. Sam zwrot pieniędzy pozostałby osobną operacją z własną kontrolą dostępu.
Automatyczne wystawienie wszystkich endpointów jako narzędzi przeniosłoby na model wybór spośród wielu podobnych funkcji. W takim projekcie najpierw ustalilibyśmy, jakie zadanie ma wykonać użytkownik, a dopiero potem zakres narzędzi. Liczba dostępnych operacji nie byłaby dla nas miarą jakości integracji.
Co przemawia za wspólnym standardem
9 grudnia 2025 r. Anthropic ogłosił przekazanie MCP do Agentic AI Foundation działającej przy Linux Foundation. Fundację współtworzyli Anthropic, Block i OpenAI, przy wsparciu m.in. Google i Microsoft. W tym samym komunikacie Anthropic wskazał adopcję MCP przez produkty różnych dostawców, w tym Cursor i Visual Studio Code. To udokumentowane wsparcie branży, choć sam komunikat dostawcy nie mierzy jakości wszystkich integracji. Ogłoszenie Anthropic.
Wspólna specyfikacja pozwala projektować serwer dla więcej niż jednego klienta. Zgodność trzeba jednak sprawdzić w praktyce. Aplikacje mogą obsługiwać różne wersje protokołu i zestawy funkcji. Specyfikacja z 28 lipca 2026 r. opisuje też opcjonalne rozszerzenia, takie jak Tasks i MCP Apps; ich dostępności nie należy zakładać w każdym kliencie. Specyfikacja i rozszerzenia MCP.
Uprawnienia pozostają częścią wdrożenia
Serwer narzędzi daje aplikacji możliwość wykonywania operacji na rzeczywistych danych. Autorzy dokumentacji bezpieczeństwa MCP opisują m.in. ryzyka przejmowania uprawnień przez pośrednika, niewłaściwego przekazywania tokenów i uruchamiania niezaufanych lokalnych serwerów. Protokół wymaga poprawnej implementacji kontroli dostępu. Zalecenia bezpieczeństwa MCP.
W przykładzie ze sklepem testowalibyśmy próbę odczytania cudzego zamówienia, niepoprawny identyfikator i ponowienie tego samego żądania. Sprawdzilibyśmy też, czy treść pobrana z notatki klienta nie skłania modelu do wykonania dodatkowej operacji. Błędne polecenie powinien odrzucić system egzekwujący uprawnienia, nawet gdy model zdecyduje się je wysłać.
Dla operacji zapisujących dane określilibyśmy, które wymagają zatwierdzenia użytkownika, jak zapobiegać duplikatom i co zapisać w dzienniku zdarzeń. Dopiero taki zestaw zasad pozwala ocenić, czy integracja nadaje się do pracy na danych firmy.
MCP z lokalnym modelem
Aplikacja korzystająca z lokalnego modelu może również mieć klienta MCP. Sam protokół nie określa sposobu uruchamiania modelu ani zarządzania jego kontekstem. Lokalny serwer i lokalny model to odrębne decyzje architektoniczne. Zakres MCP.
W projekcie z modelem z rodziny Qwen sprawdzilibyśmy osobno wybór narzędzia, poprawność argumentów i reakcję na odmowę dostępu. Uruchomienie modelu na własnym sprzęcie nie gwarantuje, że cała aplikacja działa bez zewnętrznych połączeń. Trzeba uwzględnić serwery narzędzi, telemetrię i usługi używane przez hosta. O doborze samego modelu piszemy w analizie Qwen do pracy lokalnej.
Komentarz Lazarus Systems: gdzie zacząć
MCP ma dla nas największy sens tam, gdzie z tych samych funkcji mają korzystać różne aplikacje AI albo kilka zespołów. Dla jednego procesu, który zawsze pobiera ten sam raport z jednego API, bezpośrednia integracja może wymagać mniej pracy i utrzymania.
Pilotaż zaczęlibyśmy od jednego zadania i narzędzi tylko do odczytu. Porównalibyśmy wykonanie zadania przez dwie aplikacje obsługujące MCP: liczbę poprawnych odpowiedzi, opóźnienie, błędne wywołania i pracę potrzebną do podłączenia drugiego klienta. Dopiero ten ostatni pomiar pokazałby, ile w danym projekcie daje wspólny standard.
Przy wyborze dostawcy poprosilibyśmy o demonstrację na własnych danych testowych, listę obsługiwanych wersji protokołu i możliwość eksportu logów wywołań. Te wymagania można wpisać do kryteriów odbioru integracji już dziś.
Stan źródeł: 2 października 2026 r. Przykład sklepu i proponowane testy są rekomendacją redakcyjną Lazarus Systems, a nie opisem przeprowadzonego wdrożenia.