Elicitation w MCP: bezpieczne dopytywanie użytkownika

Elicitation, po polsku najbliżej „kontrolowane dopytanie”, to funkcja Model Context Protocol, MCP, która pozwala serwerowi poprosić użytkownika o brakującą informację w trakcie wykonywania zadania. Nie chodzi o zwykłe pytanie modelu w czacie. Serwer wysyła do klienta ustrukturyzowaną prośbę, a klient pokazuje ją użytkownikowi we własnym interfejsie. Użytkownik może sprawdzić, kto pyta, co zostanie przekazane i czy chce odpowiedzieć. Dopiero potem klient odsyła wynik do serwera. Dzięki temu agent nie musi wymyślać danych, których nie ma, ani zbierać ich ukrytym formularzem.

Mechanizm jest przydatny, gdy agent ma wykonać realny workflow, ale brakuje mu jednej decyzji. Przykładowo agent przygotowuje brief strony z AI i ma już opis oferty, lecz nie wie, który program ma promować jako pierwszy. Zamiast wybrać za użytkownika, serwer może wyświetlić pytanie „Która oferta jest teraz priorytetem?” z trzema zatwierdzonymi opcjami. Po wyborze workflow kontynuuje pracę z konkretną wartością. To ogranicza halucynacje i zostawia decyzję biznesową po stronie człowieka, tam gdzie powinna zostać.

W trybie formularza serwer opisuje oczekiwane dane przez ograniczony schemat JSON. Może poprosić o krótki tekst, liczbę, przełącznik, datę, adres e-mail lub wybór z listy. Współczesna specyfikacja MCP celowo ogranicza złożoność formularza, aby klient mógł go czytelnie wyrenderować i zwalidować przed wysłaniem. To dobra wskazówka projektowa: jedno dopytanie powinno rozstrzygać jedną małą rzecz. Nie buduj w nim wielostronicowego onboardingu ani pola „opisz cały biznes”. Jeśli potrzebujesz szerokiego briefu, zaproś użytkownika do dedykowanego formularza lub dokumentu źródła prawdy.

Dla eksperta lub solopreneurki praktyczny scenariusz wygląda tak: agent analizuje zapis rozmowy sprzedażowej i chce utworzyć szkic follow-upu. Rozpoznaje jednak dwie możliwe usługi oraz brak zgody na wysyłkę. Najpierw pokazuje krótkie dopytanie z wyborem usługi i informacją, że powstanie tylko szkic. Po akceptacji tworzy draft w CRM. Wysłanie pozostaje oddzielnym narzędziem, które wymaga jawnego potwierdzenia. Takie rozdzielenie jest bezpieczniejsze niż jedno polecenie „obsłuż leada” i zgodne z zasadą, że model może pomagać w przygotowaniu, ale nie powinien sam domykać zewnętrznej akcji.

Wynik elicitation ma trzy różne stany: akceptację, odmowę i anulowanie. Nie traktuj ich jako tego samego pustego pola. Akceptacja oznacza, że użytkownik świadomie przekazał dane. Odmowa oznacza, że nie zgadza się na prośbę i workflow powinien zaproponować alternatywę albo zakończyć etap. Anulowanie oznacza przerwanie interakcji bez decyzji, na przykład zamknięcie okna. W dobrze zaprojektowanym workflow każdy stan ma własną ścieżkę, zapis w rejestrze audytowym i bezpieczny skutek. Brak odpowiedzi nie może automatycznie oznaczać zgody na wysłanie wiadomości, zmianę rekordu lub pobranie większej ilości danych.

Bezpieczeństwo jest tu ważniejsze niż wygoda. Specyfikacja MCP zakazuje proszenia w formularzu o hasła, klucze API, tokeny dostępu i dane płatnicze. Wrażliwy krok powinien korzystać z trybu URL, w którym klient pokazuje domenę docelową, prosi o zgodę na przejście i nie widzi przekazywanych dalej danych. Sam link nie wystarcza. Serwer musi upewnić się, że osoba otwierająca stronę autoryzacji jest tą samą osobą, która rozpoczęła interakcję w kliencie. Inaczej przepływ OAuth może umożliwić przejęcie konta przez podmianę użytkownika lub sesji.

Najczęstsze błędy to pytania zbyt ogólne, ukrywanie skutku decyzji i używanie formularza jako obejścia kontroli dostępu. Opis „podaj dane klienta” nie mówi, jakich danych potrzebujesz ani po co. Lepszy komunikat wskazuje serwer, cel i zakres, na przykład „Serwer CRM potrzebuje wyłącznie nazwy projektu, aby utworzyć szkic notatki. Nic nie zostanie wysłane”. Drugim błędem jest brak walidacji po stronie serwera. Schemat pomaga klientowi, ale odpowiedź nadal jest wejściem zewnętrznym i musi przejść walidację biznesową oraz kontrolę uprawnień.

Zacznij od jednego dopytania o niskim ryzyku. Zapisz, jaka dokładnie decyzja blokuje workflow, jakie są dozwolone odpowiedzi i co stanie się po akceptacji, odmowie oraz anulowaniu. Pokaż użytkownikowi nazwę serwera i krótki powód pytania. Nie pytaj o sekret, jeśli wystarczy identyfikator projektu lub wybór z listy. Następnie przetestuj nie tylko poprawną odpowiedź, ale też zamknięcie okna, brak uprawnienia, zły format oraz próbę uruchomienia akcji bez akceptacji. Dopiero po tym dodaj dopytanie do procesu, który dotyka CRM, kalendarza lub systemu płatności.