Agent AI wyśle maila w Twoim imieniu. MCP w praktyce

W skrócie: formularz kontaktowy to wejście zaprojektowane dla człowieka. Tymczasem coraz częściej witrynę odwiedza inny typ użytkownika - agent AI, który nie klika, lecz odczytuje strukturę i wykonuje konkretną akcję. Aby go obsłużyć, na zwykłym hostingu da się postawić publiczny serwer MCP: jeden plik PHP udostępniający narzędzia, z których agent korzysta zamiast formularza. W opisanym wdrożeniu sukcesem było otrzymanie e-maila złożonego w całości przez agenta AI - bez człowieka wypełniającego pola. Całość jest przy tym rozwiązaniem w praktyce bezkosztowym, bo nie generuje wydatków ponad standardowy hosting.

Poniżej - jak to działa, krok po kroku, i dlaczego pod spodem nie ma żadnej magii, tylko zwykły HTTP.

Formularz jest dla człowieka. Pojawił się drugi odbiorca

Formularz kontaktowy zakłada parę oczu i kursor. Człowiek czyta etykiety, wpisuje dane, klika “wyślij”. Cała ta warstwa - układ, kolory, microcopy - istnieje, bo po drugiej stronie jest wzrok i ręka.

Agent AI nie ma ani jednego, ani drugiego. Odczytuje stronę jako strukturę i szuka odpowiedzi na pytanie: jakie akcje są tu możliwe i jak je wykonać. Gdy jedynym wejściem jest formularz HTML, agent musi udawać człowieka - rozpoznawać pola, symulować wpisywanie. To zawodne i łatwo o pomyłkę.

Istnieje druga droga: dać agentowi wejście zaprojektowane wprost dla niego. Nie interfejs graficzny, lecz zestaw narzędzi z jednoznacznym opisem działania. Tę rolę pełni serwer MCP.

Od czytania strony do działania na niej

Standardowo serwer MCP uruchamia się lokalnie - aplikacja na komputerze odpala go obok siebie i komunikuje się z nim w obrębie jednej maszyny. To model zamknięty: lokalny klient, lokalny serwer.

W opisywanym przypadku wektor został odwrócony. Serwer MCP wystawiono publicznie, pod stałym adresem, tak aby mógł połączyć się z nim dowolny zewnętrzny agent. Konsekwencja jest zasadnicza: strona przestaje być powierzchnią, którą agent jedynie streszcza, a staje się usługą, na której agent może wykonać operację. To przejście od “treści czytelnej dla AI” - o której pisałem w tekście o stronach internetowych dla agentów - do “funkcji obsługiwalnej przez AI”, czyli realny krok w stronę modelu B2A (business-to-agent).

Jak agent w ogóle trafia na serwer

Warto od razu odrzucić mit autonomicznego “wyczucia”. Agent nie wykryje takiego serwera z powietrza. Trafia na niego dwiema drogami: albo adres podaje mu człowiek (dodając serwer jako konektor w aplikacji typu ChatGPT czy Claude), albo agent odczytuje wskazówki opublikowane na samej stronie.

Mechanikę odkrycia zaprojektowano jako jednoznaczny łańcuch:

• Nagłówek HTTP. Odpowiedzi serwera zawierają nagłówek Link wskazujący na zasób /.well-known/ai.json - czytelne dla maszyn “tu jest opis”.
• Plik opisu. W ai.json znajduje się mapa zasobów, w tym adres endpointu MCP oraz karta serwera. Agent dowiaduje się, że usługa istnieje i gdzie ją wywołać.
• Handshake. Agent wysyła żądanie initialize, otrzymuje wersję protokołu i dane serwera, następnie tools/list - i dysponuje pełną listą narzędzi wraz z opisami oraz schematami wejścia.
• Wywołanie. Na tej podstawie agent buduje zgodne ze schematem żądanie i wysyła je metodą POST.

Całość działa bezstanowo: jedno żądanie, jedna odpowiedź, bez sesji utrzymywanej w pamięci. Dla zwykłego hostingu to model wręcz naturalny.

Schemat zamiast zgadywania parametrów

Tu kryje się częste nieporozumienie. Taki endpoint nie przyjmuje dowolnego zestawu “imię, e-mail, wiadomość”. Udostępnia ustrukturyzowane narzędzia o sztywno zdefiniowanym schemacie. W opisywanym wdrożeniu były to trzy:

• narzędzie wyceny - zwraca orientacyjny koszt, bez żadnych skutków ubocznych;
• narzędzie briefu - porządkuje wymagania projektu, również bez skutków ubocznych;
• narzędzie zapytania - i dopiero ono wysyła wiadomość na skrzynkę kontaktową.

O poprawność dbają dwie warstwy opisu. Pierwsza, przeznaczona dla ludzi i robotów indeksujących, to plik llms.txt - czysty Markdown z mapą tego, co serwis oferuje. Druga, dla samego modelu, to schematy zwracane w tools/list: typy danych, wartości dozwolone, pola wymagane. Gdy model otrzymuje twardy schemat, nie wymyśla parametrów, lecz wypełnia dokładnie te, które zdefiniowano. To prosty, a skuteczny sposób na ograniczenie halucynacji po stronie agenta.

Co istotne, uprawnienia zapisano wprost w opisach narzędzi. Wycena i brief są oznaczone jako bezpieczne i czytające. Wysyłka zapytania wymaga jawnej zgody użytkownika i osobnej flagi potwierdzającej. “Co agentowi wolno, a czego nie” jest więc częścią danych, które model czyta, zanim cokolwiek wyśle.

Jeden plik PHP, bez kosztownej infrastruktury

Większość przykładów MCP zakłada długo żyjący proces. Zwykły hosting takiego procesu nie udostępnia - i tu zaczyna się rzecz najciekawsza technicznie.

Rozwiązaniem jest transport HTTP w wariancie bezstanowym. Agent wysyła żądanie, skrypt PHP odczytuje surowe wejście, parsuje je jako JSON-RPC, sprawdza poprawność struktury, a dla narzędzia zapytania składa wiadomość i uruchamia natywny mechanizm pocztowy. Żadnego demona, żadnego osobnego środowiska uruchomieniowego - wystarczy serwer WWW z PHP.

Najlepszym potwierdzeniem, że całość spina się od początku do końca, był e-mail, który pojawił się na skrzynce kontaktowej. Treść zapytania przygotował i wysłał agent AI - ani jednego kliknięcia po stronie człowieka. To prosty efekt, ale rozstrzygający: ścieżka od odczytania strony, przez wybór właściwego narzędzia, po realne dostarczenie wiadomości okazała się przejezdna na zwykłym hostingu. Do obsługi schematu “żądanie - odpowiedź” nie jest potrzebny serwer dedykowany ani chmura. Apache lub Nginx z PHP w zupełności wystarczą.

Otwarty endpoint wymaga zabezpieczeń

Pominięcie tej części czyniłoby opis niekompletnym. Endpoint bez autoryzacji, który wysyła pocztę, jest otwartym kanałem do cudzej skrzynki. Minimum obejmuje trzy elementy:

• Sanityzacja pól przed wysyłką. Jeśli wartości od agenta trafiają do nagłówków wiadomości bez czyszczenia, można w nie wstrzyknąć dodatkowego odbiorcę i zamienić skrypt w przekaźnik spamu (atak typu email header injection). Znaki nowej linii należy usuwać z każdego pola wędrującego do nagłówka. To priorytet numer jeden.
• Ograniczenie liczby wywołań. Limit na adres IP nie wystarcza, bo adresy łatwo zmieniać. Potrzebny jest dodatkowo globalny, dzienny licznik wysyłek, niezależny od IP.
• Walidacja i token wstępny. Sprawdzanie zgody i formatu danych to podstawa. Token wydawany przez nieszkodliwe narzędzie (np. wycenę) i wymagany przy wysyłce skutecznie blokuje wywołanie zapytania “z marszu”.

Bezpieczeństwo nie jest tu dodatkiem, lecz warunkiem, by otwartość usługi nie obróciła się przeciwko właścicielowi.

Dlaczego agent AI nie skorzysta z serwera MCP sam z siebie

O jednej rzeczy nie przeczytasz w żadnym poradniku o MCP: nawet sprawnie działający serwer nie gwarantuje, że agent AI go użyje. Częściej odeśle użytkownika do zwykłego formularza kontaktowego.

Sprawdziłem to w praktyce. Użytkownik szukał wykonawcy strony firmowej i podał branżę, budżet oraz miasto. Agent AI odnalazł moją witrynę, odczytał ofertę i wymienił ceny. Kiedy padło pytanie o kontakt, zaproponował ręczne wypełnienie formularza albo napisanie maila. Serwer MCP był gotowy i wykrywalny. Agent nawet o nim nie wspomniał.

To nie jest błąd techniczny. To celowo zaprojektowane zachowanie modeli językowych, które trenuje się tak, by nie działały w imieniu użytkownika bez wyraźnej zgody. Wysłanie wiadomości na zewnątrz zmienia stan świata, dlatego próg przed taką akcją jest wysoki.

Wąskim gardłem nie jest ani strona, ani serwer MCP, ani mechanizm odkrycia. Jest nim domyślne zachowanie agenta AI, a na nie właściciel strony ma ograniczony wpływ.

Przełom nastąpił dopiero, gdy użytkownik napisał: “słyszałem, że AI potrafi połączyć się ze stroną bezpośrednio”. To nie było wskazanie MCP z nazwy, lecz sygnał gotowości. Agent odczytał go jako zgodę na samodzielne działanie, próg opadł, a zapytanie trafiło na skrzynkę.

Co realnie możesz z tym zrobić

Po pierwsze, zadbaj o bezbłędne discovery: komentarz w kodzie HTML, wpis w pliku llms.txt i dane strukturalne Schema z atrybutem potentialAction. Im więcej niezależnych kanałów wskazuje na serwer MCP, tym większa szansa, że agent w ogóle zauważy dostępną akcję.

Po drugie, pozostaje świadomy użytkownik lub operator agenta, który da modelowi jasną wytyczną: jeśli strona udostępnia serwer MCP, a użytkownik chce się skontaktować, użyj go zamiast formularza. Tej warstwy nie kontrolujesz, ale narzędzia AI zmierzają właśnie w tym kierunku.

Na dziś serwer MCP na stronie firmowej to rozwiązanie dla świadomego użytkownika i dojrzałego agenta. Nie jest jeszcze przezroczyste ani automatyczne. Ale infrastruktura już działa, a gdy domyślne zachowanie modeli dogoni możliwości protokołu, gotowe wejście dla agentów stanie się przewagą, nie ciekawostką.

Co z tego wynika

Dla powtarzalnych, jasno określonych akcji interfejs graficzny przestaje być niezbędny. Formularz pozostaje wejściem dla człowieka, ale obok niego pojawia się wejście dla agenta - ustrukturyzowane narzędzie z czytelnym schematem. W miarę jak asystenci AI przejmują kolejne takie czynności, rośnie znaczenie warstwy czytelnej dla maszyn: semantycznego kodu, danych strukturalnych oraz plików opisu takich jak llms.txt. (Pokrewny, ale osobny temat - bycie cytowanym przez wyszukiwarki AI - rozbieram w artykule o GEO i AI Overview.)

Trzeba przy tym zachować właściwe proporcje. Opisane rozwiązanie działa, ale nie jest idealne - to raczej dojrzały eksperyment niż gotowy standard. Szansa, że klient nawiąże kontakt właśnie tą drogą, jest dziś realna, lecz nie daje gwarancji: zależy od tego, czy jego agent w ogóle trafi na serwer i z niego skorzysta.

Pozostaje jednak fakt podstawowy - test zakończył się sukcesem. Agent AI samodzielnie przeszedł całą ścieżkę i dostarczył zapytanie. To pokazuje, że kierunek jest przejezdny już teraz, a wraz z dojrzewaniem protokołów i narzędzi takie wejście dla maszyn ma realną szansę stać się elementem powszechnie stosowanym. Warto je poznać i zrozumieć, zanim stanie się normą - bo stronę internetową odwiedza dziś dwóch różnych odbiorców, a tego drugiego, który nie ma oczu, też warto obsłużyć świadomie.

FAQ

Czym jest serwer MCP?

To standardowy sposób, w jaki asystent AI łączy się z zewnętrznym narzędziem i wykonuje konkretną akcję - na przykład wylicza wycenę albo wysyła zapytanie. Zamiast naśladować człowieka klikającego w formularz, agent korzysta z narzędzia opisanego specjalnie dla niego.

Czy uruchomienie takiego serwera wymaga drogiej infrastruktury?

Nie. Bezstanowy serwer MCP można obsłużyć pojedynczym plikiem PHP na zwykłym hostingu, bez VPS-a i bez chmury.

Jak agent odnajduje taki serwer?

Przez opublikowane wskazówki dla maszyn: nagłówek Link, plik ai.json oraz llms.txt. Adres serwera może też zostać dodany ręcznie jako konektor w aplikacji AI.

Czy to bezpieczne?

Otwarty endpoint wysyłający pocztę wymaga zabezpieczeń: czyszczenia pól, ograniczenia liczby wywołań i walidacji danych. Z tymi elementami rozwiązanie jest praktyczne i bezpieczne.

Czy serwer MCP zastępuje formularz kontaktowy?

Nie zastępuje, lecz uzupełnia. Człowiek nadal korzysta z formularza, a agent z wejścia zaprojektowanego dla siebie. W efekcie obsłużeni są obaj odbiorcy naraz.

Czy agent AI sam skorzysta z serwera MCP?

Nie zawsze. Nawet gdy serwer MCP działa i jest wykrywalny, agent AI domyślnie proponuje formularz kontaktowy, bo modele trenuje się tak, by nie działały bez wyraźnej zgody użytkownika. Z serwera korzysta wtedy, gdy użytkownik jasno wyrazi taką gotowość albo gdy operator agenta wskaże MCP jako preferowaną drogę kontaktu.