خادم MCP من 2GIS: كيف يُمنع نموذج اللغة الكبير من اختراع العناوين والإحداثيات

أصدرت شركة 2GIS خادم MCP (باسم mcp-2gis) — أداة تربط وكلاء الذكاء الاصطناعي مباشرة بخدمات الجيومكانية الخاصة بمنصة واجهات برمجة التطبيقات (API) لشركة 2GIS. ويضم الخادم حالياً ست أدوات: البحث عن الأماكن والمنظمات، الترميز الجغرافي المباشر، الترميز الجغرافي العكسي، بناء المسارات، خطوط التساوي الزمني، والخرائط الثابتة.

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

البنية المعمارية: إطار مشترك إضافة إلى محوّلات رقيقة

القرار الأساسي هو بنية معمارية قابلة للتوسع. فبدلاً من جعل كل أداة مستقلة بالكامل بمعالجة أخطاء خاصة بها وتسجيل وتجمعات HTTP منفصلة، قسّمت 2GIS النظام إلى طبقات:

1. FastMCP middleware — المصادقة، القائمة المسموح بها (allowlist)، المقاييس، المهلات الزمنية (timeouts) 2. tools/<domain>.py — مخطط MCP، التحقق من صحة الإدخال/الإخراج عبر Pydantic، تحويل النتيجة 3. tools/gis.py — تبعيات دورة حياة (lifespan) وحدود مشتركة لمعالجة الأخطاء 4. integrations/<domain>_api.py — الرابط (URL)، المعطيات، والتفاعل عبر JSON مع واجهة برمجة التطبيقات المحددة لـ 2GIS 5. integrations/gis_client.py — تجمع httpx مشترك لجميع الطلبات، حقن مفتاح API، وتحويل أخطاء HTTP

كل طبقة مسؤولة فقط عن جزئها. ووحدة التكامل تستقبل الرابط ومخطط التفاعل مع واجهة برمجة التطبيقات، لكنها لا ترى الترويسات (headers) ولا البيئة (environment) ولا MCP نفسه. والأداة لا تُنشئ تجمعات HTTP ولا تقرأ المتغيرات. هذا الفصل يقلل التكرار ويسمح بإضافة أدوات جديدة أو خوادم MCP جديدة دون نسخ كميات كبيرة من الكود.

من جهة الطرف المستدعي

هناك دالة مساعدة واحدة تُدعى `run_gis_tool` تجمع كل التبعيات، وتفتح span خاصاً بالأداة، وتترجم الأخطاء إلى عقدين مختلفين. وهذا تنفيذ لمتطلب حاسم: يجب أن يصل خطأ العمل (مفتاح غير صحيح، عدم وجود وصول) إلى الوكيل كنتيجة للأداة مع رمز قابل للقراءة آلياً، لا كفشل في البروتوكول. وإلا فلن يفهم النموذج ماذا يفعل، وسيستدعي الأداة من جديد.

أما عطل الشبكة أو تجاوز المهلة الزمنية، فعلى العكس، يجب أن يظل خطأ MCP — فلا جدوى من التفكير في هذا الأمر، بل الجدوى في إعادة محاولة الطلب.

عقد لا إقناع

تتطلب إضافة أداة جديدة:

• نماذج Pydantic للإدخال/الإخراج مع الأنواع والتحقق من الصحة • مخطط JSON — عقد المعطيات (ما هو إلزامي، وما هو اختياري، وما القيم المسموح بها) • وصف الأداة (description) — النص الذي يقرأه النموذج ليقرر استدعاء الأداة أم لا وبأي معطيات • اختبارات وحدة (unit) واختبارات تكامل داخل العملية (in-process)

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

الخلاصة

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