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: მდგომარეობის მქონე MCP კლიენტის შესაძლებლობები AgentCore Runtime-ზე

AI აგენტების გაუმჯობესება: მდგომარეობის მქონე MCP-ზე გადასვლა Amazon Bedrock-ზე

AI აგენტები სწრაფად ვითარდებიან, თუმცა მათი სრული პოტენციალი ხშირად შეზღუდული იყო უმდგომარეო იმპლემენტაციებით, განსაკუთრებით იმ სცენარებში, რომლებიც საჭიროებენ მომხმარებლის რეალურ დროში ინტერაქციას, დინამიური კონტენტის გენერირებას ან მიმდინარე პროგრესის განახლებებს. დეველოპერები, რომლებიც ქმნიან დახვეწილ AI აგენტებს, ხშირად აწყდებიან გამოწვევებს, როდესაც სამუშაო პროცესები უნდა შეჩერდეს, მოითხოვოს განმარტება ან მოახდინოს სტატუსის შესახებ მოხსენება ხანგრძლივი ოპერაციების დროს. უმდგომარეო შესრულების ხისტი, ცალმხრივი ბუნება ზღუდავს ნამდვილად ინტერაქტიული და რეაგირებადი AI აპლიკაციების განვითარებას.

ახლა, Amazon Bedrock AgentCore Runtime წარმოგიდგენთ ინოვაციურ მდგომარეობის მქონე მოდელის კონტექსტის პროტოკოლის (MCP) კლიენტის შესაძლებლობებს, რომელიც ცვლის იმას, თუ როგორ ურთიერთქმედებენ AI აგენტები მომხმარებლებთან და დიდ ენობრივ მოდელებთან (LLMs). ეს საკვანძო განახლება ათავისუფლებს აგენტებს უმდგომარეო კომუნიკაციის შეზღუდვებისგან, რაც საშუალებას იძლევა კომპლექსური, მრავალეტაპიანი და მაღალინტერაქტიული სამუშაო პროცესების განვითარებას. MCP კლიენტის გადამწყვეტი ფუნქციების – გამოკვლევის (Elicitation), შერჩევის (Sampling) და პროგრესის შეტყობინებების (Progress Notifications) – ინტეგრირებით, Bedrock AgentCore Runtime ხელს უწყობს ორმხრივ საუბრებს MCP სერვერებსა და კლიენტებს შორის, რაც გზას უხსნის უფრო ინტელექტუალურ, მომხმარებელზე ორიენტირებულ AI გადაწყვეტილებებს.

უმდგომარეოდან მდგომარეობის მქონემდე: ინტერაქტიული აგენტური სამუშაო პროცესების განბლოკვა

ადრე, AgentCore-ზე MCP სერვერის მხარდაჭერა მუშაობდა უმდგომარეო რეჟიმში, სადაც ყოველი HTTP მოთხოვნა ფუნქციონირებდა დამოუკიდებლად, ყოველგვარი საერთო კონტექსტის გარეშე. მიუხედავად იმისა, რომ ეს ამარტივებდა განლაგებას ძირითადი ინსტრუმენტების სერვერებისთვის, ის სერიოზულად ზღუდავდა სცენარებს, რომლებიც საჭიროებდნენ საუბრის უწყვეტობას, სამუშაო პროცესის შუა პერიოდში მომხმარებლის განმარტებას ან რეალურ დროში პროგრესის მოხსენებას. სერვერს უბრალოდ არ შეეძლო საუბრის ძაფის შენარჩუნება ცალკეულ მოთხოვნებს შორის, რაც აფერხებდა ჭეშმარიტად ინტერაქტიული აგენტების განვითარებას.

მდგომარეობის მქონე MCP კლიენტის შესაძლებლობების დანერგვა ფუნდამენტურად ცვლის ამ პარადიგმას. სერვერის გაშვებისას stateless_http=False-ის დაყენებით, AgentCore Runtime უზრუნველყოფს გამოყოფილ microVM-ს თითოეული მომხმარებლის სესიისთვის. ეს microVM მუდმივია სესიის მთელი ხანგრძლივობის განმავლობაში – 8 საათამდე, ან 15 წუთიანი უმოქმედობის შემდეგ idleRuntimeSessionTimeout პარამეტრის მიხედვით – რაც უზრუნველყოფს CPU-ს, მეხსიერებას და ფაილური სისტემის იზოლაციას სესიებს შორის. უწყვეტობა შენარჩუნებულია Mcp-Session-Id ჰედერით, რომელსაც სერვერი აწვდის ინიციალიზაციის დროს და კლიენტი მოიცავს ყველა შემდგომ მოთხოვნაში იმავე სესიამდე დასაბრუნებლად. ეს გამოყოფილი, მუდმივი გარემო საშუალებას აძლევს აგენტებს დაიმახსოვრონ კონტექსტი, მოითხოვონ მომხმარებლის შეყვანა, შექმნან დინამიური LLM კონტენტი და უზრუნველყონ უწყვეტი განახლებები.

შემდეგი ცხრილი აჯამებს ძირითად განსხვავებებს უმდგომარეო და მდგომარეობის მქონე რეჟიმებს შორის:

	უმდგომარეო რეჟიმი	მდგომარეობის მქონე რეჟიმი
`stateless_http` პარამეტრი	`TRUE`	`FALSE`
სესიის იზოლაცია	გამოყოფილი microVM თითო სესიაზე	გამოყოფილი microVM თითო სესიაზე
სესიის სიცოცხლის ხანგრძლივობა	8 საათამდე; 15 წუთიანი უმოქმედობის ვადის გასვლა	8 საათამდე; 15 წუთიანი უმოქმედობის ვადის გასვლა
კლიენტის შესაძლებლობები	არ არის მხარდაჭერილი	გამოკვლევა, შერჩევა, პროგრესის შეტყობინებები
რეკომენდებულია	მარტივი ინსტრუმენტის სერვისი	ინტერაქტიული, მრავალეტაპიანი სამუშაო პროცესები

როდესაც სესია იწურება ან სერვერი გადაიტვირთება, შემდგომი მოთხოვნები ადრინდელი სესიის ID-ით დააბრუნებს 404 შეცდომას. ამ ეტაპზე, კლიენტებმა ხელახლა უნდა მოახდინონ კავშირის ინიციალიზაცია ახალი სესიის ID-ის მისაღებად და ახალი სესიის დასაწყებად. მდგომარეობის მქონე რეჟიმის ჩასართავად კონფიგურაციის შეცვლა არის ერთი დროშა თქვენი სერვერის გაშვებისას:

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

ამ დროშის გარდა, სამი კლიენტის შესაძლებლობა ავტომატურად ხელმისაწვდომი ხდება მას შემდეგ, რაც MCP კლიენტი მათ მხარდაჭერას გამოაცხადებს ინიციალიზაციის შეთანხმების დროს.

ახალი კლიენტის შესაძლებლობების სიღრმისეული ანალიზი: გამოკვლევა, შერჩევა და პროგრესი

მდგომარეობის მქონე რეჟიმზე გადასვლით, Amazon Bedrock AgentCore Runtime ხსნის სამ მძლავრ კლიენტის შესაძლებლობას MCP სპეციფიკაციიდან, თითოეული შექმნილია მოწინავე AI აგენტებისთვის გადამწყვეტი ურთიერთქმედების განსხვავებული შაბლონების მოსაგვარებლად. ეს შესაძლებლობები გარდაქმნის ადრე ხისტ, ცალმხრივ ბრძანების შესრულებას სითხისებრ, ორმხრივ დიალოგად MCP სერვერსა და მის დაკავშირებულ კლიენტებს შორის. მნიშვნელოვანია აღინიშნოს, რომ ეს ფუნქციები არის 'opt-in', რაც ნიშნავს, რომ კლიენტები აცხადებენ თავიანთ მხარდაჭერას ინიციალიზაციის დროს, ხოლო სერვერებმა უნდა გამოიყენონ მხოლოდ ის შესაძლებლობები, რომლებიც დაკავშირებულმა კლიენტმა რეკლამირება მოახდინა.

გამოკვლევა: მომხმარებლის დინამიური შეყვანის ჩართვა AI აგენტებში

გამოკვლევა ინტერაქტიული AI-ის ქვაკუთხედს წარმოადგენს, რაც MCP სერვერს საშუალებას აძლევს გონივრულად შეაჩეროს თავისი შესრულება და მოითხოვოს კონკრეტული, სტრუქტურირებული შეყვანა მომხმარებლისგან კლიენტის მეშვეობით. ეს შესაძლებლობა ინსტრუმენტს საშუალებას აძლევს დასვას ზუსტი კითხვები შესაბამის მომენტებში მისი სამუშაო პროცესის ფარგლებში, იქნება ეს გადაწყვეტილების დასადასტურებლად, მომხმარებლის პრეფერენციის შესაგროვებლად თუ წინა ოპერაციებიდან მიღებული მნიშვნელობის შესაგროვებლად. სერვერი ამას იწყებს elicitation/create JSON-RPC მოთხოვნის გაგზავნით, რომელიც მოიცავს ადამიანისთვის გასაგებ შეტყობინებას და არჩევით requestedSchema-ს, რომელიც განსაზღვრავს მოსალოდნელ პასუხის სტრუქტურას.

MCP სპეციფიკაცია ითვალისწინებს გამოკვლევის ორ ძლიერ რეჟიმს:

ფორმის რეჟიმი: ეს იდეალურია სტრუქტურირებული მონაცემების უშუალოდ MCP კლიენტის მეშვეობით შესაგროვებლად, როგორიცაა კონფიგურაციის პარამეტრები, მომხმარებლის პრეფერენციები ან მარტივი დადასტურებები, სადაც კონფიდენციალური მონაცემები არ არის ჩართული.
URL რეჟიმი: ინტერაქციებისთვის, რომლებიც საჭიროებენ უსაფრთხო, გარე პროცესს, როგორიცაა OAuth ნაკადები, გადახდის დამუშავება ან მგრძნობიარე სერთიფიკატების შეყვანა, URL რეჟიმი მომხმარებელს გადამისამართებს გარე URL-ზე. ეს უზრუნველყოფს, რომ მგრძნობიარე ინფორმაცია სრულად გვერდს აუვლის MCP კლიენტს, აუმჯობესებს უსაფრთხოებასა და შესაბამისობას.

გამოკვლევის მოთხოვნის მიღებისას, კლიენტი ქმნის შესაბამის შეყვანის ინტერფეისს. მომხმარებლის შემდგომი მოქმედება იწვევს სამ-მოქმედებიან საპასუხო მოდელს სერვერისკენ: accept (მომხმარებელმა მიაწოდა მოთხოვნილი მონაცემები), decline (მომხმარებელმა აშკარად უარყო მოთხოვნა) ან cancel (მომხმარებელმა უარი თქვა მოთხოვნაზე არჩევანის გაკეთების გარეშე). ინტელექტუალური სერვერები შექმნილია იმისათვის, რომ ელეგანტურად გაუმკლავდნენ თითოეულ ამ სცენარს, უზრუნველყონ მყარი და მომხმარებლისთვის მოსახერხებელი გამოცდილება. მაგალითად, add_expense_interactive ინსტრუმენტს, როგორც ეს ნაჩვენებია საწყის მასალაში, შეუძლია მომხმარებლის წარმართვა კითხვების სერიაში — თანხა, აღწერა, კატეგორია და საბოლოო დადასტურება — სანამ მონაცემებს დაავალებს ისეთ ბექენდს, როგორიცაა Amazon DynamoDB. თითოეული ნაბიჯი იყენებს Pydantic მოდელებს მოსალოდნელი შეყვანის განსაზღვრისთვის, რომელსაც FastMCP უწყვეტად გარდაქმნის JSON Schema-დ, რომელიც საჭიროა elicitation/create მოთხოვნისთვის.

შერჩევა და პროგრესის შეტყობინებები: LLM ინტერაქციისა და გამჭვირვალობის გაუმჯობესება

მომხმარებლის პირდაპირი ინტერაქციის მიღმა, შერჩევა MCP სერვერს უზრუნველყოფს შესაძლებლობით, მოითხოვოს დახვეწილი დიდი ენობრივი მოდელის (LLM) მიერ გენერირებული კონტენტი უშუალოდ კლიენტისგან sampling/createMessage მეშვეობით. ეს კრიტიკული მექანიზმია, რადგან ის საშუალებას აძლევს ინსტრუმენტის ლოგიკას სერვერზე გამოიყენოს ძლიერი ენობრივი მოდელის შესაძლებლობები საკუთარი LLM სერთიფიკატების ან პირდაპირი API ინტეგრაციების მართვის გარეშე. სერვერი უბრალოდ აწვდის მოთხოვნას და არჩევით მოდელის პრეფერენციებს, ხოლო კლიენტი, როგორც შუამავალი, აგზავნის მოთხოვნას მის დაკავშირებულ LLM-ზე და აბრუნებს გენერირებულ პასუხს. ეს ხსნის პრაქტიკული გამოყენების უამრავ შესაძლებლობას, მათ შორის პერსონალიზებული შეჯამებების შექმნას, ბუნებრივი ენის განმარტებების გენერირებას კომპლექსური სტრუქტურირებული მონაცემებიდან, ან კონტექსტის გათვალისწინებული რეკომენდაციების შექმნას მიმდინარე საუბრის საფუძველზე.

ოპერაციებისთვის, რომლებიც დროთა განმავლობაში გრძელდება, პროგრესის შეტყობინებები ფასდაუდებელი ხდება. ეს შესაძლებლობა საშუალებას აძლევს MCP სერვერს მოახდინოს ინკრემენტული განახლებების მოხსენება ხანგრძლივი ამოცანების დროს. ctx.report_progress(progress, total)-ის გამოყენებით, სერვერს შეუძლია უწყვეტი განახლებების გაცემა, რომლებიც კლიენტებს შეუძლიათ გადააქციონ ვიზუალურ უკუკავშირად, როგორიცაა პროგრესის ზოლი ან სტატუსის ინდიკატორი. იქნება ეს უზარმაზარი მონაცემთა წყაროების ძიება თუ კომპლექსური გამოთვლითი ამოცანების შესრულება, პროგრესის გამჭვირვალე განახლებები უზრუნველყოფს მომხმარებლების ინფორმირებულობას, ხელს უშლის იმედგაცრუებას და აუმჯობესებს საერთო მომხმარებლის გამოცდილებას, ნაცვლად იმისა, რომ ისინი ცარიელ ეკრანს უყურებდნენ და უკვირდეთ, არის თუ არა სისტემა ჯერ კიდევ აქტიური.

AI აგენტების განვითარების მომავლის უზრუნველყოფა Bedrock AgentCore Runtime-ით

Amazon Bedrock AgentCore Runtime-ზე მდგომარეობის მქონე MCP კლიენტის შესაძლებლობების დანერგვა წარმოადგენს მნიშვნელოვან ნახტომს AI აგენტების განვითარებაში. ადრე უმდგომარეო ინტერაქციების დინამიურ, ორმხრივ საუბრებად გარდაქმნით, AWS დეველოპერებს აძლევს შესაძლებლობას შექმნან უფრო ინტელექტუალური, რეაგირებადი და მომხმარებლისთვის მოსახერხებელი AI აპლიკაციები. ეს შესაძლებლობები – გამოკვლევა მომხმარებლის მიერ მართული შეყვანისთვის, შერჩევა მოთხოვნილ LLM გენერაციისთვის და პროგრესის შეტყობინებები რეალურ დროში გამჭვირვალობისთვის – ერთობლივად ხსნის ინტერაქტიული აგენტური სამუშაო პროცესების ახალ ერას. რადგან AI აგრძელებს განვითარებას, ეს ფუნდამენტური შესაძლებლობები გადამწყვეტი იქნება დახვეწილი აგენტური AI-ის ოპერაციონალიზაციისთვის, რომელსაც შეუძლია შეუფერხებლად ინტეგრირება კომპლექსურ ბიზნეს პროცესებში, ადაპტირება მომხმარებლის საჭიროებებთან და განსაკუთრებული ღირებულების მიწოდება.