ربط نموذج ذكاء اصطناعي بخادم MCP بعيد يسمح لتطبيقك باستخدام أدوات خدمة خارجية بدل الاكتفاء بإجابة نصية. لكن إضافة الخادم ليست تفويضًا مفتوحًا لكل أداة أو لكل معلومة في المحادثة. وللتحضير لعام 2027، يشرح هذا الدليل مسار الربط والموافقة في Responses API بحسب التوثيق المتحقق منه في 27 أكتوبر 2026، دون افتراض استمرار التفاصيل دون تغيير.
ما الذي تضيفه إلى الطلب؟
داخل tools أضف تعريفًا من النوع mcp، واسمًا للخادم عبر server_label، وعنوان الخادم البعيد عبر server_url. وإذا كان الخادم يتطلب مصادقة، فقد تحتاج رمز وصول OAuth في authorization. يجب أن يتوافق الخادم البعيد مع Streamable HTTP أو HTTP/SSE، وأن تختار نموذجًا يدعم هذه الأداة.
لا تخلط عنوان الخادم مع connector_id القديم؛ فهذا المعرف مهمل للنماذج الصادرة بعد 1 سبتمبر 2026، مع استمرار دعم الموصلات للنماذج السابقة. وللخوادم الخاصة توجد طريقة مختلفة باستخدام Secure MCP Tunnel ومعرف tunnel_id، بدل افتراض ضرورة فتح الخادم للإنترنت.
استيراد الأدوات ثم استدعاؤها
يحاول API أولًا الحصول على قائمة الأدوات من الخادم، ويظهر عنصر mcp_list_tools في المخرجات عند نجاح الاستيراد. استخدم allowed_tools لتحديد الأدوات التي يحتاجها التطبيق، بدل إتاحة قائمة كبيرة تزيد كلفة التعريفات وزمن المعالجة. وإبقاء عنصر القائمة في سياق الطلبات التالية يمنع إعادة جلبها في كل دور.
إذا اختار النموذج أداة، يظهر mcp_call وفيه الوسائط والنتيجة. قد تظهر استدعاءات متعددة في طلب واحد، وقد يتضمن حقل error خطأ بروتوكول أو تنفيذ أو اتصال. لذلك لا تعتبر وجود استدعاء دليلًا على نجاح الإجراء، ولا تكتف بالنص النهائي عند فحص سير العملية.
كيف تعمل الموافقة؟
المسار الافتراضي يطلب الموافقة قبل مشاركة البيانات. ويمكن تثبيت ذلك صراحة عبر require_approval بالقيمة always. عند ظهور mcp_approval_request، راجع اسم الأداة ووسائطها والبيانات التي ستغادر التطبيق.
للموافقة أرسل طلب Responses جديدًا يتضمن mcp_approval_response، مع approval_request_id الفعلي وapprove بالقيمة true، واربطه بالرد السابق عبر previous_response_id أو إدارة السياق يدويًا. الموافقة تخص استدعاءً واحدًا؛ والطلب التالي للموافقة يحتاج معالجة مستقلة. أما never فيلغي الموافقات لكل أدوات الخادم، ويمكن تخصيص تجاوزها لأدوات محددة بدل تعميمه على الإجراءات الحساسة.
مثال عملي للموافقة أو الرفض
افترض أن تطبيقًا يبحث في توثيق عام، وأنك أتحت search_openai_docs وحدها. يصل طلب موافقة يتضمن اسم الأداة ووسائط مثل عبارة البحث. اعرض هذه التفاصيل للمراجع، لا زرًا يقول «موافق» بلا بيان لما سيرسل. إذا كانت عبارة البحث عامة ومقصودة، أرسل mcp_approval_response بمعرف الطلب المستلم وapprove: true. وإذا تضمنت العبارة معلومة لا تريد مشاركتها، فالرد الرافض يستخدم approve: false، ويمكن إرفاق reason لتوضيح القرار.
المعرف في المثال ليس رقمًا ثابتًا تنسخه من التوثيق؛ اربط كل قرار بطلبه الحقيقي. ورفض هذا الطلب لا يعني أن التطبيق حصل على النتيجة، كما أن الموافقة عليه لا تسمح تلقائيًا بأي طلب تالٍ. تابع المخرجات الجديدة لتعرف هل عاد استدعاء بنتيجة أو خطأ أو طلب موافقة آخر، وأبلغ المستخدم بما تحقق بالفعل بدل صياغة نجاح لم يحدث.
تصفية الأدوات ليست موافقة على البيانات
allowed_tools تحدد الأدوات المتاحة للنموذج أصلًا، بينما require_approval تضبط الموافقة عند استدعاء أداة متاحة. إتاحة أداة بحث واحدة تقلل نطاق الوظائف، لكنها لا تثبت سلامة كل عبارة بحث ترسل إليها. وبالعكس، اشتراط الموافقة لا يغني عن إزالة أدوات لا يحتاجها التطبيق. عمليًا اجمع قائمة صغيرة مناسبة للمهمة مع مراجعة الوسائط الحساسة لكل استدعاء.
فشل الاستدعاء والتحقق من النتيجة
افصل بين نجاح جلب القائمة، والحصول على الموافقة، ونجاح تنفيذ الأداة؛ فهي مراحل مختلفة. إذا ظهر error في mcp_call، احتفظ بنوع الخطأ ورسالة الخادم لتشخيص هل المشكلة في الاتصال أم البروتوكول أم التنفيذ، ولا تحولها إلى نتيجة فارغة توحي بعدم وجود بيانات. وإذا احتوى output على نتيجة، راجع أنها تخص الأداة والوسائط المقصودة قبل بناء الإجابة عليها.
عند ربط أداة تنفذ إجراءً لا مجرد قراءة، لا تفترض أن تكرار الطلب آمن بعد خطأ اتصال؛ تحقق من حالة الإجراء لدى الخدمة قبل محاولة قد تنفذه مرتين. هذه قاعدة تحقق للتطبيق، وليست وعدًا من API بالتراجع عن أثر خارجي أو بمنع التكرار تلقائيًا.
رمز الوصول وحدود الخصوصية
لا يحفظ Responses API قيمة authorization ولا يعيدها في كائن الرد، لذا يلزم إرسالها في كل طلب إنشاء يحتاجها. هذا لا يعني أن الخادم لا يتلقى البيانات اللازمة لتنفيذ أداته، ولا أن سياسة احتفاظ تطبيقك تنتقل إليه تلقائيًا.
اختر خادمًا رسميًا لمقدم الخدمة متى توفر، وراجع البيانات المرسلة والروابط الراجعة قبل استخدامها. قد تتضمن مخرجات خادم غير موثوق تعليمات خفية، وقد يتغير سلوك أدواته. كما أن توافق الأداة مع عدم الاحتفاظ بالبيانات أو إقامتها لا يلزم الخادم الخارجي بسياسة مماثلة؛ تحقق من شروطه بنفسها قبل إرسال معلومات حساسة.
