GPT Actions مقابل MCP: مقارنة تقنية

تحل GPT Actions من OpenAI وModel Context Protocol (MCP) من Anthropic المشكلة الأساسية نفسها: تمكين نموذج ذكاء اصطناعي من استدعاء أدوات وواجهات API خارجية أثناء المحادثة. لكنهما يحلانها بطريقتين مختلفتين جدا.

هذه المقالة مقارنة تقنية بين النهجين. تتناول البنية، وآليات البروتوكول، والمصادقة، واكتشاف الأدوات، والمفاضلات المهمة عند الاختيار بينهما (أو استخدامهما معا).

ما هي GPT Actions؟

GPT Actions هي آلية OpenAI لتمكين Custom GPTs (وبصورة أوسع، المساعدات المبنية عبر OpenAI API) من استدعاء واجهات HTTP API خارجية. ظهر المفهوم مع GPT Store في أواخر 2023 وتطور من نظام ChatGPT Plugins السابق.

الفكرة الأساسية: تقدم مواصفة OpenAPI (الإصدار 3.0 أو 3.1) تصف نقاط نهاية API، والمعلمات، ومخططات الاستجابة. يحلل نظام OpenAI هذه المواصفة ويعرض نقاط النهاية كنقاط أدوات قابلة للاستدعاء أمام النموذج. عندما يقرر النموذج استدعاء واحدة منها، ترسل خوادم OpenAI طلب HTTP نيابة عن المستخدم.

فيما يلي مخطط OpenAPI بسيط يعرّف إجراء واحدا للبحث عن عميل باستخدام البريد الإلكتروني:

openapi: "3.1.0"
info:
  title: "واجهة API للبحث عن العملاء"
  version: "1.0.0"
servers:
  - url: "https://api.example.com"
paths:
  /customers/search:
    get:
      operationId: "searchCustomer"
      summary: "البحث عن عميل باستخدام البريد الإلكتروني"
      parameters:
        - name: "email"
          in: "query"
          required: true
          schema:
            type: "string"
            format: "email"
          description: "عنوان البريد الإلكتروني للعميل"
      responses:
        "200":
          description: "تم العثور على العميل"
          content:
            application/json:
              schema:
                type: "object"
                properties:
                  id:
                    type: "string"
                  name:
                    type: "string"
                  email:
                    type: "string"
                  plan:
                    type: "string"

تلصق هذا المخطط أو ترفعه إلى GPT Builder (أو تشير إليه عبر URL)، وتضبط المصادقة، ويصبح بإمكان Custom GPT استدعاء GET /customers/search?email=... كلما رأى النموذج أن ذلك مناسب. (إعداد المواصفة هو الجزء الذي يمكن أتمتته: على سبيل المثال، يقوم Quickchat AI بإنشاء الإجراء المكافئ من وصف مكوّن من جملة واحدة، بالاستناد إلى التوثيق الحي لواجهة API.)

الخصائص المعمارية الأساسية لـ GPT Actions:

• تنفيذ من جهة الخادم: تنفذ بنية OpenAI الأساسية استدعاء HTTP الصادر. تتلقى واجهة API لديك الطلب من نطاق عناوين IP الخاص بـ OpenAI، وليس من متصفح المستخدم النهائي.
• OpenAPI كصيغة للمخطط: يستخدم النموذج حقول operationId وsummary وdescription من مواصفة OpenAPI لفهم متى وكيف يستدعي كل نقطة نهاية.
• REST/HTTP فقط: تقتصر Actions على طرق HTTP القياسية (GET وPOST وPUT وDELETE وPATCH) عبر HTTPS.
• خيارات المصادقة: OAuth 2.0، أو مفتاح API (يرسل كترويسة أو معلمة استعلام)، أو بدون مصادقة. تتولى OpenAI تدفق تبادل رمز OAuth نيابة عن المستخدم.
• تعريفات أدوات ثابتة: تحدد مجموعة الإجراءات المتاحة وقت الإعداد. لا يمكن للنموذج اكتشاف نقاط نهاية جديدة أثناء التشغيل.

ما هو MCP؟

Model Context Protocol (MCP) هو بروتوكول مفتوح، نشرته Anthropic في أواخر 2024، يوحد طريقة تواصل تطبيقات الذكاء الاصطناعي مع الأدوات ومصادر البيانات الخارجية. وهو غير مرتبط بنموذج أو مورّد محدد.

كتبنا دليلا كاملا حول آلية عمل MCP يغطي البروتوكول من المبادئ الأساسية. النسخة المختصرة: يعرّف MCP بنية عميل وخادم، حيث يتصل تطبيق ذكاء اصطناعي (عميل MCP) بخادم MCP واحد أو أكثر، ويكتشف الأدوات المتاحة عبر طلب tools/list، ويستدعيها عبر رسائل tools/call. يستخدم الاتصال JSON-RPC 2.0.

فيما يلي أداة البحث عن العميل نفسها معبّرا عنها كتعريف أداة MCP:

{
  "name": "search_customer",
  "description": "البحث عن عميل باستخدام عنوان البريد الإلكتروني",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "عنوان البريد الإلكتروني للعميل"
      }
    },
    "required": ["email"]
  }
}

يوجد هذا التعريف داخل خادم MCP (برنامج صغير يغلّف منطق عملك). عندما يرسل عميل MCP طلب tools/call مع name: "search_customer" وarguments: {"email": "user@example.com"}، ينفذ الخادم أيا كان الكود الموجود خلف تلك الأداة (استدعاء API، أو استعلام قاعدة بيانات، أو قراءة ملف) ويعيد النتيجة. إذا كان ما تريد عرضه هو مساعد ذكاء اصطناعي بدلا من منطق عمل خام، يمكنك تجاوز كتابة الخادم بالكامل: يمكن عرض Quickchat AI Agent لديك كأداة MCP باستخدام URL مستضاف.

مقارنة البنية

يختلف النهجان في مكان تشغيل الكود، وكيفية تدفق الاتصال، وما التجريدات التي يعرضانها.

GPT Actions: مركزية ومبنية على HTTP

User <-> ChatGPT (OpenAI servers) --HTTPS--> Your API server

يوجد النموذج ومنفذ الإجراء معا في جهة OpenAI. عندما يقرر النموذج استدعاء إجراء، ينشئ backend الخاص بـ OpenAI طلب HTTP استنادا إلى مواصفة OpenAPI، ويرسله إلى API لديك، ويتلقى الاستجابة، ثم يمرر النتيجة مرة أخرى إلى النموذج. لا يتواصل عميل المستخدم (المتصفح أو تطبيق الهاتف) مباشرة مع API لديك أبدا.

هذا يعني:

1. يجب أن تكون API لديك متاحة علنا عبر HTTPS (أو على الأقل قابلة للوصول من بنية OpenAI الأساسية).
2. يتضمن زمن الاستجابة رحلة ذهاب وإياب من OpenAI إلى خادمك والعودة.
3. تمر كل بيانات الطلبات والاستجابات عبر خوادم OpenAI.

MCP: لامركزي ومبني على البروتوكول

User <-> AI Application (MCP Client) <--JSON-RPC--> MCP Server <-> Your API / DB / service

يعمل عميل MCP حيثما يعمل تطبيق الذكاء الاصطناعي. بالنسبة إلى Claude Desktop، يكون ذلك على جهاز المستخدم. بالنسبة إلى AI Agent مستضاف على السحابة (مثل Quickchat AI)، يعمل عميل MCP على backend الخاص بالوكيل. يمكن أن يعمل خادم MCP محليا (مع الاتصال عبر stdio)، أو على الشبكة نفسها، أو عن بعد عبر HTTP باستخدام Server-Sent Events (SSE) أو نقل Streamable HTTP الأحدث.

هذا يعني:

1. يمكن لخوادم MCP الوصول إلى موارد محلية (ملفات، قواعد بيانات، خدمات localhost) غير مكشوفة للإنترنت العام.
2. الاتصال ثنائي الاتجاه. يمكن للخوادم إرسال إشعارات إلى العملاء (مثلا عند تغير مورد).
3. البروتوكول غير مرتبط بوسيلة نقل محددة. يعمل عبر أنابيب stdio، أو SSE، أو HTTP عادي.

جدول المقارنة

تفصيل تقني: تكامل نموذجي

لجعل الفروقات ملموسة، لننظر في مهمة شائعة: الاستعلام عن قاعدة بيانات PostgreSQL للحصول على طلبات العملاء وإعادة النتائج إلى المستخدم.

نهج GPT Actions

تحتاج إلى بناء واستضافة HTTP API أمام قاعدة البيانات لديك:

# Flask API server (simplified)
from flask import Flask, request, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/orders", methods=["GET"])
def get_orders():
    customer_email = request.args.get("email")
    conn = psycopg2.connect("dbname=mydb user=myuser")
    cur = conn.cursor()
    cur.execute(
        "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
        (customer_email,)
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return jsonify([
        {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
        for r in rows
    ])

بعد ذلك تكتب مواصفة OpenAPI لنقطة النهاية هذه، وتنشر API مع TLS، وتضبط المصادقة، وتلصق المواصفة في GPT Builder. تتولى OpenAI الباقي: تقرأ المواصفة، وتعرض العملية المتاحة للنموذج، وترسل استدعاء HTTP عند الحاجة.

يتضمن الإعداد الكلي: خادم API قيد التشغيل، ونقطة نهاية HTTPS عامة، ومواصفة OpenAPI، وإعداد GPT Action في واجهة OpenAI.

نهج MCP

تكتب خادم MCP يغلّف استعلام قاعدة البيانات نفسه:

# MCP server using the mcp Python SDK
from mcp.server import Server
from mcp.types import Tool, TextContent
import psycopg2
import json

server = Server("orders-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_orders",
            description="البحث عن طلبات عميل باستخدام البريد الإلكتروني",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "عنوان البريد الإلكتروني للعميل"
                    }
                },
                "required": ["email"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_orders":
        conn = psycopg2.connect("dbname=mydb user=myuser")
        cur = conn.cursor()
        cur.execute(
            "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
            (arguments["email"],)
        )
        rows = cur.fetchall()
        cur.close()
        conn.close()
        results = [
            {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
            for r in rows
        ]
        return [TextContent(type="text", text=json.dumps(results, indent=2))]

إذا كان خادم MCP يعمل محليا (عبر stdio)، فيمكنه الاتصال مباشرة بقاعدة بيانات على localhost أو الشبكة المحلية. لا حاجة إلى نقطة نهاية عامة. إذا كان الخادم يعمل عن بعد، فهو يحتاج إلى نقطة نهاية HTTP، لكنه يتواصل باستخدام JSON-RPC عبر SSE أو Streamable HTTP بدلا من REST الخام.

يتضمن الإعداد الكلي للاستخدام المحلي: سكربت خادم MCP، وإعداد عميل MCP (يشير إلى أمر الخادم)، واتصال قاعدة بيانات. لا مواصفة OpenAPI، ولا شهادة TLS، ولا API مواجهة للعامة.

الفروقات الرئيسية في التطبيق العملي

يتطلب مسار GPT Actions بنية أساسية أكثر (خدمة HTTP منشورة)، لكنه يستفيد من أنماط REST API القائمة التي تعرفها معظم الفرق بالفعل. إذا كان لديك REST API بالفعل، فإضافة GPT Action تكون غالبا مسألة كتابة مواصفة OpenAPI.

يتطلب مسار MCP بنية أساسية أقل لحالات الاستخدام المحلية، لكنه يقدم بروتوكولا جديدا يحتاج فريقك إلى تعلمه. بالنسبة إلى النشر عن بعد، تكون متطلبات البنية الأساسية مشابهة لـ GPT Actions، لكن نموذج الاتصال مختلف (وصلات مستمرة، وتأطير JSON-RPC، وإشعارات ثنائية الاتجاه).

كيف يتعامل Quickchat AI مع النهجين

يدعم نظام AI Actions في Quickchat AI نوعين متميزين من الإجراءات يرتبطان بهذين النموذجين: HTTP Request Actions وRemote MCP Actions.

HTTP Request Actions

تشبه HTTP Request Actions من حيث المفهوم GPT Actions. تضبط نقطة نهاية HTTP، والطريقة، والترويسات، ومعلمات الاستعلام، وقالب جسم JSON. يجمع AI Agent قيم المعلمات من المحادثة، ويرسل backend الخاص بـ Quickchat طلب HTTP من جهة الخادم.

يتكون HTTP Request Action من:

• عنوان URL لنقطة النهاية مع عناصر نائبة {{parameter}} (مثلا https://api.hubapi.com/crm/v3/objects/contacts)
• طريقة HTTP (GET، POST، PATCH، PUT، DELETE)
• ترويسات (بما في ذلك رموز التفويض المستبدلة من جهة الخادم)
• قالب جسم JSON مع عناصر نائبة للمعلمات
• معلمات استعلام مع عناصر نائبة
• مجموعة من المعلمات ذات الأنواع (string، number، boolean، float) مع أوصاف، وأعلام required، وقيم افتراضية

وقت التنفيذ، يحدد الذكاء الاصطناعي المعلمات التي يجب ملؤها استنادا إلى سياق المحادثة. يحقن backend قيم المعلمات في URL، والترويسات، والجسم، وسلسلة الاستعلام، مستبدلا عناصر {{param_name}} النائبة. ثم يرسل طلب HTTP ويعيد الاستجابة إلى الذكاء الاصطناعي لتفسيرها.

لمثال مفصل، راجع دليل HubSpot AI Actions.

Remote MCP Actions

تصل Remote MCP Actions بين AI Agent وخادم MCP خارجي. بدلا من تعريف نقاط نهاية HTTP منفردة، تقدم URL الخاص بخادم MCP وبيانات اعتماد مصادقة اختيارية (رمز bearer و/أو ترويسات مخصصة). يعمل backend الخاص بـ Quickchat كعميل MCP: يتصل بالخادم البعيد، ويكتشف الأدوات المتاحة عبر استدعاء البروتوكول القياسي tools/list، ويعرضها على نموذج الذكاء الاصطناعي.

يتطلب الإعداد:

• URL خادم MCP (نقطة نهاية HTTPS تقدم نقل MCP Streamable HTTP أو SSE)
• رمز مصادقة اختياري
• ترويسات مخصصة اختيارية
• قائمة بالأدوات المكتشفة مع مفاتيح تفعيل/تعطيل منفردة
• إعداد افتراضي لتفعيل الأدوات (ما إذا كانت الأدوات المكتشفة حديثا فعالة افتراضيا)

بعد الاتصال، تصبح كل أداة يعرضها خادم MCP متاحة لـ AI Agent أثناء المحادثات. يرى الذكاء الاصطناعي أسماء الأدوات وأوصافها من استجابة tools/list الخاصة بخادم MCP ويمكنه استدعاؤها عند الحاجة. يمكن تضييق اختيار الأدوات باستخدام إعداد allowed_tools، الذي يتيح لك تفعيل أو تعطيل أدوات محددة من الخادم.

هذا النهج مفيد خاصة عند التكامل مع خدمات تنشر خوادم MCP بالفعل (مثل Shopify’s MCP) لأنك تستطيع الاتصال بالخادم القائم بدلا من بناء إجراءات HTTP منفردة لكل نقطة نهاية.

متى تستخدم أيهما في Quickchat

استخدم HTTP Request Actions عندما:

• تتكامل مع نقطة نهاية REST API محددة
• تريد تحكما دقيقا في صيغة الطلب (الترويسات، بنية الجسم، معلمات الاستعلام)
• لا تملك API خادم MCP منشورا
• تحتاج إلى حقن بيانات الاعتماد من جهة الخادم (مثل رموز OAuth لـ HubSpot وZendesk وغيرهما)

استخدم Remote MCP Actions عندما:

• تنشر الخدمة خادم MCP
• تريد الاتصال بعدة أدوات من خدمة واحدة في إجراء واحد
• تريد اكتشاف أدوات ديناميكيا (يمكن أن تتغير الأدوات المتاحة للذكاء الاصطناعي مع تحديث خادم MCP)
• تبني نظاما متعدد الوكلاء حيث يفوض ذكاء اصطناعي إلى آخر عبر MCP

الإيجابيات والسلبيات

GPT Actions

المزايا:

• تقنية مألوفة. إذا كانت لديك REST API قائمة، فلديك بالفعل معظم ما تحتاج إليه. كتابة مواصفة OpenAPI موثقة جيدا وأدواتها ناضجة.
• صيغة OpenAPI معتمدة على نطاق واسع. يمكن توليد المواصفات تلقائيا من أطر ويب كثيرة (FastAPI، وExpress مع swagger-jsdoc، وSpring Boot مع springdoc).
• تتولى OpenAI تنفيذ طلب HTTP، وإنهاء TLS، ومعالجة الأخطاء على بنيتها الأساسية.
• دعم OAuth 2.0 مدمج مع تحديث تلقائي للرموز.

العيوب:

• مقيدة بنظام OpenAI البيئي. لا يمكن إعادة استخدام إجراء تبنيه من أجل Custom GPT مع Claude أو Gemini أو أي مزود نماذج آخر دون إعادة تنفيذ.
• يجب أن تكون API لديك متاحة علنا. لا يوجد دعم للموارد المحلية أو موارد الشبكات الخاصة.
• لا يوجد اكتشاف ديناميكي للأدوات. إضافة نقطة نهاية جديدة تتطلب تحديث مواصفة OpenAPI وإعادة ضبط GPT.
• أحادية الاتجاه فقط. لا يمكن لـ API لديك دفع تحديثات أو إشعارات مرة أخرى إلى النموذج خارج استجابات HTTP.
• تمر كل البيانات عبر خوادم OpenAI، وقد يكون ذلك مصدر قلق لأحمال العمل الحساسة.
• حدود المعدلات ومهل التنفيذ تتحكم بها OpenAI، وليس أنت.

MCP

المزايا:

• محايد تجاه المورّد. يعمل خادم MCP نفسه مع Claude وCursor وQuickchat AI وأي عميل آخر يطبق البروتوكول.
• يدعم الموارد المحلية. يمكن لخادم MCP يعمل عبر stdio الوصول إلى الملفات، وقواعد البيانات، والخدمات على الجهاز المحلي دون كشف أي شيء للإنترنت.
• اكتشاف ديناميكي للأدوات. يمكن للذكاء الاصطناعي الاستعلام من الخادم عن الأدوات المتاحة أثناء التشغيل. يمكن إضافة الأدوات أو إزالتها أو تحديثها دون إعادة ضبط العميل.
• اتصال ثنائي الاتجاه. يمكن للخوادم إخطار العملاء بالتغييرات (مثلا تم تعديل ملف أو إنشاء سجل جديد).
• جلسات ذات حالة. تستمر الوصلة عبر عدة استدعاءات للأدوات ضمن محادثة واحدة، مما يتيح تدفقات عمل تحتاج إلى سياق من الاستدعاءات السابقة.
• مواصفة مفتوحة. يمكن لأي شخص فحص البروتوكول أو تطبيقه أو توسيعه.

العيوب:

• نظام بيئي أحدث. نشر البروتوكول في أواخر 2024، لذلك لا تزال الأدوات والتوثيق ومعرفة المجتمع قيد التطور مقارنة بـ OpenAPI.
• يتطلب تشغيل خادم MCP. بالنسبة إلى النشر عن بعد، يعني ذلك استضافة خدمة إضافية (مع أنها قد تكون خفيفة).
• لا توجد مواصفة مصادقة موحدة (حتى أوائل 2026). تختلف التطبيقات بين المصادقة القائمة على الرموز، والترويسات المخصصة، وامتدادات OAuth. لا تزال مواصفة MCP Authorization تتطور.
• يضيف تأطير JSON-RPC طبقة تجريد قد تبدو غير مألوفة للفرق المعتادة على REST.
• يختلف دعم العملاء. لا تدعم كل تطبيقات الذكاء الاصطناعي كل وسائل نقل MCP أو ميزاته.

متى تستخدم أيهما

يعتمد الاختيار على قيودك:

اختر GPT Actions إذا:

• كنت تبني حصريا من أجل ChatGPT أو OpenAI API.
• كانت لديك REST API عامة مع مواصفة OpenAPI.
• كنت تحتاج إلى أن تتولى المنصة OAuth 2.0 نيابة عنك.
• كنت تريد أبسط مسار من “API قائمة” إلى “أداة قابلة للاستدعاء من الذكاء الاصطناعي.”

اختر MCP إذا:

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

استخدمهما معا إذا:

• كانت لديك REST API قائمة تريد عرضها كـ GPT Action لمستخدمي ChatGPT، لكنك تريد أيضا نشر خادم MCP لـ Claude وCursor وعملاء آخرين. يمكن مشاركة منطق العمل الأساسي، أما محوّل البروتوكول فهو طبقة رقيقة فوقه.

اتجاه التقارب

بدأت GPT Actions وMCP من فلسفتي تصميم مختلفتين (مبنية على HTTP مقابل مبنية على البروتوكول)، لكن الفجوة تضيق.

أضافت OpenAI دعم MCP إلى Agents SDK في مارس 2025، مما يسمح للوكلاء المدعومين من OpenAI بالاتصال بخوادم MCP إلى جانب استدعاء الدوال التقليدي. هذا لا يستبدل GPT Actions (التي تظل طريقة إضافة استدعاء الأدوات إلى Custom GPTs في ChatGPT)، لكنه يشير إلى أن OpenAI ترى MCP معيارا صالحا لاتصال الوكلاء بالأدوات.

من جهة MCP، يدعم البروتوكول الآن نقل Streamable HTTP، مما يجعل خوادم MCP البعيدة تبدو أقرب إلى خدمات HTTP التقليدية. خادم MCP خلف نقطة نهاية Streamable HTTP ليس بعيدا معماريا عن REST API، رغم أنه لا يزال يستخدم JSON-RPC داخليا بدلا من أعراف REST.

النتيجة المرجحة هي تعايش النمطين. ستظل مخططات OpenAPI الطريقة القياسية لوصف REST APIs، وستستمر GPT Actions (أو آليات مشابهة) في كونها أبسط جسر بين تلك الواجهات ونماذج الذكاء الاصطناعي داخل نظام OpenAI البيئي. سينمو MCP كمعيار متعدد المورّدين لتكامل الأدوات، خاصة في البنى الوكيلة ومتعددة النماذج. المنصات مثل Quickchat AI التي تدعم كلا من HTTP Request Actions وRemote MCP Actions تمنحك المرونة لاستخدام النهج الأنسب لتكاملك المحدد.

قراءات إضافية

• مواصفة MCP
• كيف يعمل Model Context Protocol: شرح MCP
• MCP مقابل HTTP
• امنح AI Agent لديك أدوات حية من خادم MCP بعيد: بناء عملي
• توثيق OpenAI Actions
• مواصفة OpenAPI
• دليل خوادم MCP
• تحديات بناء AI Agent فوق Shopify MCP