Co przetestować, zanim serwer MCP trafi do użytkowników

Czego nie dowodzi działające demo

Demo może się udać z jednym użytkownikiem, hojnymi poświadczeniami, sprawnymi API i grzecznymi danymi wejściowymi. Każdy z tych warunków ukrywa całą klasę błędów. Pisz poniższe testy na serwerze stagingowym z tożsamościami testowymi: co najmniej dwoma zwykłymi użytkownikami o różnych prawach, jednym użytkownikiem bez dostępu i klientem zarejestrowanym tak, jak będą rejestrowani klienci produkcyjni.

Testy kontraktu: lista narzędzi to interfejs

Klienci, prompty i zestawy ewaluacyjne zależą od nazw, opisów i schematów narzędzi, więc cicha zmiana jest zmianą łamiącą zgodność. Aktualna specyfikacja pozwala, by lista narzędzi różniła się zależnie od autoryzacji żądania, dlatego zapisujesz jej stan osobno dla każdej tożsamości testowej.

• tools/list dla każdej tożsamości zgadza się z zatwierdzonym stanem, a każda różnica wymaga zaakceptowanej zmiany
• Każdy wynik strukturalny przechodzi walidację względem schematu wyjścia, czego specyfikacja wymaga, gdy taki schemat zadeklarowano
• Złe typy, nieoczekiwane pola i wartości spoza zakresu są odrzucane z komunikatem, który nazywa problem

Negatywne testy autoryzacji

Dla serwera chronionego przepływem autoryzacji HTTP każdy przypadek powinien sprawdzać odmowę, brak skutków ubocznych i brak danych w komunikacie błędu:

• Brak tokenu albo token wygasły: HTTP 401 z nagłówkiem WWW-Authenticate wskazującym metadane zasobu
• Poprawnie podpisany token wydany dla innego odbiorcy: odrzucony, bo serwer może przyjmować tylko tokeny przeznaczone dla siebie
• Ważny token bez potrzebnego scope'u: 403 z wyzwaniem insufficient_scope, jeśli twój serwer i klienci wdrażają zalecane rozszerzanie uprawnień
• Użytkownik A prosi przez poprawne narzędzie o rekord użytkownika B: odmowa bez treści rekordu w komunikacie
• Uchwyt stanu utworzony przez użytkownika A i użyty ponownie przez użytkownika B: odmowa, bo uchwyt nie może być uwierzytelnieniem
• Zapis bez pasującego zatwierdzenia albo z treścią zmienioną po zatwierdzeniu: odmowa
• Logi żądań systemów docelowych na stagingu identyfikują własną tożsamość testową serwera przez identyfikator klienta, odbiorcę lub odcisk klucza i nigdy nie zawierają tokenu przychodzącego ani wartości żadnego poświadczenia

Awarie w systemach za serwerem

MCP oddziela błędy protokołu, takie jak nieznane narzędzie czy źle zbudowane żądanie, od błędów wykonania narzędzia zwracanych z isError ustawionym na true. Testy powinny potwierdzać, że każda awaria trafia do właściwej kategorii. Wstrzykuj awarie na stagingu: timeouty systemu docelowego, odpowiedzi o przekroczeniu limitu, błędy serwera, ucięte odpowiedzi i odpowiedzi wolniejsze niż timeout klienta. W każdym przypadku narzędzie powinno zwrócić błąd wykonania, z którym model może coś zrobić, bez stack trace'a, wewnętrznej nazwy hosta czy tokenu w treści. Sprawdź też, czy własne limity wywołań serwera, których wymaga specyfikacja, rzeczywiście działają.

Testy zmian stanu dla każdego zapisu

1. 1

   Powtórzenie

   Wyślij to samo wywołanie potwierdzające dwa razy i oczekuj jednego rekordu. Potem pozwól, by zapis w systemie docelowym się udał, ale odpowiedź przekroczyła czas, ponów wywołanie i nadal oczekuj jednego rekordu.

2. 2

   Przerwanie

   Przerwij wieloetapowy zapis w połowie. Tam, gdzie zapisy w systemie docelowym nie mogą być atomowe, serwer utrwala stan częściowy, a krok kompensacji lub uzgadniania kończy albo odwraca pracę. Wynik narzędzia mówi, w jakim stanie jest sprawa.

3. 3

   Porzucenie

   Przygotuj zmianę i nigdy jej nie potwierdzaj: nic się nie zmienia. Potwierdź po wygaśnięciu uchwytu: błąd wykonania wyjaśnia, że potrzebna jest nowa propozycja.

4. 4

   Kolizja

   Zmień rekord w systemie biznesowym między przygotowaniem a potwierdzeniem. Narzędzie zgłasza konflikt zamiast nadpisywać.

Uruchamiaj te testy na sandboksie systemu biznesowego z syntetycznymi rekordami, nigdy na produkcji.

Plan w CI i przed aktualizacją klientów

MCP Inspector ma tryb wiersza poleceń dla skryptów z udokumentowanymi kodami wyjścia: 3, gdy serwer wymaga uwierzytelnienia, 5, gdy wywołanie narzędzia zwraca isError albo narzędzia brakuje, i 6, gdy ścisła kontrola znajdzie problem z przenośnością schematu. Ponieważ kod 5 oznacza zarówno odmowę wynikającą z reguły, jak i brak narzędzia, przykład sprawdza, że narzędzie istnieje i że błąd zawiera oczekiwany komunikat. Flaga stored-auth-only sprawia, że przebieg CI od razu kończy się błędem, zamiast czekać na logowanie w przeglądarce. Adres, narzędzia i komunikat są hipotetyczne.

set -euo pipefail
SERVER="https://mcp.staging.internal/mcp"
inspect() { npx @modelcontextprotocol/inspector --cli "$SERVER" --transport http --stored-auth-only "$@"; }

# Contract: both tools are listed, and schemas pass the strict check
inspect --method tools/list --format json \
  | jq -e '.result.tools | map(.name) | (index("find_orders") != null and index("prepare_return") != null)' > /dev/null
inspect --method tools/list --strict > /dev/null

# Business rule: a return outside the policy window comes back as a tool error (exit 5)
# with the expected rule message, not merely as a missing tool
set +e
out=$(inspect --method tools/call --tool-name prepare_return --tool-arg order_number=SO-00000001 --format json)
code=$?
set -e
test "$code" -eq 5
echo "$out" | jq -e '.result.isError == true and (.result.content[0].text | test("return window"))' > /dev/null

Inspector obejmuje zachowanie protokołu. Przypadki dotyczące tożsamości, zatwierdzeń i zmian stanu, łącznie ze sprawdzeniem, że odrzucone wywołanie niczego nie utworzyło w sandboksie, zwykle wymagają własnej uprzęży testowej, która przełącza użytkowników testowych i sprawdza system biznesowy. Uruchamiaj cały plan ponownie przy zmianie rewizji protokołu, SDK albo wspieranego klienta; rewizja z 2026-07-28 usunęła na przykład sesje protokołu, co psuje testy, które je zakładały.

Tworzenie serwerów MCP