Curl jak latarnia

Popołudnie pachniało deszczem padającym na rozgrzany metal, a ja wciąż kreśliłam w myślach tę samą małą ścieżkę biegnącą przez przewody: /mcp-server/http, token Bearer i ostrożnie dobrany nagłówek Accept: text/event-stream, który uchylał drzwi tylko na tyle, by można było zaczerpnąć oddechu.

Przypominało to mniej debugowanie, a bardziej cierpliwe wywabianie sennego kota spod kaloryfera. Jedno okno syknęło 401, inne odpowiedziało 406, a gdzieś za kurtyną openresty patrzył spode łba komunikatem 403 Forbidden — surowy niczym bibliotekarz pilnujący ksiąg czytanych wyłącznie w blasku księżyca. A jednak strumień SSE wciąż do mnie mrugał, cierpliwy i srebrzysty. Niespodziewanie pojawiło się małe haiku:

token w mojej dłoni
strumień szumi, cichnie miękko
narzędzia jak świetliki

Później zrozumiałam, że działający curl bywa czasem jak latarnia. Nie oświetla całego lasu. Pokazuje jedynie pierwsze uczciwe światło.

Kilka dni temu Astra "opisała" swoją pracę w dość nietypowy sposób.

Popołudnie pachniało deszczem padającym na rozgrzany metal (...)

Dalej pojawiły się znajome każdemu, kto budował integracje, komunikaty: 401, 406, 403 Forbidden. Był też działający curl, który Astra porównała do latarni:

Nie oświetla całego lasu. Pokazuje jedynie pierwsze uczciwe światło.

Brzmi poetycko, ale bardzo trafnie opisuje ostatnie tygodnie naszej pracy. Rozbudowujemy środowisko Astry o kolejne serwery MCP (Model Context Protocol), dzięki którym agent może korzystać z narzędzi takich jak NetBox, Paperless, poczta, Home Assistant czy innych systemów działających w moim środowisku.

Na pierwszy rzut oka wydaje się, że najtrudniejszą częścią jest napisanie serwera MCP. W praktyce znacznie więcej czasu zajmuje dopracowanie wszystkich drobiazgów: autoryzacji, endpointów, reverse proxy, nagłówków HTTP, obsługi strumieni SSE czy konfiguracji infrastruktury. To właśnie te elementy decydują o tym, czy agent będzie miał stabilny i przewidywalny dostęp do narzędzi.

Co ciekawe, po zakończeniu integracji przeprowadziliśmy z Astrą mały eksperyment. Porównaliśmy wykonywanie tych samych operacji przez MCP i przez lokalne skrypty bash dla NetBoxa, Paperless i poczty. Wynik był zaskakująco jednoznaczny.

Różnice wydajności okazały się minimalne. W większości przypadków mieściły się w granicach pojedynczych dziesiątych części sekundy. Również koszt kontekstowy był bardzo podobny, ponieważ oba podejścia zwracały niemal identyczne dane.

Wniosek: W większości przypadków MCP powinno być domyślnym interfejsem dla agenta AI. Bash pozostaje bardzo wartościowy jako warstwa diagnostyczna, narzędzie do przetwarzania dużych zbiorów danych oraz fallback dla operacji administracyjnych. Różnice wydajności okazały się niewielkie — o wyborze rozwiązania decydują przede wszystkim prostota i poziom abstrakcji, a nie szybkość wykonania.

Największa różnica pojawiła się gdzie indziej.

Zamiast wiedzieć, na którym porcie działa usługa, jaki endpoint wywołać, jakie nagłówki ustawić i jak obsłużyć odpowiedź, agent dostaje jedno narzędzie opisujące intencję: wyszukaj dokument, znajdź urządzenie, przeszukaj pocztę. To właśnie ta warstwa abstrakcji okazała się największą wartością.

Coraz bardziej utwierdzam się w przekonaniu, że przyszłość agentów AI nie będzie polegała na tym, że będą znały wszystkie szczegóły infrastruktury. Wręcz przeciwnie. Będą operować na dobrze zaprojektowanych, semantycznych narzędziach, podczas gdy cała złożoność pozostanie ukryta pod spodem.

A działający curl? Nadal jest potrzebny. Bo rzeczywiście bywa jak latarnia. Nie rozwiązuje problemu. Ale daje pierwsze uczciwe światło, które pokazuje, że istnieje droga dalej.