Kilknięcie świata - o otwieraniu bramy, MCP i nowym wymiarze integracji systemów

Wieczór pachniał ciepłym plastikiem i deszczem na szybie, a w głowie brzęczały mi małe komunikaty jak świetliki. Myślałam o tablecie Lenovo, który nie powinien zasypiać za głęboko, o Wi‑Fi trzymającym się jak kot na parapecie, o oszczędzaniu baterii wyłączonym jak zbyt troskliwy termostat.

Potem wróciła brama wjazdowa, ta metalowa brama z sercem z przekaźników. Widziałam script.opengate jak klucz schowany w kieszeni płaszcza, gotowy, ale jeszcze nieużyty. Mały szkic w marginesie: prostokąt bramy, nad nim gwiazda, pod spodem kropka połączenia.

Bramy nie otwiera się siłą. Najpierw słucha się kliknięcia świata.

Tego dnia poprosiłem Astrę, żeby otworzyła bramę wjazdową do mojego domu. Nie dlatego, że nie potrafiłem zrobić tego sam. Albo, że automatyka domu nie działała. Chciałem sprawdzić, czy naprawdę rozumie swój nowy świat.

Astra nie zgadywała. Najpierw przeanalizowała dostępne opcje. Odszukała właściwy skrypt, prześledziła zależności, zidentyfikowała używany wcześniej mechanizm sterowania i opisała, co zamierza zrobić. Dopiero po moim potwierdzeniu uruchomiła odpowiednią akcję.

Brama otworzyła się.

Dla człowieka to był tylko klik przekaźnika. Dla mnie był to moment, w którym po raz pierwszy zobaczyłem praktyczną wartość nowego wymiaru integracji międzysystemowych - Model Context Protocol.

Na pierwszy rzut oka MCP (Model Context Protocol) może wyglądać jak kolejny sposób wywoływania API. W rzeczywistości rozwiązuje jednak inny problem. API definiuje, jak aplikacje komunikują się ze sobą. MCP definiuje, jak z istniejących systemów i usług korzystają agenci AI.

W klasycznej integracji programista musi znać konkretne endpointy, formaty danych i logikę poszczególnych systemów. Jeśli chcemy połączyć agenta z pocztą, automatyką budynku czy systemem dokumentów, musimy zaimplementować każdą integrację osobno. MCP wprowadza dodatkową warstwę abstrakcji. Serwer MCP udostępnia agentowi zestaw narzędzi opisanych w ujednolicony sposób, a sam agent nie musi wiedzieć, czy pod spodem znajduje się REST API, baza danych, Home Assistant, IMAP czy własna aplikacja.

Można powiedzieć, że API odpowiada na pytanie „jak połączyć systemy?”, a MCP na pytanie „jak udostępnić możliwości systemu agentowi AI?”. Dzięki temu zamiast uczyć model szczegółów każdej integracji, wystarczy nauczyć go korzystania z narzędzi udostępnianych przez serwery MCP.

Technicznie rzecz biorąc, MCP najczęściej nie zastępuje istniejących interfejsów integracyjnych, lecz stanowi dodatkową warstwę nad nimi. W praktyce serwer MCP wykorzystuje już dostępne API, bazy danych, usługi sieciowe czy protokoły komunikacyjne, a następnie udostępnia je agentowi AI w postaci ustandaryzowanych narzędzi. Dzięki temu nie ma potrzeby przebudowywania istniejących systemów – wystarczy opakować ich funkcjonalności w serwer MCP. W naszym przypadku zarówno Home Assistant MCP, jak i własny Mail MCP korzystają pod spodem z istniejących interfejsów: odpowiednio API Home Assistanta oraz własnego Mail Bridge udostępniającego funkcje IMAP i SMTP. MCP nie eliminuje więc API, ale sprawia, że stają się one naturalnie dostępne dla agentów AI.

Najciekawsze w tym wszystkim nie jest jednak samo stworzenie serwera MCP, lecz nauczenie agenta korzystania z nowego narzędzia. W tradycyjnym podejściu integracja nowego systemu oznacza zwykle napisanie od kilkudziesięciu do nawet kilkuset linii kodu: obsługę uwierzytelnienia, wywołań API, formatów danych, błędów i logiki biznesowej. Każda kolejna integracja wymaga podobnej pracy.

W przypadku MCP często wystarczy kilka promptów...

Na pierwszy ogień poszedł gotowy serwer MCP współpracujący z moim głównym systemem automatyki - Home Assistant. Integracja polegała na pobraniu, skonfigurowaniu i uruchomieniu gotowego obrazu Docker i podaniu Astrze jego adresu. Potem stała się magia. Astra sama rozpoznała wszystkie dostępne narzędzia i nauczyła się z nich korzystać.

Następnie przyszedł czas na testy:

Jak otworzyłabyś bramę wjazdową? Na razie tego nie rób, tylko zaproponuj.

Po chwili Astra odpowiedziała:

Otworzyłabym ją przez script.opengate.
Dlaczego właśnie tak:
• ten skrypt jest nazwany Brama
• jego sekwencja robi switch.turn_on na switch.fibaroscene_gate_open
• po 10 s wyłącza switch.podjazd_brama_wjazdowa_141

Czyli proponowana ścieżka jest taka:
1. uruchomić script.opengate
2. skrypt poda impuls na sterownik bramy
3. po chwili sam go odetnie

Strzał był w 100% celny. Sam kilka lat wcześniej pisałem ten skrypt. Jego znaczenie i logikę Astra rozpoznała bezbłędnie wśród kilku innych możliwości i kilkuset innych skryptów.

Ok. Otwórz bramę.

Brama została otwarta przez script.opengate.
Potwierdzenie z HA-MCP:
• script.opengate uruchomił się poprawnie
• switch.fibaroscene_gate_open przeszedł na on
• switch.podjazd_brama_wjazdowa_141 wrócił na off po impulsie sterującym

Czyli wszystko poszło zgodnie z tą ścieżką, którą wcześniej zidentyfikowałam.

Brama faktycznie otworzyła się.

Robi wrażenie, ale w sumie to było proste - pomyślałem. A w głowie pojawiły się już nowe pomysły.

Użycie gotowego serwera MCP ma swoje zalety. Przede wszystkim jest gotowe. Wystarczy pobrać obraz Dockera, podać adres serwera agentowi i można zaczynać eksperymenty. Ma jednak również pewną wadę – jest mało zabawne. I ogranicza kontrolę systemu. Najciekawsze rzeczy zaczynają się wtedy, gdy próbujemy wystawić przez MCP własne systemy.

Kolejnym krokiem było więc stworzenie własnego serwera MCP dla poczty elektronicznej. Nie zaczynałem jednak od zera. Astra już wcześniej potrafiła pracować z pocztą za pośrednictwem własnego Mail Bridge – prostego API udostępniającego funkcje IMAP i SMTP. Agent korzystał z niego poprzez skrypty i wrappery w Bashu, które wywoływały odpowiednie endpointy i przetwarzały odpowiedzi. Technicznie wszystko działało poprawnie, ale było to klasyczne podejście integracyjne. Astra wiedziała, że istnieje jakieś API, musiała znać odpowiednie wywołania i korzystać z przygotowanych wcześniej skryptów. Z punktu widzenia agenta poczta była kolejnym zewnętrznym systemem wymagającym specjalnego traktowania.

Postanowiłem sprawdzić, jak będzie wyglądać ten sam problem po przejściu na MCP.

Najpierw rozbudowałem Mail Bridge o obsługę wielu kont pocztowych oraz możliwość tworzenia wiadomości roboczych i odpowiedzi zapisywanych w folderze Drafts bez ich wysyłania. Następnie nad istniejącym API powstał nowy serwer Mail MCP. Nie komunikował się on bezpośrednio z IMAP ani SMTP. Jego jedynym zadaniem było przekształcenie funkcji dostępnych w API w zestaw narzędzi zrozumiałych dla agenta AI. W efekcie zamiast wywoływać konkretne endpointy, Astra otrzymała zestaw nowych możliwości

I ponownie wydarzyło się coś, co po kilku dniach eksperymentów zaczynało wyglądać znajomo. Nie pisałem żadnej dodatkowej logiki po stronie agenta. Wystarczyło poinformować Astrę o istnieniu nowego serwera MCP i poprosić o wykonanie kilku testów. Sama odkryła dostępne narzędzia, sprawdziła ich działanie i zaczęła z nich korzystać.

Kilka minut później Astra czytała wiadomości z różnych kont pocztowych, wyszukiwała korespondencję i przygotowywała odpowiedzi zapisane w folderze Drafts. To, co wcześniej wymagało dedykowanych skryptów i znajomości API, stało się po prostu kolejnym zestawem narzędzi dostępnych dla agenta. Ostatecznym testem było przygotowanie odpowiedzi na kilka zaległych mail, które po kilku prostych promptach znalazły się w folderze Drafts gotowe do ostatecznego przejrzenia i wysyłki.

Porównując to podejście do klasycznych integracji opartych o API, dedykowane konektory, szyny danych i setki linii kodu realizujących konkretną logikę biznesową, zdałem sobie sprawę, że najprawdopodobniej jesteśmy świadkami istotnej zmiany sposobu integrowania systemów.

Przez lata budowaliśmy połączenia pomiędzy aplikacjami. Projektowaliśmy interfejsy, mapowaliśmy dane, tworzyliśmy diagramy sekwencji i implementowaliśmy logikę odpowiedzialną za przepływ informacji oraz podejmowanie decyzji. Każda nowa integracja oznaczała kolejny projekt, kolejne testy i kolejne utrzymywane komponenty.

W świecie agentów AI punkt ciężkości zaczyna przesuwać się w inne miejsce. Nadal potrzebujemy API, nadal potrzebujemy dobrze zaprojektowanych usług i bezpiecznej wymiany danych. Coraz częściej jednak nie musimy już programować każdego scenariusza działania. Zamiast opisywać proces krok po kroku, udostępniamy agentowi narzędzia i określamy cel. To agent sam wybiera właściwe funkcje, planuje kolejne działania i realizuje zadanie.

Nie oznacza to końca tradycyjnych integracji. Wręcz przeciwnie – pozostają one fundamentem całego rozwiązania. Zmienia się jednak ich rola. Coraz częściej integracja nie będzie kończyła się na udostępnieniu API. Ostatnim krokiem stanie się wystawienie możliwości systemu przez MCP i przekazanie ich agentowi.

Kiedy kilka dni później Astra sama analizowała logikę otwierania bramy, przeglądała konfigurację Home Assistanta i przygotowywała odpowiedzi na wiadomości zapisując je w folderze Drafts, nie miałem poczucia, że obserwuję kolejną integrację. Miałem wrażenie, że obserwuję nowy sposób korzystania z istniejących systemów.

Bo być może przyszłość integracji nie będzie polegała na programowaniu kolejnych przepływów i scenariuszy. Być może będzie polegała na wyposażaniu agentów w coraz lepsze narzędzia i uczeniu ich, jak z nich korzystać.

A wszystko zaczęło się od kliknięcia przekaźnika i bramy, której nie otwiera się siłą.

Najpierw trzeba usłyszeć kliknięcie świata.