What problem do stateful MCP client capabilities solve on Amazon Bedrock AgentCore Runtime?

Stateful Model Context Protocol (MCP) client capabilities on Amazon Bedrock AgentCore Runtime address the critical limitations of previous stateless AI agent implementations. Stateless agents struggled with interactive, multi-turn workflows, as they couldn't pause mid-execution to solicit user input for clarification, request dynamic large language model (LLM)-generated content, or provide real-time progress updates during lengthy operations. Each request was independent, lacking shared context. This new feature fundamentally transforms agent interactions by enabling bidirectional conversations, allowing agents to maintain conversational threads, gather necessary input precisely when needed, generate dynamic content on the fly, and transparently inform users about ongoing processes. This leads to the development of significantly more responsive, intelligent, and user-centric AI applications capable of complex, adaptive workflows.

How does the transition from stateless to stateful mode work on AgentCore Runtime?

The transition to stateful mode within Amazon Bedrock AgentCore Runtime is initiated by a simple configuration adjustment: setting `stateless_http=False` when starting your MCP server. Once enabled, AgentCore Runtime provisions a dedicated microVM for each individual user session. This microVM is designed for persistence throughout the session's duration, which can last up to 8 hours or expire after 15 minutes of inactivity, ensuring isolated CPU, memory, and filesystem resources for each session. Continuity across interactions is maintained through a unique `Mcp-Session-Id` header. This ID is established during the initial handshake and subsequently included by the client in all follow-up requests, ensuring they are accurately routed back to the correct, persistent session, thereby preserving context and enabling complex, interactive dialogues.

What is Elicitation, and how does it enhance AI agent interactions?

Elicitation is a powerful stateful MCP capability that allows an AI agent (acting as the MCP server) to intelligently pause its ongoing execution and request specific, structured input directly from the user via the client. This significantly enhances interactive agent workflows by enabling agents to ask targeted questions at precise, opportune moments within their operational flow. For example, an agent might use elicitation to confirm a decision, gather user preferences, or collect particular data values that are contingent on preceding steps. The feature supports two robust modes: 'Form mode' for direct structured data collection through the MCP client, and 'URL mode' for secure, out-of-band interactions that require directing the user to an external URL (e.g., for OAuth or sensitive credential entry). The user's response – whether accepting, declining, or canceling the request – is then returned to the server, allowing the agent to dynamically adapt its workflow based on real-time human feedback.

How does Sampling capability benefit AI agents without managing LLM credentials?

Sampling equips the MCP server with the ability to request sophisticated large language model (LLM)-generated content directly from the client using the `sampling/createMessage` mechanism. A key benefit is that the MCP server itself does not need to manage its own LLM credentials, API keys, or direct integrations with various LLM providers. Instead, the server simply provides a well-formed prompt and any optional model preferences to the client. The client then acts as an intelligent intermediary, forwarding this request to its connected LLM and returning the generated response back to the server. This abstraction allows AI agents to seamlessly leverage powerful language model capabilities for tasks such as crafting personalized summaries, generating natural-language explanations from complex structured data, or producing context-aware recommendations, all while simplifying the operational overhead and security concerns associated with LLM management on the server side.

Amazon Bedrock: Możliwości stanowych klientów MCP w środowisku uruchomieniowym AgentCore

Udoskonalanie agentów AI: Przejście na stanowy MCP w Amazon Bedrock

Agenci AI szybko ewoluują, jednak ich pełny potencjał był często ograniczany przez bezstanowe implementacje, zwłaszcza w scenariuszach wymagających interakcji z użytkownikiem w czasie rzeczywistym, dynamicznego generowania treści lub bieżących aktualizacji postępu. Deweloperzy tworzący zaawansowane agenty AI często napotykają wyzwania, gdy przepływy pracy muszą zostać wstrzymane, zebrać wyjaśnienia lub zgłosić status podczas długotrwałych operacji. Sztywna, jednokierunkowa natura bezstanowego wykonania ogranicza rozwój prawdziwie interaktywnych i responsywnych aplikacji AI.

Teraz Amazon Bedrock AgentCore Runtime wprowadza przełomowe możliwości stanowych klientów Model Context Protocol (MCP), zmieniając sposób, w jaki agenci AI komunikują się z użytkownikami i dużymi modelami językowymi (LLM). Ta kluczowa aktualizacja uwalnia agentów od ograniczeń komunikacji bezstanowej, umożliwiając złożone, wieloturnusowe i wysoce interaktywne przepływy pracy. Dzięki integracji kluczowych funkcji klienta MCP – elicytacji, próbkowania i powiadomień o postępach – Bedrock AgentCore Runtime ułatwia dwukierunkowe rozmowy między serwerami a klientami MCP, torując drogę do inteligentniejszych, zorientowanych na użytkownika rozwiązań AI.

Od bezstanowego do stanowego: Uwalnianie interaktywnych przepływów pracy agentów

Wcześniej obsługa serwera MCP w AgentCore działała w trybie bezstanowym, gdzie każde żądanie HTTP funkcjonowało niezależnie, pozbawione jakiegokolwiek wspólnego kontekstu. Chociaż uprościło to wdrożenie dla podstawowych serwerów narzędziowych, poważnie ograniczyło scenariusze wymagające ciągłości konwersacji, wyjaśnień od użytkownika w trakcie przepływu pracy lub raportowania postępów w czasie rzeczywistym. Serwer po prostu nie mógł utrzymywać wątku konwersacji w oddzielnych żądaniach, co utrudniało rozwój prawdziwie interaktywnych agentów.

Pojawienie się możliwości stanowych klientów MCP fundamentalnie zmienia ten paradygmat. Ustawiając stateless_http=False podczas uruchamiania serwera, AgentCore Runtime udostępnia dedykowaną mikro-maszynę wirtualną (microVM) dla każdej sesji użytkownika. Ta microVM zachowuje się przez cały czas trwania sesji – do 8 godzin lub 15 minut braku aktywności zgodnie z ustawieniem idleRuntimeSessionTimeout – zapewniając izolację procesora, pamięci i systemu plików między sesjami. Ciągłość jest utrzymywana poprzez nagłówek Mcp-Session-Id, który serwer dostarcza podczas inicjalizacji, a klient dołącza do wszystkich kolejnych żądań, aby skierować je z powrotem do tej samej sesji. To dedykowane, trwałe środowisko pozwala agentom pamiętać kontekst, żądać danych wejściowych od użytkownika, generować dynamiczne treści LLM i dostarczać ciągłe aktualizacje.

Poniższa tabela podsumowuje kluczowe różnice między trybem bezstanowym a stanowym:

	Tryb bezstanowy	Tryb stanowy
Ustawienie `stateless_http`	`TRUE`	`FALSE`
Izolacja sesji	Dedykowana mikro-maszyna wirtualna na sesję	Dedykowana mikro-maszyna wirtualna na sesję
Czas życia sesji	Do 8 godzin; 15 min bezczynności	Do 8 godzin; 15 min bezczynności
Możliwości klienta	Nieobsługiwane	Elicytacja, próbkowanie, powiadomienia o postępach
Zalecane dla	Proste usługi narzędziowe	Interaktywne, wieloturnusowe przepływy pracy

Gdy sesja wygaśnie lub serwer zostanie ponownie uruchomiony, kolejne żądania z poprzednim identyfikatorem sesji zwrócą błąd 404. W tym momencie klienci muszą ponownie zainicjalizować połączenie, aby uzyskać nowy identyfikator sesji i rozpocząć nową sesję. Zmiana konfiguracji w celu włączenia trybu stanowego to pojedyncza flaga w uruchamianiu serwera:

mcp.run( transport="streamable-http", host="0.0.0.0", port=8000, stateless_http=False # Włącz tryb stanowy)

Poza tą flagą, trzy możliwości klienta stają się automatycznie dostępne, gdy klient MCP zadeklaruje ich obsługę podczas uzgadniania (handshake) inicjalizacji.

Głębsze spojrzenie na nowe możliwości klienta: Elicytacja, próbkowanie i postępy

Wraz z przejściem w tryb stanowy, Amazon Bedrock AgentCore Runtime udostępnia trzy potężne możliwości klienta ze specyfikacji MCP, z których każda została zaprojektowana w celu adresowania odrębnych wzorców interakcji kluczowych dla zaawansowanych agentów AI. Te możliwości przekształcają to, co było kiedyś sztywnym, jednokierunkowym wykonaniem poleceń, w płynny, dwukierunkowy dialog między serwerem a klientami MCP. Ważne jest, aby pamiętać, że te funkcje są opcjonalne, co oznacza, że klienci deklarują ich obsługę podczas inicjalizacji, a serwery mogą wykorzystywać tylko te możliwości, które zostały zareklamowane przez połączonego klienta.

Elicytacja: Włączanie dynamicznego wprowadzania danych przez użytkownika w agentach AI

Elicytacja stanowi kamień węgielny interaktywnej AI, pozwalając serwerowi MCP na rozważne wstrzymanie swojego wykonania i zażądanie określonych, ustrukturyzowanych danych wejściowych bezpośrednio od użytkownika za pośrednictwem klienta. Ta możliwość umożliwia narzędziu zadawanie precyzyjnych pytań w dogodnych momentach w ramach jego przepływu pracy, czy to w celu potwierdzenia decyzji, zebrania preferencji użytkownika, czy zebrania wartości wynikającej z poprzednich operacji. Serwer inicjuje to, wysyłając żądanie elicitation/create JSON-RPC, które zawiera czytelny dla człowieka komunikat i opcjonalny requestedSchema określający oczekiwaną strukturę odpowiedzi.

Specyfikacja MCP przewiduje dwa solidne tryby elicytacji:

Tryb formularza (Form mode): Jest to idealne rozwiązanie do zbierania ustrukturyzowanych danych bezpośrednio za pośrednictwem klienta MCP, takich jak parametry konfiguracyjne, preferencje użytkownika lub proste potwierdzenia, gdzie nie są zaangażowane wrażliwe dane.
Tryb URL (URL mode): W przypadku interakcji wymagających bezpiecznego procesu poza pasmem, takich jak przepływy OAuth, przetwarzanie płatności lub wprowadzanie poufnych danych uwierzytelniających, tryb URL kieruje użytkownika do zewnętrznego adresu URL. Zapewnia to, że wrażliwe informacje całkowicie omijają klienta MCP, zwiększając bezpieczeństwo i zgodność.

Po otrzymaniu żądania elicytacji, klient renderuje odpowiedni interfejs wprowadzania danych. Kolejna akcja użytkownika wyzwala trzyczynny model odpowiedzi z powrotem do serwera: accept (użytkownik dostarczył żądane dane), decline (użytkownik wyraźnie odrzucił żądanie) lub cancel (użytkownik odrzucił monit bez dokonania wyboru). Inteligentne serwery są zaprojektowane do grzecznego obsługiwania każdego z tych scenariuszy, zapewniając solidne i przyjazne dla użytkownika doświadczenie. Na przykład narzędzie add_expense_interactive, jak zademonstrowano w materiale źródłowym, może prowadzić użytkownika przez serię pytań – kwotę, opis, kategorię i ostateczne potwierdzenie – przed zatwierdzeniem danych do backendu, takiego jak Amazon DynamoDB. Każdy krok wykorzystuje modele Pydantic do zdefiniowania oczekiwanych danych wejściowych, które FastMCP bezproblemowo konwertuje na schemat JSON wymagany dla żądania elicitation/create.

Próbkowanie i powiadomienia o postępach: Zwiększanie interakcji LLM i przejrzystości

Oprócz bezpośredniej interakcji z użytkownikiem, próbkowanie wyposaża serwer MCP w możliwość żądania treści generowanych przez LLM bezpośrednio od klienta za pośrednictwem sampling/createMessage. Jest to krytyczny mechanizm, ponieważ pozwala logice narzędzia na serwerze wykorzystywać potężne możliwości modeli językowych bez konieczności zarządzania własnymi poświadczeniami LLM lub bezpośrednimi integracjami API. Serwer po prostu dostarcza prompt i opcjonalne preferencje modelu klientowi. Klient działa następnie jako inteligentny pośrednik, przekazując to żądanie do połączonego LLM i zwracając wygenerowaną odpowiedź. Otwiera to mnóstwo praktycznych zastosowań, w tym tworzenie spersonalizowanych podsumowań, generowanie wyjaśnień w języku naturalnym ze ustrukturyzowanych danych lub tworzenie rekomendacji uwzględniających kontekst, a wszystko to przy jednoczesnym uproszczeniu narzutu operacyjnego i kwestii bezpieczeństwa związanych z zarządzaniem LLM po stronie serwera.

W przypadku operacji, które trwają dłużej, powiadomienia o postępach stają się nieocenione. Ta możliwość pozwala serwerowi MCP na raportowanie przyrostowych aktualizacji podczas długotrwałych zadań. Wykorzystując ctx.report_progress(progress, total), serwer może emitować ciągłe aktualizacje, które klienci mogą przekształcić w wizualne informacje zwrotne, takie jak pasek postępu lub wskaźnik statusu. Niezależnie od tego, czy chodzi o przeszukiwanie ogromnych źródeł danych, czy wykonywanie złożonych zadań obliczeniowych, przejrzyste aktualizacje postępu zapewniają, że użytkownicy pozostają poinformowani, zapobiegając frustracji i poprawiając ogólne wrażenia użytkownika, zamiast pozostawiać ich wpatrujących się w pusty ekran i zastanawiających się, czy system nadal działa.

Zabezpieczanie przyszłości rozwoju agentów AI dzięki środowisku uruchomieniowemu Bedrock AgentCore Runtime

Wprowadzenie możliwości stanowych klientów MCP w środowisku uruchomieniowym Amazon Bedrock AgentCore Runtime stanowi znaczący krok naprzód w rozwoju agentów AI. Przekształcając dotychczas bezstanowe interakcje w dynamiczne, dwukierunkowe rozmowy, AWS umożliwia deweloperom tworzenie inteligentniejszych, bardziej responsywnych i przyjaznych dla użytkownika aplikacji AI. Te możliwości – elicytacja dla ukierunkowanych danych wejściowych od użytkownika, próbkowanie dla generowania LLM na żądanie oraz powiadomienia o postępach dla przejrzystości w czasie rzeczywistym – łącznie otwierają nową erę interaktywnych przepływów pracy agentów. W miarę ewolucji AI, te podstawowe możliwości będą kluczowe dla tworzenia wyrafinowanej operacjonalizacji agentowej AI, która może bezproblemowo integrować się ze złożonymi procesami biznesowymi, dostosowywać się do potrzeb użytkowników i dostarczać wyjątkową wartość.