AWS تعلّم سجل خوادم MCP أن يحدّث نفسه: مخطط الأدوات بلا تعديلات يدوية

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

نشرت AWS تحليلًا لكيفية تفادي ذلك في Agent Registry، وهو جزء من Amazon Bedrock AgentCore. الفكرة بسيطة: يجب ألا يعتمد تحديث السجل على انضباط المطوّر، بل أن يطلقه حدث النشر نفسه.

كيف يعمل ذلك

تتألف السلسلة من خمس خدمات، وتبدو كما يلي.

• يحدّث المطوّر خادم MCP، مثلًا بالأمر agentcore deploy. يؤدي ذلك إلى استدعاء واجهة UpdateAgentRuntime البرمجية، ويسجّل CloudTrail الاستدعاء بوصفه management event.
• يمرّر EventBridge الحدث وفق قاعدة (المصدر aws.bedrock-agentcore، واسم الحدث UpdateAgentRuntime) إلى ناقل مركزي. وفي المخطط متعدد الحسابات يقع هذا الناقل في حساب السجل.
• تستخرج Lambda من الحدث معرّف ARN الخاص بالـ runtime وتبني منه عنوان URL لاستدعاء خادم MCP. وتأخذ المنطقة ومعرّف الحساب من ARN نفسه.
• تحصل Lambda على رمز OAuth عبر AgentCore Identity: أولًا رمز workload لنفسها، ثم رمز M2M من credential provider الخاص بالحساب المطلوب. ولا توجد أسرار عميل في متغيرات البيئة.
• تستدعي Lambda الأمر initialize ثم tools/list، فتحصل على قائمة الأدوات الحالية.
• بعد ذلك تبحث عن سجل في الـ Registry يرد في مخططه ARN نفسه (أو ARN المشفَّر، أو عنوان URL)، وتقارن القوائم.

أين تكمن الهندسة الدقيقة

تتم المقارنة دون كتابات زائدة. تُرتَّب الأدوات حسب الاسم وتُختزل إلى ثلاثة حقول: name وdescription وinputSchema. ولا يُرسَل التحديث إلى السجل إلا إذا اختلفت هذه الحقول، وتبقى في السجلات (logs) معلومة عمّا أُضيف أو أُزيل بالضبط.

وثمة تفصيلان مفيدان آخران. يُضبط لكل حساب credential provider خاص به (متغير على الصيغة CREDENTIAL_PROVIDER_{ACCT_ID})، ولذلك تخدم Lambda واحدة خوادم من حسابات مختلفة. وقبل إرسال الطلب تتحقق الشيفرة من أن عنوان URL يبدأ بـ https://، وهذا يسدّ سيناريوهات مزعجة مثل file://.

تخيّل فريق المدفوعات أضاف إلى خادم MCP الخاص به أداة refund_status. في السابق كان فريق الدعم سيعلم بذلك من الدردشة بعد أسبوع. أما الآن فبعد 5–15 دقيقة من النشر يحتوي سجل الـ Registry بالفعل على الأداة الجديدة بمخططها الحالي، وتُظهر سجلات Lambda ما الذي تغيّر.

القيود التي ينبغي معرفتها

أولًا: الخدمة لا تنشئ سجلات. تقوم Lambda في المثال بتحديث السجلات المسجَّلة مسبقًا فقط، وهي التي أُنشئت أثناء الإدماج (onboarding) وتحتوي ARN الخاص بالـ runtime في mcpServer.data. أما السجلات ذات الحالة DRAFT فتُتجاهل، والمطلوب APPROVED. وهذا يحافظ على عملية الموافقة القائمة، لكن التسجيل الأولي سيتعيّن أتمتته بشكل منفصل.

ثانيًا: التأخر. يسلّم CloudTrail الأحداث خلال نحو 5–15 دقيقة، لذا فهو غير مناسب لسيناريو «نشرتُ وأستدعي فورًا». أما بالنسبة لكتالوج يقرؤه البشر والوكلاء عند البحث عن الأدوات فهذا التأخر محتمل عادةً.

ثالثًا: المحفّز هو UpdateAgentRuntime تحديدًا. إذا تغيرت مجموعة أدوات الخادم ديناميكيًا دون تحديث الـ runtime فلن يظهر حدث، وسيتعيّن مزامنة السجلات وفق جدول زمني.

وثمة ملاحظتان على شيفرة المقالة نفسها. يمرّ البحث عن السجل على قائمة الـ Registry ويُجري طلب get منفصلًا لكل عنصر، ولا يوجد ترقيم صفحات (pagination) في المقطع المعروض. مع عشرات الخوادم لا مشكلة في ذلك، أما مع المئات فينبغي إضافة فهرس أو حفظ المطابقة بين ARN ومعرّف السجل بشكل منفصل. كما أن جزءًا من الشيفرة مقطوع في المقالة الأصلية، لذا من الأفضل الاطلاع على النسخة الكاملة في مستودع المثال.

ماذا تفعل عمليًا

إذا كنت تبني كتالوجًا داخليًا لخوادم MCP، فاعتمد النمط كاملًا: حدث النشر، ثم الاستعلام عبر tools/list، ثم المقارنة (diff)، ثم الكتابة. وهو غير مرتبط بـ AWS: ففي أي سحابة يمكن تركيب الشيء نفسه من سجل تدقيق وناقل أحداث ودالة. والقاعدة الأساسية: مصدر الحقيقة بشأن مخطط الأدوات هو الخادم العامل نفسه، أما سجل الكتالوج فمجرد انعكاس له، ولا يجوز تركه للتحديث اليدوي.