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: Būseną palaikančios MCP kliento galimybės AgentCore Runtime aplinkoje

DI agentų tobulinimas: perėjimas prie būseną palaikančio MCP Amazon Bedrock aplinkoje

DI agentai sparčiai tobulėja, tačiau jų visas potencialas dažnai būdavo ribojamas be būsenos veikiančių diegimų, ypač scenarijuose, reikalaujančiuose realaus laiko vartotojo sąveikos, dinamiško turinio generavimo ar nuolatinių eigos atnaujinimų. Kuriant sudėtingus DI agentus, kūrėjai dažnai susiduria su iššūkiais, kai darbo eigas reikia sustabdyti, surinkti patikslinimus arba pranešti apie būseną ilgai trunkančių operacijų metu. Griežtas, vienpusis be būsenos vykdymo pobūdis riboja iš tiesų interaktyvių ir reaguojančių DI programų kūrimą.

Dabar, Amazon Bedrock AgentCore Runtime pristato novatoriškas būseną palaikančias Modelio konteksto protokolo (MCP) kliento galimybes, keičiančias DI agentų sąveiką su vartotojais ir dideliais kalbos modeliais (LLM). Šis esminis atnaujinimas išlaisvina agentus nuo bendravimo be būsenos apribojimų, įgalindamas sudėtingas, daugiapakopes ir labai interaktyvias darbo eigas. Integruodamas esmines MCP kliento funkcijas – informacijos išsiaiškinimą, atrankos funkciją ir eigos pranešimus – Bedrock AgentCore Runtime palengvina dvipusius pokalbius tarp MCP serverių ir klientų, atverdamas kelią išmanesniems, į vartotoją orientuotiems DI sprendimams.

Nuo be būsenos iki būseną palaikančio: interaktyvių agentų darbo eigų atrakinimas

Anksčiau MCP serverio palaikymas AgentCore veikė be būsenos režimu, kai kiekviena HTTP užklausa veikė nepriklausomai, be jokio bendro konteksto. Nors tai supaprastino diegimą pagrindiniams įrankių serveriams, tai smarkiai apribojo scenarijus, reikalaujančius pokalbio tęstinumo, vartotojo patikslinimų darbo eigos viduryje arba realaus laiko eigos ataskaitų. Serveris tiesiog negalėjo palaikyti pokalbio gijos tarp atskirų užklausų, stabdydamas tikrai interaktyvių agentų kūrimą.

Atsiradus būseną palaikančioms MCP kliento galimybėms, iš esmės pasikeičia ši paradigma. Nustačius stateless_http=False serverio paleidimo metu, AgentCore Runtime kiekvienai vartotojo sesijai numato dedikuotą mikroVM. Ši mikroVM išlieka visą sesijos trukmę – iki 8 valandų arba 15 minučių neveiklumo pagal idleRuntimeSessionTimeout nustatymą – užtikrindama procesoriaus, atminties ir failų sistemos izoliaciją tarp sesijų. Tęstinumas palaikomas per Mcp-Session-Id antraštės lauką, kurį serveris pateikia inicijavimo metu, o klientas įtraukia į visas tolesnes užklausas, kad būtų nukreiptas atgal į tą pačią sesiją. Ši dedikuota, nuolatinė aplinka leidžia agentams prisiminti kontekstą, rinkti vartotojo informaciją, generuoti dinamišką LLM turinį ir teikti nuolatinius atnaujinimus.

Toliau pateiktoje lentelėje apibendrinami pagrindiniai skirtumai tarp be būsenos ir būseną palaikančio režimų:

	Be būsenos režimas	Būseną palaikantis režimas
`stateless_http` nustatymas	`TRUE`	`FALSE`
Sesijos izoliavimas	Dedikuota mikroVM kiekvienai sesijai	Dedikuota mikroVM kiekvienai sesijai
Sesijos trukmė	Iki 8 valandų; 15 min. neveiklumo laikas	Iki 8 valandų; 15 min. neveiklumo laikas
Kliento galimybės	Nepalaikoma	Informacijos išsiaiškinimas, atrankos funkcija, eigos pranešimai
Rekomenduojama	Paprastiems įrankių serveriams	Interaktyvioms, daugiapakopėms darbo eigoms

Kai sesija baigiasi arba serveris iš naujo paleidžiamas, tolesnės užklausos su ankstesniu sesijos ID grąžins 404 klaidą. Tuomet klientai privalo iš naujo inicijuoti ryšį, kad gautų naują sesijos ID ir pradėtų naują sesiją. Konfigūracijos pakeitimas, leidžiantis įjungti būseną palaikantį režimą, yra vienas žymeklis jūsų serverio paleidimo metu:

mcp.run( transport="streamable-http", host="0.0.0.0", port=8000, stateless_http=False # Enable stateful mode)

Be šio žymeklio, trys kliento galimybės tampa automatiškai prieinamos, kai MCP klientas deklaruoja jų palaikymą inicijavimo rankos paspaudimo metu.

Gilus naujų kliento galimybių nagrinėjimas: informacijos išsiaiškinimas, atrankos funkcija ir eiga

Perėjus į būseną palaikantį režimą, Amazon Bedrock AgentCore Runtime atrakina tris galingas MCP specifikacijos kliento galimybes, kurių kiekviena skirta atskiriems sąveikos modeliams, kritiškai svarbiems pažangiems DI agentams. Šios galimybės paverčia kadaise standų, vienpusį komandų vykdymą į lankstų, dvipusį dialogą tarp MCP serverio ir jo prijungtų klientų. Svarbu pažymėti, kad šios funkcijos yra pasirenkamos, o tai reiškia, kad klientai deklaruoja savo palaikymą inicijavimo metu, o serveriai turi naudoti tik tas galimybes, kurias prijungtas klientas yra paskelbęs.

Informacijos išsiaiškinimas: dinaminio vartotojo duomenų įvedimo įgalinimas DI agentuose

Informacijos išsiaiškinimas yra interaktyvaus DI pagrindas, leidžiantis MCP serveriui protingai sustabdyti savo vykdymą ir per klientą paprašyti konkrečios, struktūrizuotos informacijos iš vartotojo. Ši galimybė suteikia įrankiui galimybę užduoti tikslius klausimus tinkamais momentais jo darbo eigoje, ar tai būtų sprendimo patvirtinimas, vartotojo nuostatos surinkimas ar vertės, gautos iš ankstesnių operacijų, rinkimas. Serveris tai inicijuoja siųsdamas elicitation/create JSON-RPC užklausą, kurioje yra žmogui suprantamas pranešimas ir pasirinktinis requestedSchema, apibrėžiantis laukiamą atsakymo struktūrą.

MCP specifikacija numato du patikimus informacijos išsiaiškinimo režimus:

Formos režimas: Tai idealiai tinka struktūrizuotiems duomenims tiesiogiai rinkti per MCP klientą, pvz., konfigūracijos parametrams, vartotojo nuostatoms ar paprastiems patvirtinimams, kai nėra jautrių duomenų.
URL režimas: Sąveikoms, kurioms reikalingas saugus, išorinis procesas, pvz., OAuth srautai, mokėjimų apdorojimas ar jautrių prisijungimo duomenų įvedimas, URL režimas nukreipia vartotoją į išorinį URL. Tai užtikrina, kad jautri informacija visiškai apeina MCP klientą, didindama saugumą ir atitiktį.

Gavęs informacijos išsiaiškinimo užklausą, klientas atvaizduoja tinkamą įvesties sąsają. Vėlesnis vartotojo veiksmas sukelia trijų veiksmų atsakymo modelį atgal į serverį: accept (vartotojas pateikė prašomus duomenis), decline (vartotojas aiškiai atmetė užklausą) arba cancel (vartotojas atmetė raginimą nepasirinkęs). Išmanieji serveriai yra sukurti taip, kad elegantiškai tvarkytų kiekvieną iš šių scenarijų, užtikrindami patikimą ir patogią vartotojo patirtį. Pavyzdžiui, add_expense_interactive įrankis, kaip parodyta pirminėje medžiagoje, gali nukreipti vartotoją per klausimų seriją – sumą, aprašymą, kategoriją ir galutinį patvirtinimą – prieš įsipareigojant duomenis į galinę sistemą, pvz., Amazon DynamoDB. Kiekviename žingsnyje naudojami Pydantic modeliai, apibrėžiantys laukiamą įvestį, kurią FastMCP sklandžiai paverčia JSON Schema, reikalinga elicitation/create užklausai.

Atrankos funkcija ir eigos pranešimai: LLM sąveikos ir skaidrumo didinimas

Be tiesioginės vartotojo sąveikos, atrankos funkcija suteikia MCP serveriui galimybę prašyti LLM sugeneruoto turinio tiesiogiai iš kliento, naudojant sampling/createMessage. Tai yra kritiškai svarbus mechanizmas, nes jis leidžia įrankio logikai serveryje išnaudoti galingas kalbos modelio galimybes, nereikalaujant valdyti savo LLM prisijungimo duomenų ar tiesioginių API integracijų. Serveris tiesiog pateikia užklausą ir pasirinktines modelio nuostatas klientui, o klientas, veikdamas kaip tarpininkas, persiunčia šią užklausą savo prijungtam LLM ir grąžina sugeneruotą atsakymą. Tai atveria daugybę praktinių pritaikymų, įskaitant suasmenintų santraukų kūrimą, natūralios kalbos paaiškinimų generavimą iš sudėtingų struktūrizuotų duomenų arba konteksto atžvilgiu tinkamų rekomendacijų teikimą, atsižvelgiant į vykstantį pokalbį.

Operacijoms, kurios trunka ilgiau, eigos pranešimai tampa neįkainojami. Ši galimybė leidžia MCP serveriui pranešti apie laipsniškus atnaujinimus ilgai trunkančių užduočių metu. Naudodamas ctx.report_progress(progress, total), serveris gali nuolat teikti atnaujinimus, kuriuos klientai gali paversti vizualiniu grįžtamuoju ryšiu, pvz., eigos juosta arba būsenos indikatoriumi. Ar tai būtų paieška didelėse duomenų bazėse, ar sudėtingų skaičiavimo užduočių vykdymas, skaidrūs eigos atnaujinimai užtikrina, kad vartotojai būtų informuoti, užkertant kelią nusivylimui ir gerinant bendrą vartotojo patirtį, užuot palikus juos spoksoti į tuščią ekraną, galvojant, ar sistema vis dar veikia.

DI agentų kūrimo ateities užtikrinimas su Bedrock AgentCore Runtime

Būseną palaikančių MCP kliento galimybių pristatymas Amazon Bedrock AgentCore Runtime aplinkoje žymi didelį šuolį DI agentų kūrimo srityje. Paversdama anksčiau be būsenos veikiančias sąveikas į dinamiškus, dvipusius pokalbius, AWS suteikia kūrėjams galimybę kurti išmanesnes, labiau reaguojančias ir patogesnes vartotojui DI programas. Šios galimybės – informacijos išsiaiškinimas vadovaujamam vartotojo įvedimui, atrankos funkcija LLM generavimui pagal poreikį ir eigos pranešimai realaus laiko skaidrumui – kartu atveria naują interaktyvių agentų darbo eigų erą. DI toliau tobulėjant, šios pagrindinės galimybės bus itin svarbios kuriant sudėtingą agentinį DI diegimą, kuris galės sklandžiai integruotis į sudėtingus verslo procesus, prisitaikyti prie vartotojo poreikių ir teikti išskirtinę vertę.