żądania wielokrotnego obiegu

Wzorzec MCP zastępujący żądania inicjowane przez serwer. Serwer kończy wywołanie wynikiem niosącym listę pytań i nieprzejrzysty blok stanu; klient zbiera odpowiedzi i ponawia pierwotne wywołanie z odesłanym stanem. Pasuje do bezstanowego rdzenia — dowolna instancja serwera może podjąć pracę.

W Polsce nazywane też:

wielokrotny obiegżądanie z dopytaniemSEP-2322

Jeśli serwer nie może już inicjować żądań, a mimo to musi czasem o coś zapytać — potrzebny jest inny wzorzec. MRTR jest właśnie nim.

Jak działa

Zamiast wysyłać osobne żądanie do klienta, serwer kończy bieżące wywołanie wynikiem oznaczającym, że potrzebuje danych wejściowych. Wynik ten niesie listę pytań oraz nieprzejrzysty blok stanu. Klient zbiera odpowiedzi od użytkownika i ponawia pierwotne wywołanie, dołączając odpowiedzi oraz zwrócony wcześniej stan w niezmienionej postaci.

Blok stanu jest dla klienta nieczytelny — jego zadaniem jest wyłącznie odesłać go dokładnie takim, jaki dostał.

Dlaczego tak

Wzorzec pasuje do bezstanowego rdzenia specyfikacji. Skoro cały stan podróżuje w treści komunikatu, żadna instancja serwera nie musi utrzymywać otwartego połączenia ani pamiętać, co się działo. Dowolna instancja może podjąć pracę tam, gdzie została przerwana — co dopiero umożliwia sensowne skalowanie poziome.

Dodatkowo jedno żądanie może połączyć kilka pytań naraz, zamiast wykonywać osobne obiegi dla każdego z osobna.

Co zastępuje

MRTR wchodzi w miejsce żądań inicjowanych przez serwer, czyli dotychczasowych mechanizmów elicitation, sampling i roots. Nie zmienia tego, o co serwer może poprosić — zmienia sposób, w jaki prośba jest dostarczana.

Status

Wzorzec wprowadzono jako SEP-2322. Warto śledzić dokumentację, bo nazwy pól w schemacie mogą jeszcze ulegać zmianom.

wersjonowanie specyfikacji MCPWersje specyfikacji MCP oznaczane datą (np. 2025-11-25, 2026-07-28) i uzgadniane podczas inicjalizacji połączenia. Kolejne rewizje wprowadzały zmiany niewsteczne, więc serwer napisany pod jedną wersję nie musi działać z klientem obsługującym inną. Od 2026-07-28 obowiązuje polityka deprecjacji z minimum dwunastomiesięcznym oknem.bezstanowy rdzeń MCPArchitektura wprowadzona w specyfikacji 2026-07-28, w której stan podróżuje w treści komunikatów zamiast być trzymany przez konkretną instancję serwera. Umożliwia skalowanie poziome i odporność na zerwane połączenia. Towarzyszą jej nagłówki HTTP z nazwą metody i narzędzia oraz deterministyczna kolejność list, stabilizująca cache promptu.sampling MCPMożliwość MCP, w której serwer prosi klienta o wykonanie zapytania do modelu — korzystając z modelu i budżetu klienta, nie własnego. Wybór modelu i kontrola nad zapytaniem należą do klienta. Zdeprecjonowane w specyfikacji 2026-07-28. To coś innego niż sampling w znaczeniu wyboru tokenu z rozkładu.dopytanie użytkownikaMechanizm MCP pozwalający serwerowi zatrzymać wykonanie i poprosić użytkownika o dane — doprecyzowanie, potwierdzenie, brakujący parametr. Zaprojektowany z człowiekiem w pętli: klient musi pokazać, który serwer pyta, i umożliwić odrzucenie. Pytanie może pojawić się wyłącznie w trakcie obsługi żądania zainicjowanego przez użytkownika.prymitywy MCPPodstawowe typy możliwości w MCP. Po stronie serwera: narzędzia (funkcje do wywołania), zasoby (dane do odczytu po URI) i prompty (szablony). Po stronie klienta: elicitation, sampling i roots, przy czym dwa ostatnie zdeprecjonowano w specyfikacji 2026-07-28.