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

تعزيز وكلاء الذكاء الاصطناعي: التحول إلى بروتوكول سياق النموذج (MCP) ذي الحالة في Amazon Bedrock

تتطور وكلاء الذكاء الاصطناعي بسرعة، ولكن إمكاناتهم الكاملة غالبًا ما تعوقها التطبيقات عديمة الحالة (stateless implementations)، خاصة في السيناريوهات التي تتطلب تفاعل المستخدم في الوقت الفعلي، أو إنشاء محتوى ديناميكي، أو تحديثات التقدم المستمرة. غالبًا ما يواجه المطورون الذين يبنون وكلاء ذكاء اصطناعي متطورين تحديات عندما تحتاج سير العمل إلى التوقف، أو جمع توضيحات، أو الإبلاغ عن الحالة أثناء العمليات طويلة الأمد. إن الطبيعة الصارمة أحادية الاتجاه للتنفيذ عديم الحالة تحد من تطوير تطبيقات ذكاء اصطناعي تفاعلية واستجابة حقًا.

الآن، يقدم Amazon Bedrock AgentCore Runtime إمكانات عميل بروتوكول سياق النموذج (MCP) ذي الحالة الرائدة، مما يغير طريقة تفاعل وكلاء الذكاء الاصطناعي مع المستخدمين ونماذج اللغات الكبيرة (LLMs). يحرر هذا التحديث المحوري الوكلاء من قيود الاتصال عديم الحالة، مما يتيح سير عمل معقدًا ومتعدد الأدوار وتفاعليًا للغاية. من خلال دمج ميزات عميل MCP الحاسمة – الاستنباط (Elicitation)، وأخذ العينات (Sampling)، وإشعارات التقدم (Progress Notifications) – يسهل وقت تشغيل Bedrock AgentCore المحادثات ثنائية الاتجاه بين خوادم وعملاء MCP، مما يمهد الطريق لحلول ذكاء اصطناعي أكثر ذكاءً وتتمحور حول المستخدم.

من الوضع عديم الحالة إلى الوضع ذي الحالة: فتح سير عمل الوكلاء التفاعلي

سابقًا، كان دعم خادم MCP في AgentCore يعمل في وضع عديم الحالة (stateless mode)، حيث تعمل كل طلب HTTP بشكل مستقل، خالياً من أي سياق مشترك. بينما بسّط هذا النشر لخوادم الأدوات الأساسية، فقد حد بشكل كبير من السيناريوهات التي تتطلب استمرارية المحادثة، أو توضيح المستخدم في منتصف سير العمل، أو الإبلاغ عن التقدم في الوقت الفعلي. لم يتمكن الخادم ببساطة من الاحتفاظ بخيط محادثة عبر طلبات منفصلة، مما أعاق تطوير وكلاء تفاعليين حقًا.

يغير ظهور إمكانات عميل MCP ذي الحالة هذا النموذج بشكل جذري. من خلال تعيين stateless_http=False أثناء بدء تشغيل الخادم، يوفر وقت تشغيل AgentCore آلة افتراضية دقيقة (microVM) مخصصة لكل جلسة مستخدم. تستمر هذه الآلة الافتراضية الدقيقة طوال مدة الجلسة — حتى 8 ساعات، أو 15 دقيقة من عدم النشاط لكل إعداد idleRuntimeSessionTimeout — مما يضمن عزل وحدة المعالجة المركزية والذاكرة ونظام الملفات بين الجلسات. يتم الحفاظ على الاستمرارية من خلال رأس Mcp-Session-Id، والذي يوفره الخادم أثناء التهيئة ويتضمنه العميل في جميع الطلبات اللاحقة للتوجيه مرة أخرى إلى نفس الجلسة. تتيح هذه البيئة المخصصة والمستمرة للوكلاء تذكر السياق، وطلب إدخال المستخدم، وتوليد محتوى ديناميكي من نماذج اللغات الكبيرة (LLM)، وتقديم تحديثات مستمرة.

الجدول التالي يلخص الاختلافات الرئيسية بين الوضع عديم الحالة والوضع ذي الحالة:

	الوضع عديم الحالة	الوضع ذو الحالة
إعداد `stateless_http`	`TRUE`	`FALSE`
عزل الجلسة	آلة افتراضية دقيقة مخصصة لكل جلسة	آلة افتراضية دقيقة مخصصة لكل جلسة
عمر الجلسة	حتى 8 ساعات؛ مهلة عدم النشاط 15 دقيقة	حتى 8 ساعات؛ مهلة عدم النشاط 15 دقيقة
إمكانات العميل	غير مدعومة	الاستنباط، أخذ العينات، إشعارات التقدم
موصى به لـ	خدمة أدوات بسيطة	سير عمل تفاعلي متعدد الأدوار

عند انتهاء صلاحية الجلسة أو إعادة تشغيل الخادم، سترجع الطلبات اللاحقة التي تحمل معرف الجلسة القديم رمز 404. عند هذه النقطة، يجب على العملاء إعادة تهيئة الاتصال للحصول على معرف جلسة جديد وبدء جلسة جديدة. تغيير التكوين لتمكين الوضع ذي الحالة هو علامة واحدة في بدء تشغيل الخادم الخاص بك:

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

بالإضافة إلى هذه العلامة، تصبح إمكانات العميل الثلاث متاحة تلقائيًا بمجرد أن يعلن عميل MCP عن دعمه لها أثناء تأكيد الاتصال الأولي (initialization handshake).

تعمق في إمكانات العميل الجديدة: الاستنباط، أخذ العينات، والتقدم

مع الانتقال إلى الوضع ذي الحالة، يفتح Amazon Bedrock AgentCore Runtime ثلاث إمكانات قوية للعميل من مواصفات MCP، كل منها مصمم لمعالجة أنماط تفاعل مميزة وحاسمة لوكلاء الذكاء الاصطناعي المتقدمين. تحول هذه الإمكانات ما كان في السابق تنفيذًا صارمًا أحادي الاتجاه للأوامر إلى حوار سلس ثنائي الاتجاه بين خادم MCP وعملائه المتصلين. من المهم ملاحظة أن هذه الميزات هي اختيارية (opt-in)، مما يعني أن العملاء يعلنون دعمهم أثناء التهيئة، ويجب على الخوادم استخدام الإمكانات التي أعلن عنها العميل المتصل فقط.

الاستنباط: تمكين إدخال المستخدم الديناميكي في وكلاء الذكاء الاصطناعي

يُعد الاستنباط حجر الزاوية في الذكاء الاصطناعي التفاعلي، حيث يسمح لخادم MCP بإيقاف تنفيذه بحكمة وطلب إدخال محدد ومنظم من المستخدم عبر العميل. تُمكّن هذه الإمكانية الأداة من طرح أسئلة دقيقة في اللحظات المناسبة ضمن سير عملها، سواء كان ذلك لتأكيد قرار، أو جمع تفضيل مستخدم، أو الحصول على قيمة مشتقة من العمليات السابقة. يبدأ الخادم ذلك عن طريق إرسال طلب elicitation/create JSON-RPC، والذي يتضمن رسالة قابلة للقراءة البشرية وrequestedSchema اختياريًا يحدد بنية الاستجابة المتوقعة.

توفر مواصفات MCP وضعين قويين للاستنباط:

وضع النموذج (Form mode): هذا مثالي لجمع البيانات المنظمة مباشرة من خلال عميل MCP، مثل معلمات التكوين، وتفضيلات المستخدم، أو التأكيدات البسيطة حيث لا توجد بيانات حساسة.
وضع الرابط (URL mode): للتفاعلات التي تتطلب عملية آمنة خارج النطاق (out-of-band)، مثل تدفقات OAuth، ومعالجة الدفع، أو إدخال بيانات اعتماد حساسة، يوجه وضع الرابط المستخدم إلى عنوان URL خارجي. يضمن ذلك أن المعلومات الحساسة تتجاوز عميل MCP تمامًا، مما يعزز الأمان والامتثال.

عند تلقي طلب الاستنباط، يقوم العميل بتقديم واجهة إدخال مناسبة. يؤدي إجراء المستخدم اللاحق إلى نموذج استجابة ثلاثي الإجراءات يعود إلى الخادم: accept (قدم المستخدم البيانات المطلوبة)، decline (رفض المستخدم الطلب صراحةً)، أو cancel (رفض المستخدم المطالبة دون اتخاذ خيار). تم تصميم الخوادم الذكية للتعامل مع كل من هذه السيناريوهات برشاقة، مما يضمن تجربة قوية وسهلة الاستخدام. على سبيل المثال، يمكن لأداة add_expense_interactive، كما هو موضح في المادة المصدر، توجيه المستخدم عبر سلسلة من الأسئلة – المبلغ، الوصف، الفئة، والتأكيد النهائي – قبل الالتزام بالبيانات في واجهة خلفية مثل Amazon DynamoDB. يستفيد كل خطوة من نماذج Pydantic لتحديد الإدخال المتوقع، والذي يحوله FastMCP بسلاسة إلى مخطط JSON المطلوب لطلب elicitation/create.

أخذ العينات وإشعارات التقدم: تعزيز تفاعل نماذج اللغات الكبيرة (LLM) والشفافية

بالإضافة إلى التفاعل المباشر مع المستخدم، يزود أخذ العينات (Sampling) خادم MCP بالقدرة على طلب محتوى تم إنشاؤه بواسطة نماذج اللغات الكبيرة (LLM) مباشرة من العميل عبر sampling/createMessage. هذه آلية حاسمة لأنها تتيح لمنطق الأداة على الخادم الاستفادة من إمكانات نماذج اللغة القوية دون الحاجة إلى إدارة بيانات اعتماد نماذج اللغات الكبيرة الخاصة به أو عمليات دمج API المباشرة. يوفر الخادم ببساطة مطالبة وتفضيلات نموذج اختيارية، ويقوم العميل، الذي يعمل كوسيط، بإعادة توجيه الطلب إلى نموذج اللغة الكبيرة المتصل به وإرجاع الاستجابة التي تم إنشاؤها. يفتح هذا العديد من التطبيقات العملية، بما في ذلك صياغة ملخصات مخصصة، وإنشاء تفسيرات باللغة الطبيعية من البيانات المنظمة، أو إنتاج توصيات تراعي السياق بناءً على المحادثة المستمرة.

بالنسبة للعمليات التي تمتد بمرور الوقت، تصبح إشعارات التقدم (Progress Notifications) لا تقدر بثمن. تتيح هذه الإمكانية لخادم MCP الإبلاغ عن تحديثات تدريجية أثناء المهام طويلة الأمد. من خلال استخدام ctx.report_progress(progress, total)، يمكن للخادم إصدار تحديثات مستمرة يمكن للعملاء ترجمتها إلى ملاحظات بصرية، مثل شريط تقدم أو مؤشر حالة. سواء كان ذلك البحث عبر مصادر بيانات ضخمة أو تنفيذ مهام حسابية معقدة، تضمن تحديثات التقدم الشفافة بقاء المستخدمين على اطلاع، مما يمنع الإحباط ويعزز تجربة المستخدم الإجمالية، بدلاً من تركهم يحدقون في شاشة فارغة متسائلين عما إذا كان النظام لا يزال نشطًا.

تأمين مستقبل تطوير وكلاء الذكاء الاصطناعي باستخدام وقت تشغيل Bedrock AgentCore

يمثل إدخال إمكانات عميل MCP ذي الحالة في Amazon Bedrock AgentCore Runtime قفزة كبيرة إلى الأمام في تطوير وكلاء الذكاء الاصطناعي. من خلال تحويل التفاعلات عديمة الحالة السابقة إلى محادثات ديناميكية وثنائية الاتجاه، تمكّن AWS المطورين من بناء تطبيقات ذكاء اصطناعي أكثر ذكاءً واستجابة وسهولة في الاستخدام. هذه الإمكانات – الاستنباط لإدخال المستخدم الموجه، وأخذ العينات لتوليد نماذج اللغات الكبيرة (LLM) حسب الطلب، وإشعارات التقدم للشفافية في الوقت الفعلي – تفتح مجتمعة عصرًا جديدًا من سير عمل الوكلاء التفاعليين. مع استمرار تطور الذكاء الاصطناعي، ستكون هذه الإمكانات الأساسية حاسمة لإنشاء ذكاء اصطناعي يعتمد على الوكلاء متطور يمكنه الاندماج بسلاسة في عمليات الأعمال المعقدة، والتكيف مع احتياجات المستخدم، وتقديم قيمة استثنائية.