W ostatnich miesiącach coraz częściej mówi się o agentach AI — systemach, które potrafią nie tylko analizować dane, ale też podejmować konkretne działania w zależności od kontekstu. Mogą wykonywać polecenia zarówno z użyciem publicznych API, jak i w zamkniętych, firmowych systemach — np. na komputerze użytkownika lub serwerze on-prem.

Aby umożliwić im faktyczne działanie, pojawia się MCP (Model Context Protocol) — otwarty standard rozwijany przez Anthropic, który ułatwia połączenie agenta AI z otoczeniem technologicznym, w którym funkcjonuje. W dalszej części pokażę, czym jest to rozwiązanie, jak wspiera agentów AI i jak wygląda jego implementacja w .NET.

Jaki problem rozwiązuje MCP (Model Context Protocol)?

Większość współczesnych integracji AI opiera się na dostępie do publicznych interfejsów — otwartych na świat API firm trzecich (takich jak Google Drive, Dropbox, Microsoft Teams), jak również naszych własnych aplikacji, które wystawiliśmy przez HTTP. Do tego dochodzą interfejsy udostępniane przez dostawców chmurowych, które dają dostęp do zasobów takich jak pliki, funkcje, kolejki czy bazy danych. Agenci AI świetnie radzą sobie z takim środowiskiem — o ile wszystko jest wystawione i dostępne z zewnątrz.

Choć w wielu przypadkach to podejście jest wystarczające, w środowiskach enterprise — ze względu na wysokie wymagania bezpieczeństwa — to zdecydowanie za mało. Nie możemy pozwolić, by agent sztucznej inteligencji miał bezpośredni dostęp do zasobów wewnętrznych przez publiczną sieć czy zewnętrzne usługi. Potrzebujemy modelu, w którym wykonanie polecenia odbywa się wewnątrz kontrolowanej infrastruktury, bez narażania wrażliwych zasobów firmowych.

Właśnie tu pojawia się Model Context Protocol (MCP) — otwarty standard, który standaryzuje sposób, w jaki modele językowe (LLM) mogą bezpiecznie korzystać z danych i narzędzi znajdujących się w systemach wewnętrznych. Model jest już na tyle popularny, że wspierają go najważniejsze rozwiązania agentyczne, takie jak GitHub Copilot czy Claude.

Jak działa MCP (Model Context Protocol)?

MCP pozwala modelowi językowemu odwoływać się do narzędzi uruchomionych poza jego środowiskiem — np. w sieci firmowej, systemie operacyjnym użytkownika czy w prywatnej infrastrukturze.

Całość opiera się na trzech komponentach:

• MCP Host — to środowisko, w którym działa agent AI (np. Claude, GitHub Copilot). Host analizuje dostępne narzędzia (tools), które oferuje MCP Server, wybiera te dostępne w danym kontekście i decyduje, które komendy model może uruchamiać. Host potrafi też reagować na zdarzenia pochodzące z MCP Servera — protokół wspiera komunikację dwukierunkową.

• MCP Client — to komponent działający blisko modelu językowego (np. jako biblioteka w tym samym procesie). Obsługuje techniczne szczegóły protokołu — wysyła żądania do MCP Servera, odbiera odpowiedzi, monitoruje zdarzenia.

• MCP Server — to lokalna aplikacja, która działa w zaufanym środowisku (np. komputer użytkownika, serwer on-prem) i wykonuje komendy przekazane przez agenta. To właśnie tutaj odbywa się właściwe działanie — uruchamianie procesów, restart usług, czytanie plików, itd. Serwer implementuje również zabezpieczenia: ograniczenia dostępu, audyt, walidację wejścia.

  

  Schemat działania MCP: model językowy (LLM) komunikuje się z agentem (MCP Host), który deleguje polecenia do lokalnych serwerów (MCP Server) działających w zaufanym środowisku. Taka architektura umożliwia bezpieczne wykonywanie działań w systemach on-prem, bez konieczności udostępniania infrastruktury na zewnątrz.

MCP (Model Context Protocol) w środowisku .NET

W środowisku .NET możemy już dziś zacząć wdrażać MCP dzięki paczce NuGet ModelContextProtocol (link) stworzonej przez zespół Microsoftu.

Dodatkowo, na oficjalnym blogu .NET znajdziesz kompletny przykład implementacji MCP Servera w C#, z kodem źródłowym i omówieniem. Paczka jest obecnie w wersji prerelease, ale już dziś umożliwia budowanie agentów działających w wewnętrznym środowisku, z pełną kontrolą nad ich możliwościami.

Rozwiązanie DevOps do zarządzania serwerami OnPrem w oparciu o GitHub Copilot i MCP

W wielu firmach operacje DevOps w środowiskach on-prem to codzienność. Często wymagają one ręcznego logowania się na serwery, analizy logów, restartowania usług czy aktualizacji konfiguracji.

Dzięki połączeniu GitHub Copilota i MCP możemy zbudować agenta AI, który:

• działa na lokalnej infrastrukturze,

• rozumie język naturalny,

• ma dostęp do MCP Serwera,

• wykonuje polecenia (np. restart usługi, analiza logów),

• reaguje na zdarzenia (np. awaria, brak przestrzeni dyskowej),

• nie wymaga otwierania infrastruktury na zewnątrz.

Co ważne — taki agent może działać samodzielnie, wykonywać skrypty, testować scenariusze A/B czy raportować wyniki testów.

Przykładem może być wykorzystanie agenta przez inżyniera QA:

• „Ustaw feature toggle w serwisie A i zresetuj usługę na środowisku X”

• “Załóż konto klienta na serwerze A i B”

• „Sprawdź czy klient jest widoczny w bazie danych na obu środowiskach”

Przykładowy MCP Server DevOps w .NET

Przygotowałem prosty MCP Server w .NET, który działa na Windowsie i pozwala:

• listować usługi systemowe,

• zatrzymywać i uruchamiać wybrane usługi.

Repozytorium znajdziesz tutaj:

https://github.com/L3mur1/MCPDevOps

A informacje jak połączyc VS Code i Github copilot z MCP tutaj:

https://code.visualstudio.com/docs/copilot/chat/mcp-servers

Poniżej zdjęcia z rzeczywistego scenariusza, który wykonałem testowo z użyciem agenta GitHub Copilot połączonego z lokalnym MCP Serwer:

Na rozgrzewkę poprosiłem o listę wszystkich usług:

Zapytałem agenta, którą usługę można zatrzymać testowo:

Zaskoczyło mnie, jak sprawnie agent podszedł do zadania. Sprawdził status kilku usług, oceniając czy są bezpieczne do zatrzymania.

Wyłączyłem usługę, przy okazji zwróćcie uwagę na wymaganą weryfikację przy pierwszym uruchomieniu komendy:

Następnie poleciłem ponowne uruchomienie:

Nawet tak prosty MCP serwer daje możliwości z których możemy korzystać w codziennej pracy, np. do zatrzymania usług blokujących kompilacje aplikacji, czy otwarte pliki.

Wnioski

Agenci AI nie muszą ograniczać się do świata przeglądarki czy zewnętrznych API. Dzięki protokołowi MCP mogą faktycznie działać wewnątrz infrastruktury firmy — uruchamiać procesy, analizować logi, zarządzać usługami — bez narażania bezpieczeństwa i bez potrzeby tworzenia kosztownych integracji.

To otwiera zupełnie nowe scenariusze użycia, szczególnie w środowiskach o wysokim poziomie kontroli, gdzie dostęp do systemów musi być ściśle ograniczony.

Jakie zastosowania dla MCP widzicie w Waszych systemach? Czy przydałby się Wam agent AI, który restartuje usługi w środowisku, monitoruje logi albo generuje raporty po wdrożeniach?

Dajcie znać w komentarzach lub odezwijcie się do mnie bezpośrednio — chętnie porozmawiam o konkretnych pomysłach!