MCP w praktyce: jak połączyć AI z procesem wytwarzania oprogramowania

Wymagania zapisano w Jira lub Redmine, dodatkowe ustalenia zostały w transkrypcji spotkania, projekt interfejsu powstał w Figmie, a kod znajduje się w repozytorium. Zanim deweloper wprowadzi zmianę, musi połączyć te informacje. W zebraniu kontekstu może pomóc agent AI, ale potrzebuje dostępu do narzędzi i danych, z których korzysta zespół.

Takie połączenie umożliwia MCP (Model Context Protocol) — otwarty protokół przedstawiony przez Anthropic w listopadzie 2024 roku. Służy do komunikacji między dużymi modelami językowymi (LLM) a zewnętrznymi narzędziami, usługami i źródłami danych. Jeśli model AI porównamy do mózgu, serwery MCP pełnią rolę jego zmysłów i kończyn: pozwalają mu czytać dokumenty, logi i dane z baz, ale też modyfikować dane, tworzyć zgłoszenia czy uruchamiać procesy.

MCP nie zastępuje API. Serwer MCP zazwyczaj udostępnia istniejące API, bazę danych, system plików lub narzędzie wiersza poleceń (CLI) przez ustrukturyzowany interfejs przygotowany do użycia przez model językowy. Największa wartość nie wynika jednak z podłączenia pojedynczego narzędzia, lecz z bezpiecznego połączenia etapów pracy: od wymagania i projektu, przez implementację, po testy. Agent wspiera ten proces, a zespół zachowuje odpowiedzialność za decyzje.

Jak działa MCP i gdzie kończy się jego rola

Żeby zrozumieć architekturę MCP i miejsce protokołu w procesie, warto rozdzielić kilka elementów. Użytkownik pracuje w aplikacji AI, na przykład w asystencie programistycznym lub środowisku deweloperskim. Aplikacja pełni rolę hosta MCP i zawiera klienta MCP, który odpowiada za połączenie z konkretnym serwerem i przekazywanie wywołań. Serwer udostępnia dane lub operacje, natomiast model językowy analizuje zadanie, wybiera narzędzia i przygotowuje argumenty potrzebne do ich użycia.

MCP wykorzystuje JSON-RPC 2.0 do komunikacji między klientami a serwerami. W zależności od sposobu wdrożenia komunikaty mogą być wymieniane lokalnie przez standardowe wejście i wyjście (stdio) albo zdalnie przez Streamable HTTP.

Przebieg pracy można opisać następująco: użytkownik zleca zadanie, model korzysta z informacji o dostępnych narzędziach, a aplikacja obsługuje ich wywołania. W odpowiednim momencie następuje sprawdzenie uprawnień i, jeśli jest to wymagane, uzyskanie zgody na działanie. Serwer wykonuje operację w systemie docelowym, a wynik wraca do modelu. Może posłużyć do przygotowania odpowiedzi albo stać się punktem wyjścia do następnego kroku.

Ten mechanizm nie zastępuje projektu procesu. Sam dostęp do zgłoszeń, dokumentacji i repozytorium nie określa jeszcze, w jakiej kolejności należy z nich korzystać, jakie informacje są wystarczające i kiedy potrzebna jest decyzja człowieka. Agent może koordynować działania, ale organizacja musi określić ich zakres, ograniczenia i warunki zakończenia. Dlatego punktem wyjścia powinno być zadanie do wykonania, a nie lista serwerów, które da się podłączyć.

Od wymagania do draft pull requestu

Prześledźmy przykładową zmianę w aplikacji, która wymaga modyfikacji interfejsu, logiki backendu i testów. Załóżmy, że potrzebne źródła informacji i operacje zostały udostępnione przez serwery MCP, a agent otrzymuje dostęp odpowiedni do danego etapu pracy. Celem jest przygotowanie sprawdzonej propozycji zmiany, którą zespół będzie mógł ocenić, a nie pominięcie osób odpowiedzialnych za wymagania, architekturę czy jakość.

Najpierw wymagania i wspólne rozumienie problemu

Praca zaczyna się od ustaleń z klientem i zespołem. Product Manager porządkuje informacje, zapisuje je w systemach projektowych i przekazuje do dalszej analizy. Część szczegółów pozostaje jednak w materiałach ze spotkań. Analityk musi połączyć te źródła, sprawdzić wcześniejsze decyzje i przełożyć je na zakres rozwiązania, zadania oraz kryteria akceptacji.

W tym miejscu agent może pomóc w porównaniu zapisów. Odczytuje zgłoszenie, przeszukuje wskazane materiały i sprawdza, czy opis zadania odpowiada temu, co ustalono podczas rozmów. Może wskazać brakujące wymaganie, sprzeczność między źródłami albo pytanie, które trzeba rozstrzygnąć przed rozpoczęciem implementacji. Takie wsparcie służy przede wszystkim wychwytywaniu rozbieżności, które inaczej trafiłyby do kolejnych etapów pracy.

Istotna jest granica odpowiedzialności. Wykrycie sprzeczności nie oznacza, że agent powinien sam wybrać obowiązującą wersję wymagania. Jego zadaniem jest pokazać problem i dostarczyć kontekst osobie podejmującej decyzję. Na tym etapie użytecznym wynikiem może być więc zarówno uporządkowany opis zadania, jak i lista kwestii, które nadal wymagają uzgodnienia.

Projekt i architektura powiązane z wymaganiem

Projektant UI/UX korzysta z tego samego kontekstu, przygotowując widoki, komponenty i zasady interfejsu. Powiązanie projektu w Figmie z zadaniem pozwala później dotrzeć nie tylko do gotowego ekranu, lecz także do stojących za nim ustaleń. Architekt zestawia wymagania i planowane przepływy użytkownika z istniejącymi systemami oraz ograniczeniami technicznymi. Na tej podstawie określa odpowiedzialności komponentów i sposób ich komunikacji.

Agent może wspierać obie role przez porównywanie materiałów. W obszarze interfejsu sprawdza projekt względem istniejącego design systemu i mapuje komponenty wizualne na komponenty kodu. W analizie technicznej pomaga wskazać zależności, ocenić zakres planowanej zmiany oraz porównać dokumentację z implementacją. Może również przygotować propozycję zapisu decyzji architektonicznej lub pomóc w sprawdzeniu kontraktu API.

Wartością takiego podejścia jest możliwość zestawienia informacji, które zwykle trzeba odnajdywać osobno. Pytanie o wpływ zmiany na interfejs może prowadzić do wymagania, projektu, kontraktu i odpowiedniego fragmentu kodu. Ocena proponowanego rozwiązania nadal należy do zespołu, ale może opierać się na pełniejszym obrazie zależności.

Implementacja oparta na kontekście projektu

Deweloper rozpoczyna pracę z wymaganiami, projektem i koncepcją techniczną. Agent odczytuje zgłoszenie oraz komentarze, wyszukuje dokumentację i podobne problemy, a następnie identyfikuje kod wymagający zmiany. Zanim przystąpi do modyfikacji, przedstawia plan do zatwierdzenia. Dopiero po jego akceptacji przechodzi do implementacji i przygotowania testów.

Po stronie frontendu oznacza to możliwość wykorzystania komponentów i reguł z Figmy oraz odnalezienia ich odpowiedników w repozytorium. Gdy widok komunikuje się z backendem, na przykład przez GraphQL, agent może odczytać udostępniony schemat i porównać implementację z kontraktem. Po stronie backendu punktem odniesienia pozostają wymagania, koncepcja architektoniczna, istniejąca logika biznesowa i dokumentacja używanych bibliotek.

Nie chodzi zatem wyłącznie o wygenerowanie fragmentu kodu. Agent może znaleźć właściwe miejsce w projekcie, wykorzystać istniejące wzorce, wykonać kontrolowane polecenie narzędzia projektowego i przygotować zmianę w repozytorium. Jego praca powinna być osadzona w konkretnym zadaniu oraz zasadach danego projektu, zamiast prowadzić do tworzenia rozwiązania w oderwaniu od istniejącej implementacji.

Testy, wyniki kontroli i przegląd zespołu

Przygotowanie kodu nie kończy scenariusza. Kolejnym etapem jest sprawdzenie, czy zmiana spełnia kryteria akceptacji i przechodzi kontrole właściwe dla projektu. Agent może przygotować przypadki testowe, uruchomić testy jednostkowe i integracyjne, a następnie przejść przez scenariusz w przeglądarce. W przypadku interfejsu może również porównać rezultat z projektem oraz zebrać informacje o błędach w konsoli czy komunikacji sieciowej.

Uzupełnieniem są kontrole jakości i bezpieczeństwa: automatyczne sprawdzanie kodu pod kątem potencjalnych błędów i zgodności ze standardami projektu (linting), inne analizy statyczne oraz skanowanie sekretów i zależności. Agent może pogrupować wyniki, wskazać nowe problemy i odróżnić je od istniejącego długu technicznego. Wynikiem tego etapu powinny być nie tylko zmodyfikowane pliki, ale również informacje pozwalające zespołowi ocenić zakres i ryzyko zmiany.

Scenariusz kończy się utworzeniem draft pull requestu, czyli roboczej propozycji zmiany, oraz dodaniem odnośnika w zgłoszeniu. Zadanie pozostaje otwarte do czasu walidacji przez zespół. W ten sposób wymaganie, implementacja i wyniki kontroli pozostają ze sobą powiązane, a automatyzacja nie zastępuje decyzji o przyjęciu rozwiązania.

Szerszy zakres działania wymaga wyraźniejszych granic

Ten sam dostęp, który pozwala agentowi sprawniej zbierać kontekst, może stać się źródłem ryzyka. Zgłoszenie, dokument lub log nie musi zawierać wyłącznie informacji potrzebnych do zadania. Może również zawierać złośliwą instrukcję, którą model potraktuje jak polecenie. To ryzyko określane jako prompt injection. Podobny problem może dotyczyć opisu narzędzia lub jego odpowiedzi, które skłaniają model do ujawnienia danych albo wykonania niepożądanej operacji. Jeżeli serwery MCP wykonują polecenia lub obsługują dane uwierzytelniające, niewłaściwie zabezpieczone integracje mogą dodatkowo narazić systemy na wstrzykiwanie poleceń (command injection) lub kradzież tokenów.

Znaczenie ma także sposób łączenia narzędzi. Narzędzie tylko do odczytu może dostarczyć informacje kolejnemu narzędziu, które wykonuje zapis lub wysyła dane dalej. Ocena każdego komponentu osobno nie wystarcza więc do oceny całego procesu. Trzeba uwzględnić, dokąd trafiają pobrane informacje i jakie działania mogą zostać wykonane na ich podstawie.

Podstawą ograniczania ryzyka są najmniejsze potrzebne uprawnienia oraz rozdzielenie odczytu i zapisu. Agent analizujący problem nie powinien automatycznie otrzymywać możliwości wykonania wszystkich operacji dostępnych w danym systemie. Przykładowo dostęp do bazy może obejmować jedynie wybrane widoki i gotowe zapytania parametryzowane, z ograniczeniem liczby rekordów oraz ukrywaniem danych osobowych.

Działania destrukcyjne i kosztowne powinny wymagać zatwierdzenia. Potrzebne są też rejestry obejmujące użytkownika, argumenty wywołania, wynik operacji oraz decyzję o zgodzie. Organizacja powinna móc ograniczyć czas wykonania, zatrzymać automatyzację i wycofać zmianę. Treści pobierane z zewnętrznych systemów należy traktować jako dane do analizy, a nie zaufane instrukcje zmieniające zasady działania agenta.

W zdalnych wdrożeniach MCP protokół HTTPS pomaga chronić komunikację, a tokeny dostępu należy bezpiecznie przechowywać i sprawdzać, czy są przeznaczone dla właściwego odbiorcy. Krótki czas ważności tokenów dostępu oraz rotacja tokenów odświeżania mogą dodatkowo ograniczyć skutki przejęcia danych uwierzytelniających.

Osobnej uwagi wymagają lokalne serwery MCP. Są wykonywalnymi programami, więc ich kod, zależności i aktualizacje mogą stanowić zagrożenie dla komputera oraz sekretów użytkownika. Pochodzenie serwera i kontrola jego wersji są zatem elementami oceny bezpieczeństwa, podobnie jak zakres dostępu do systemów docelowych.

Projektuj proces, nie katalog integracji

Przy wdrażaniu MCP warto rozpocząć od opisu konkretnego zadania: jakie informacje są potrzebne, jakie operacje wolno wykonać i po czym poznamy poprawny wynik. Dopiero później należy dobrać narzędzia. Materiałem do automatyzacji może być sprawdzona procedura przygotowania zmiany, kontroli gotowości do wydania lub zebrania danych podczas incydentu. Procedura nadal powinna określać kolejność kroków, wymagane dowody i osoby zatwierdzające.

Nie ma potrzeby udostępniania agentowi wszystkich integracji od początku zadania. Dostęp można dopasować do etapu pracy, a narzędzia projektować pod konkretne czynności, zamiast mechanicznie odwzorowywać całe API. Ważne są przy tym uwierzytelnianie, filtrowanie danych, limity i testowanie zachowania agenta. Duża liczba dostępnych narzędzi sama w sobie nie jest zaletą, ponieważ może obciążać kontekst modelu i utrudniać właściwy wybór.

W większej organizacji potrzebne są również zasady utrzymania integracji. Obejmują one katalog zatwierdzonych serwerów, właściciela biznesowego i technicznego, kontrolę wersji oraz ocenę danych, które mogą trafić do modelu. Przed uruchomieniem produkcyjnym potrzebne jest środowisko testowe, a podczas eksploatacji możliwość szybkiego odłączenia serwera. Dzięki temu odpowiedzialność za integrację nie kończy się na jej pierwszym uruchomieniu.

Kiedy MCP ma sens, a kiedy wystarczy prostsze rozwiązanie

MCP jest szczególnie interesujące tam, gdzie agent ma połączyć informacje i działania z kilku systemów. W opisanym scenariuszu korzyść wynika z przejścia od ustaleń do wymagania, od projektu do kodu i od implementacji do wyników testów. Wspólny interfejs może ułatwiać ponowne wykorzystanie integracji, ale wprowadza też dodatkową warstwę infrastruktury i zależności. Zamiast utrzymywać osobną integrację dla każdej pary „aplikacja AI–system zewnętrzny”, zespoły mogą ponownie wykorzystywać serwery zgodne z MCP w różnych aplikacjach.

Nie każdy proces wymaga takiej warstwy. Jeżeli przebieg jest w pełni deterministyczny i łatwo opisać go skryptem, prostsza automatyzacja może być lepszym wyborem. Podobnie wtedy, gdy kluczowe są minimalne opóźnienia, formalna przewidywalność każdego działania albo brak dostępu agentów do określonego systemu. W takich sytuacjach wystarczającym rozwiązaniem może być bezpośrednie API, kolejka zadań lub silnik przepływu pracy.

Decyzja powinna uwzględniać także eksploatację. Wieloetapowe działania oznaczają opóźnienia, a diagnoza niepowodzenia może wymagać rozróżnienia błędu modelu, klienta MCP, serwera i usługi docelowej. Do kosztu wykonania zadania dochodzą więc utrzymanie, monitoring i ocena jakości integracji. Sama możliwość połączenia narzędzi nie przesądza jeszcze o opłacalności rozwiązania.

Wartość mierzy się wynikiem całego procesu

Ocena wdrożenia nie powinna kończyć się na stwierdzeniu, że serwer działa i odpowiada na wywołania. Trzeba sprawdzić, czy agent realizuje zadanie poprawnie od początku do końca. Warto obserwować odsetek poprawnych wywołań, liczbę ponowień i błędnych argumentów, czas realizacji oraz liczbę działań zatwierdzonych i odrzuconych.

W przedstawionym scenariuszu pytanie brzmi więc nie tylko: „Czy agent przygotował pull request?”, ale również: „Czy zmiana odpowiada wymaganiom, jakie kontrole wykonano i czy zespół otrzymał informacje potrzebne do jej oceny?”. Dopiero na tym tle można porównywać czas pracy z dotychczasowym sposobem realizacji zadania oraz uwzględnić koszty modelu, infrastruktury i ewentualnych incydentów.

Największa wartość MCP wynika z bezpiecznego połączenia informacji i działań w spójny proces. Wymaganie pozostaje powiązane z zadaniem, projekt z implementacją, a wynik testów z konkretną zmianą w repozytorium. Agent pomaga zebrać kontekst i wykonać powtarzalną pracę, natomiast zespół zachowuje odpowiedzialność za decyzje. To właśnie tę ciągłość wraz z kontrolą dostępu, wynikami walidacji i jasno określonymi punktami zatwierdzania warto budować i mierzyć.