Google Search Console MCP: ما تكشفه فعليًا أربعة خوادم MCP للـ SEO

خوادم MCP الخاصة بـ Google Search Console هي الطريقة التي تقرأ بها الوكلاء بيانات البحث لديك دون تصدير ملف CSV أولًا. هذا الجزء السهل. الجزء غير السهل هو التمييز بين الخوادم، لأنها كلها تعرّف عن نفسها بالطريقة ذاتها، ولا يظهر الفرق إلا حين تسألها عمّا تستطيع فعله بالفعل.

فسألنا. في 12 سبتمبر 2026، وصلنا أربعة خوادم MCP منشورة للـ SEO، وأرسلنا إلى كل واحد منها طلب tools/list، وأحصينا ما أعاده. كانت الأعداد 42 و21 و4 و1.

هذا التفاوت ليس ترتيبًا للجودة. إنه قرار تصميمي، وهو يغيّر ما يستطيع الوكيل فعله، وكم يكلّفك على صعيد السياق، وكم من بياناتك يخرج من جهتك.

ما اختبرناه، وكيف

المنهج: شُغّل كل خادم تمامًا كما توجّه وثائقه، عبر المدخل والمخرج القياسيين، أو عبر HTTP حين حدّدت الوثائق هذا النمط. أرسلنا مصافحة initialize الخاصة بـ MCP، ثم tools/list، وسجّلنا عدد الأدوات وأسماءها. لم نستخدم أي مفاتيح API إلا حيث رفض الخادم العمل بدون مفتاح.

خادم واحد، حزمة Search Console من طرف ثالث، لم يُكمل المصافحة داخل نافذتنا البالغة 50 ثانية، فاستُبعد بدل أن يُقيَّم. قوائم الأدوات تتغيّر مع كل إصدار، لذا تعامل مع هذه الأعداد كلقطة صباح يوم ما، لا كصفة دائمة لأي مورّد.

التصاميم الأربعة، والغرض من كل واحد

غلاف (21 أداة). يأخذ mcp-gsc واجهة Search Console API ويلفّ كل تقرير في أداة مسمّاة. تُقرأ قائمته كوصف وظيفي لمحلل بحث: search_analytics وinspect_url وtop_movers وquick_wins وcannibalization وcontent_decay وdevice_country_breakdown وctr_anomalies وweekly_seo_report وindexing_coverage. الميزة أن النموذج لا يحتاج إطلاقًا إلى تركيب استعلام. الثمن أنك ترث رأي شخص آخر في ما ينبغي أن يحتويه التقرير، وأنك لا تستطيع طلب أي شيء خارج القائمة.

مرآة المنصة كاملة (42 أداة). يعرض خادم Ahrefs سطح منتج المورّد نقطة نهاية بنقطة نهاية: rank-tracker-overview وrank-tracker-competitors-overview وkeywords-explorer-matching-terms وkeywords-explorer-volume-history وbatch-analysis. هذه أغنى قائمة قِسناها، وهي أيضًا الأغلى على صعيد السياق، لأن كل تعريف أداة يُحمَّل سواء كان ذا صلة بالمهمة أو لا. وهي أيضًا الأوضح في بيان المقايضة: اتساع القدرة مقابل ضريبة دائمة على كل موجّه.

بوابة (4 أدوات). ذهب خادم الإصدار الثالث من DataForSEO في الاتجاه المعاكس. يعرض docs_index وdocs_list_sections وdocs_search، وأداة عامة واحدة api_request. بدل تسمية كل نقطة نهاية، يعلّم النموذج أن يجد الوثائق ثم يجري نداءً موثَّقًا. أربع أدوات تغطي واجهة برمجية فيها مئات النقاط، ويدفع النموذج ثمن التحديد عند النداء لا عند التحميل. في فحصنا أعادت نقطة HTTP الرسالة invalid auth بلا بيانات اعتماد، واستجابت بشكل سليم معها. وهذا هو السلوك المرغوب.

خادم أحادي الأداة (أداة واحدة). لا يعيد seo-mcp-server سوى أداة واحدة هي ai_content_detect. لا عيب في خادم صغير، لكن ينبغي أن يكون صريحًا في ماهيته: عرض توضيحي أو فحص منفرد، وليس طاولة عمل SEO. وإذا ثبّته وأنت تتوقع تقريرًا أسبوعيًا، فستُخيَّب بطريقة لم تذكرها تعليمات التثبيت قط.

أربعة أنماط. اثنان منها يتوسّعان إلى عمل تقارير حقيقي، وكل منهما يتوسّع في اتجاه مختلف.

لماذا عدد الأدوات هو العنوان الخطأ

خادمان بالعدد نفسه يمكن أن يتصرفا بشكل مختلف تمامًا، لأن المهم هو شكل الحدود لا الرقم.

الغلاف يقرّر أسئلتك مسبقًا. هذا مفيد فعليًا حين تكون الواجهة الأساسية صعبة والغلاف يرمّز خبرة حقيقية، وقائمة mcp-gsc تفعل ذلك. ويصبح قيدًا في اللحظة الأولى التي يكون فيها سؤالك خارج القائمة، ولا سبيل لدوران حولها.

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

الاختبار العملي ليس "كم عدد الأدوات" بل "هل يعرض الخادم ذلك الشيء الذي أسأل عنه كل أسبوع". في عمل تتبّع الترتيب، يعني ذلك عادةً تحليلات البحث بتقسيم التاريخ والجهاز، وفحص عنوان URL. يغطي الغلاف والبوابة ذلك. أما خادم الـ 42 أداة فيغطيه، ويغطي معه أربعين شيئًا آخر لن تستخدمه اليوم.

الفحوص التي تهم فعلًا قبل تثبيت أي شيء

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

تحقق من الذي يغادر جهازك. البوابة التي تمرّر بيانات اعتماد API إلى مورّد لها طبيعة خطر مختلفة عن الغلاف المحلي الذي يخاطب Google API برمزك الخاص. قد يكون كلاهما سليمًا. لكن واحدًا فقط يعني أن طرفًا ثالثًا يرى كل كلمة مفتاحية تجلبها.

شغّل اختبار الاستجابة الفارغة. اطلب من الخادم نطاقًا زمنيًا بلا بيانات، مثل خاصية لم تُطلقها بعد. الخادم المصنوع جيدًا يعيد مجموعة نتائج فارغة. والسيئ يعيد خطأً، والوكيل الذي يتلقى خطأً كثيرًا ما يلفّق تفسيرًا معقولًا لبيانات ناقصة. هذا الاختبار الواحد يلتقط مشاكل أكثر من أي مراجعة كود.

قد يعرض خادمان التقرير نفسه بالضبط، ويختلفان تمامًا في من يرى بيانات اعتمادك.

افحص ما يحدث حين تفشل أداة. حدود المعدل حقيقية: يسمح Search Console بـ 1,200 استعلام في الدقيقة لكل موقع، وموجة إعادات محاولة من الوكيل تستهلكها وحدها. الخادم الذي يُظهر الحد يكون قابلًا للاستخدام. والخادم الذي يعيد لا شيء بصمت يعلّم وكيلك أن ظهورك صفر، وذلك أسوأ من الخطأ. الحد نفسه يشكّل أي متتبّع ترتيب مبنّي بنفسك، لذا تستحق ميزانية الطلبات سطرًا في ملف الإعداد.

توصيله بوكيل

الإعداد هو الجزء الصغير. الموضع هو ما يحدّد إن كنت ستحصل على القيمة أصلًا.

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "mcp-gsc"],
      "env": { "GSC_CREDENTIALS": "/path/to/service-account.json" }
    },
    "dataforseo": {
      "url": "http://localhost:3000/mcp",
      "headers": { "Authorization": "Basic <base64 login:password>" }
    }
  }
}

ثلاث قواعد نستخدمها، مرتبة بحسب حجم الألم الذي تمنعه.

خادم واحد لكل مصدر بيانات. خادمان يدّعي كل منهما أنه يجيب عن أسئلة الترتيب ينتجان جوابين، فيختار الوكيل الأكثر إقناعًا في سمعه لا الأصح. أعطِ Search Console للغلاف، وبيانات SERP من طرف ثالث للبوابة، واكتب أي الحقول تعدّها مرجعية عند أي منهما.

أبقِ تعريف التقارير خارج الخادم. الأدوات تمنح الوكيل وصولًا إلى البيانات. وهي لا تمنحه تعريفاتك: أي الخصائص تُحتسب، وأي الاستعلامات هي محرّك الإيراد، وهل الترتيب متوسط فترة أم لقطة يومية. تلك تنتمي إلى ملف تعليمات يقرأه الوكيل قبل أن ينادي أي شيء، وهي الفرق بين ملخّص مفيد وخطأ واثق. وسير عمل التقرير الأسبوعي مثال حيّ على تعريفات تعيش خارج الأدوات.

تحقق من التشغيل الأول يدويًا. اجلب أسبوعًا من تحليلات البحث عبر الخادم وقارنه بالأسبوع نفسه في واجهة Search Console. إن لم تتطابق الأرقام فلديك مشكلة نطاق زمني أو إسناد، وكل تقرير آلي لاحق سيرثها.

رأي Auspia: سؤال MCP ليس "أي خادم أفضل". بل "أي حدود تريد أن ترسمها بين وكيلك وبياناتك". الغلاف عقد تقبله مسبقًا. والبوابة مسؤولية تقبلها في كل تشغيل. وأي الاثنين يناسب سير عمل ترتيب أوسع هو ما يرتّبه دليل قدرات الوكلاء بحسب المهمة. كلاهما مشروع، والفريق الذي يحترق هو الذي يجري الاختيار دون أن يلاحظ أنه اختار.

الأسئلة الشائعة

هل تنشر Google خادم MCP رسميًا لـ Search Console؟ حتى 12 سبتمبر 2026، لم نجد واحدًا في سجلات الحزم. خوادم Search Console التي اختبرناها مشاريع مجتمعية أو من مورّدين تعمل فوق الواجهة الرسمية. الرسمي هو طبقة API، وهذا بحد ذاته ليس عيبًا آليًا، لكنه يعني أن ذلك الخادم تبعية صيانة تختارها أنت.

كم عدد أدوات MCP الكثير على جلسة وكيل واحدة؟ لا عدد ثابت. الحد العملي هو ما إذا كانت قائمة الأدوات تدفع تعليماتك خارج نافذة السياق. حمّل خادمًا بـ 42 أداة لمهمة تحتاج اثنتين منها فقط، وأنت تدفع كل نداء مقابل أربعين تعريفًا. حمّل الخوادم الضيقة للعمل الروتيني والواسعة للاستكشاف.

هل يستطيع وكيل استخدام MCP مع Search Console دون حساب خدمة؟ نعم، بشرط أن يكون الخادم قد نفّذ تدفق OAuth وأكملته أنت محليًا مرة واحدة. مسار حساب الخدمة أسهل في الأتمتة وأصعب في التسليم لشخص، لذا يشغّل الفرق عادةً الاثنين: حساب خدمة للتشغيل المجدول و OAuth للعمل العارض.

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

الكاتب: Julian Mercer، باحث تكامل MCP في Auspia عبر أكثر من 40 سلسلة أدوات للوكلاء. يكتب عن بروتوكولات الوكلاء وحدود الأدوات والتكلفة التشغيلية لوصل النماذج اللغوية ببيانات حيّة.