Serwer MCP zmienił narzędzia: czy nadal zatwierdzono tę samą integrację?

W poniedziałek integracja potrafiła znaleźć wiadomość i przygotować szkic odpowiedzi. W czwartek pod tym samym adresem serwera pojawiło się narzędzie wysyłające odpowiedź wszystkim uczestnikom wątku. Nazwa dostawcy nie zmieniła się, ikona nadal była zielona, a w rejestrze widniało „zatwierdzono w poniedziałek”. Tylko zakres możliwego działania trochę urósł. Jak roślina, którą ktoś podlewał uprawnieniami.

To fikcyjny przykład, lecz pytanie odbiorowe jest konkretne: co właściwie zatwierdzono? Połączenie z serwerem, odczyt skrzynki, listę określonych narzędzi czy możliwość wykonania każdego działania, które dostawca kiedyś doda? Jeżeli zapis zgody nie pozwala rozróżnić tych rzeczy, nie pomoże samo sprawdzenie, że adres nadal odpowiada.

MCP to protokół pozwalający aplikacji AI korzystać między innymi z narzędzi udostępnionych przez serwer. Przegląd katalogu w działającym procesie ma wskazać, co zmieniło się od ostatniego dopuszczenia i jak ta różnica wpływa na zadanie. Na tej podstawie właściciel procesu decyduje o dalszym użyciu integracji. Zakres poniższej próby obejmuje działanie narzędzi i jego operacyjny odbiór.

Ten sam adres nie opisuje całego działania

Dla naszego procesu pocztowego zatwierdzona czynność polegała na znalezieniu informacji i przygotowaniu materiału do oceny przez człowieka. Wysyłka była poza zakresem. Dodanie osobnego narzędzia wysyłającego wiadomość nie musi automatycznie prowadzić do jego użycia, ale zmienia zestaw działań, które aplikacja może otrzymać do wyboru. Sprawdź, czy po tej zmianie aplikacja nadal kończy pracę na szkicu.

W specyfikacji narzędzi MCP katalog pobiera się przez tools/list, a definicja narzędzia obejmuje między innymi nazwę, opis i schemat wejścia. Mechanizm listChanged dotyczy informowania o zmianie listy. Samo powiadomienie nie jest oceną nowego zakresu działania.

Do porównania dwóch stanów zachowaj więc coś więcej niż zrzut ikony połączenia. Zachowaj oznaczenie serwera, zestaw faktycznie udostępnionych narzędzi, ich opisy i parametry oraz informację o koncie, dla którego pobrano katalog. Odczyt wykonany kontem testowym z ograniczonym dostępem może przedstawiać inny zakres niż połączenie używane przez zespół. Nie podpisuj go jako dowodu dotyczącego wszystkich kont.

Nazwa narzędzia pomaga znaleźć pozycję, ale nie zastępuje oceny działania. W naszym przykładzie nowa pozycja może nosić wyraźną nazwę wskazującą wysyłkę. Trudniejszy przypadek to zachowanie dawnej nazwy przy zmianie domyślnego trybu: przygotowanie szkicu zostaje zastąpione wysłaniem odpowiedzi, jeżeli nie podano dodatkowego parametru. Porównanie samych nazw nie pokaże tej różnicy.

Przy scalaniu kilku integracji odnotuj również, z którego połączenia pochodzi dana pozycja. Dwa podobnie nazwane narzędzia mogą odnosić się do różnych skrzynek albo środowisk. Zapis „sprawdzono wyszukiwanie” niczego nie rozstrzyga, jeśli nie wiadomo, czy chodziło o testowy katalog, czy firmową pocztę. Oznaczenie powinno pozwalać wrócić do ocenianej konfiguracji bez odgadywania po kolorze logo.

Podstawy dopuszczania danych i czynności opisuje tekst o uprawnieniach integracji AI. Tutaj dokładamy zmianę w czasie: czy późniejszy katalog nadal mieści się w uzgodnionych granicach? Ponowne połączenie, odświeżenie listy albo ponowne zalogowanie nie powinno samo zastępować odpowiedzi na to pytanie.

W zapisie dopuszczenia rozdziel trzy ustalenia:

• Zadanie: przygotowanie szkicu na podstawie wskazanej wiadomości, z oceną człowieka przed wysyłką.
• Dostęp: konkretna skrzynka i materiały potrzebne do odpowiedzi, z rozpoznawalnym kontem używanym przez proces.
• Działanie: narzędzia dopuszczone do tego zadania i czynności, które pozostają poza zakresem, nawet jeżeli serwer potrafi je wykonać.

Taki zapis pozwala ocenić zmianę bez dyskusji o tym, czy ktoś kiedyś „zgodził się na MCP”. Protokół jest sposobem połączenia. Decyzja dotyczy konkretnego wykorzystania danych i wykonania czynności.

Zmiana może schować się w opisie albo parametrze

Porównaj stan zatwierdzony z obecnym. Osobno wskaż narzędzia dodane, usunięte i zmienione. Dla zmienionej pozycji pokaż także tekst opisu, wejście i znaczenie wyniku. Krótszy opis nie musi oznaczać prostszej czynności, a nowy opcjonalny parametr może zmienić domyślne zachowanie wszystkich dotychczasowych wywołań.

Rozważ trzy rodzaje zmian w naszej poczcie. Dodano narzędzie wysyłki. W istniejącym narzędziu pojawił się wybór odbiorców, domyślnie obejmujący cały wątek. Albo opis zaczął zachęcać model do wysłania gotowego materiału po znalezieniu odpowiedzi. Każda sytuacja wymaga innej kontroli: dostępności nowej funkcji, znaczenia parametru oraz sposobu doboru czynności przez aplikację.

Przy parametrze sprawdź brak wartości, pustą wartość i wartość podaną jawnie. Jeżeli zatwierdzona próba dotyczyła wyłącznie konkretnej listy adresatów, nie potwierdza zachowania bez tej listy. W materiałach odbiorowych zapisz, co dokładnie wysłano do narzędzia i jaki skutek uzyskano w uzgodnionym środowisku. Zdanie modelu „przygotowałem szkic” nie jest dowodem, że wiadomość pozostała szkicem.

Znaczenie wyniku też może się zmienić. Pole, które wcześniej oznaczało identyfikator szkicu, po aktualizacji może wskazywać wysłaną wiadomość. Kontrola składni nadal przejdzie, jeśli w obu przypadkach wartością jest tekst. Oceniający musi znać znaczenie pola w danej wersji i porównać je z rzeczywistym stanem sprawy. Ładny obiekt danych bywa bardzo uprzejmym opakowaniem złego skutku.

Autorzy oficjalnego bloga MCP o adnotacjach narzędzi podkreślają, że są one wskazówkami, a nie gwarancją zachowania czy mechanizmem wymuszania granic. Deklaracja readOnlyHint sama nie blokuje zapisu. W przeglądzie oddziel więc informację opisową od kontroli faktycznie ograniczającej wykonanie.

Podobnie potraktuj opis „bezpieczne wyszukiwanie”. Zapytaj, jaki zasób jest przeszukiwany, co opuszcza środowisko i czy wywołanie może wykonać dodatkową czynność. Opis ma pomagać zrozumieć funkcję. Nie powinien sam nadawać uprawnień ani rozstrzygać, że nowy zakres został już zaakceptowany.

Sprawdzenie katalogu uzupełnia kontrolę obcych instrukcji odnajdywanych w dokumentach. O prompt injection w firmowych materiałach warto przeczytać wtedy, gdy treść źródła próbuje kierować działaniem modelu. Przy narzędziach oceniasz dodatkowo sam opis funkcji dostarczany aplikacji oraz rzeczywiste możliwości wykonania. Te drogi mogą się spotkać, lecz wymagają osobnych dowodów.

Zapisz osobno moment kontroli katalogu i moment wykonania czynności. Zespół mógł przeczytać katalog rano, podczas gdy późniejsze wywołanie korzysta już z innego stanu. W raporcie pokaż, do którego momentu odnosi się porównanie i czy oceniana próba rzeczywiście używała tego zestawu. Jeśli nie da się tego odtworzyć, zapisz granicę dowodu. Nie przedstawiaj porannego odczytu jako potwierdzenia wieczornego działania.

Uzgodnij, co dzieje się po wykryciu różnicy

Nie każda zmiana wymaga wstrzymania całego procesu. Poprawiona literówka w opisie może nie zmieniać działania, natomiast nowe miejsce zapisu albo wysyłka do dodatkowych odbiorców może wykraczać poza zatwierdzony zakres. Zapisz kryterium decyzji i osobę, która ją podejmuje. Ocena „zmiana drobna” powinna wskazywać sprawdzony skutek, a nie liczbę zmienionych znaków.

Dla nowej funkcji poza zakresem ustal stan oczekiwania: narzędzie pozostaje niedostępne dla procesu do czasu decyzji albo cała integracja przechodzi do uzgodnionego trybu ograniczonego. Wybór zależy od możliwości konkretnego rozwiązania. W próbie sprawdź faktyczny rezultat tego ustawienia, także po ponownym połączeniu i odświeżeniu katalogu.

Usunięcie pozycji wymaga innego pytania. Czy zadanie kończy się jawnym brakiem, czy model próbuje zastąpić narzędzie innym, szerszym? Po utracie funkcji przygotowującej szkic nie powinien sam wybierać wysyłki tylko dlatego, że oba opisy wspominają odpowiedź na wiadomość. Zastępstwo musi mieścić się w zakresie zlecenia i uzgodnionych uprawnieniach.

Jeżeli zmiana nie przejdzie odbioru, wskaż realny sposób ograniczenia skutku. Przywrócenie wcześniejszej konfiguracji może zatrzymać kolejne wysyłki, ale nie cofnie już wysłanej wiadomości. Oddziel zatem powrót do poprzedniego sposobu pracy od uporządkowania czynności wykonanych w zmienionym zakresie. W próbie pocztowej sprawdź, czy po blokadzie nie pozostaje kolejka oczekujących wysyłek. Sam napis „integracja wyłączona” nie wyjaśnia stanu takiej kolejki.

Granice wykonania opisuje tekst o piaskownicy agenta AI i dostępie do plików oraz sieci. Piaskownica to wydzielone środowisko z określonym dostępem do zasobów. W tym przeglądzie sprawdź, czy ograniczenie obejmuje również drogę przez zewnętrzny serwer. Zakaz lokalnego zapisu nie wyjaśnia jeszcze, co może zrobić narzędzie w innym systemie.

Ta sama uwaga dotyczy wyłączenia plików z pracy asystenta kodu. Gdy nowa funkcja potrafi odczytać repozytorium przez osobną usługę, dawny filtr lokalnego katalogu może nie opisywać tej drogi. Porównaj zakres obu połączeń. Nie dopisuj wyniku „plik niedostępny” wyłącznie na podstawie ustawienia jednej warstwy.

Zostaw dowód dotyczący konkretnego stanu

Próbę pocztową zaplanuj na kontrolowanym koncie i wiadomościach przygotowanych do odbioru, bez przypadkowych adresatów. Zachowaj stan katalogu przed zmianą i po niej. Następnie użyj tego samego polecenia, które wcześniej miało kończyć się szkicem. Sprawdź wybrane narzędzie, parametry oraz wynik w skrzynce. To proponowany przebieg kontroli, nie opis testu wykonanego w tym artykule.

Dodaj osobny przypadek z pominiętym nowym parametrem opcjonalnym. Dzięki temu zobaczysz, czy aktualizacja zachowała stare znaczenie wywołania. Potem sprawdź zachowanie po odświeżeniu połączenia. Jeżeli aplikacja pokazuje dawny opis, ale wywołuje już zmienione działanie, dowód z samego interfejsu jest niepełny. W raporcie rozdziel stan widziany przez użytkownika od czynności wykonanej przez integrację.

Jeżeli z integracji korzystają różne konta, sprawdź osobno każdą rolę objętą odbiorem. Osoba przygotowująca materiał może widzieć wyłącznie szkic, a operator z szerszym dostępem również wysyłkę. Nie zaliczaj wyniku pierwszej próby jako potwierdzenia drugiej. Zanotuj rolę, konfigurację i oczekiwane działanie. Dzięki temu po następnej aktualizacji będzie wiadomo, którą część sprawdzić ponownie, zamiast odtwarzać całą historię z pamięci zespołu.

Przy poczcie wynik oceniaj także według wątku i rzeczywistych odbiorców odpowiedzi AI. Poprawna treść skierowana do niewłaściwych osób nie spełnia zadania. Nowe narzędzie „odpowiedz wszystkim” szczególnie dobrze pokazuje, dlaczego nazwa akcji, parametry i skutek powinny znaleźć się w jednym zapisie odbioru.

W rejestrze umieść rozpoznawalną konfigurację, ocenianą różnicę, zakres próby, decyzję i jej właściciela. Nie przechowuj w nim sekretów ani całej skrzynki tylko po to, by udowodnić zmianę jednego narzędzia. Powiązanie z wersjami instrukcji i właścicielami biblioteki promptów pomoże odtworzyć polecenie użyte w próbie, ale nie zastąpi wersji samej integracji.

Do rozmowy o zakresie Aeneia Audit przynieś dawny zapis dopuszczenia, obecny katalog i jeden proces, w którym zmiana może mieć skutek. Można wtedy rozstrzygnąć, co nadal działa w uzgodnionych granicach, a co wymaga nowej decyzji. W naszym przykładzie ikona pozostała zielona, choć zmienił się zakres działania. Zapis odbioru powinien pozwalać rozpoznać tę różnicę bez uruchamiania wysyłki na prawdziwej korespondencji.