خادم Snowflake MCP: الأدوات، والإعداد، والتحكم في التكاليف

ما هو خادم Snowflake MCP

إن خادم Snowflake MCP هو نقطة نهاية MCP مدارة من قبل Snowflake وتعمل داخل حساب Snowflake. بروتوكول سياق النموذج (Model Context Protocol) هو المعيار المفتوح الذي يسمح لوكيل الذكاء الاصطناعي باكتشاف واستدعاء الأدوات في نظام خارجي، ويقوم تطبيق Snowflake بتحويل ميزات Cortex وSQL الخام إلى أدوات قابلة للاستدعاء.

الاختلاف الهيكلي عن خادم MCP المستضاف كخدمة (SaaS): أنت من يحدد واجهة الأدوات. يتم إنشاء الخادم باستخدام الأمر CREATE MCP SERVER ... FROM SPECIFICATION، حيث تكون المواصفات عبارة عن ملف YAML يسرد كل أداة ونوعها وتكوينها. لا يظهر في قائمة الأدوات (tools/list) أي شيء لم تقم بكتابته بنفسك.

يتم دعم خمسة أنواع من الأدوات:

المواصفات الدنيا بسيطة للغاية: إدخال واحد من نوع SYSTEM_EXECUTE_SQL مع ضبط read_only على true، ومهلة زمنية، واسم مستودع البيانات، وبذلك تحصل على خادم MCP لمستودع البياناتجاهز للعمل. تتطلب أنواع أدوات Cortex متطلبات مسبقة، إما خدمة Cortex Search موجودة أو عرض دلالي (semantic view).

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

ما تفعله الوكلاء فعلياً بهذه البيانات

تعتمد حالات الاستخدام المهمة على ربط الأدوات ببعضها بدلاً من مجرد إرسال استعلام واحد:

• التحليلات المخصصة. يطرح المحلل سؤالاً بلغة بسيطة؛ فيقوم الوكيل باستدعاء CORTEX_ANALYST_MESSAGE مقابل عرض دلالي للإيرادات، ويحصل على لغة SQL والنتائج، ثم يشرح الأرقام. هذا هو النموذج الكلاسيكي لـ وكيل تحويل النص إلى SQL، باستثناء أن الدلالات موجودة في Snowflake بدلاً من وجودها في المطالبة (prompt).
• الاسترجاع الهجين. يستعلم وكيل الدعم عن خدمة Cortex Search للحصول على وثائق المنتج، ثم يشغل أداة SQL للتحقق من حالة حساب العميل، ويجيب بناءً على كليهما.
• تصحيح أخطاء خطوط المعالجة. يتحقق الوكيل من عدد الصفوف وحداثة البيانات باستخدام SQL، ويكتشف قسماً قديماً، ثم يقرأ بيانات تعريف المهمة الأولية من جدول آخر.
• مطابقة المقاييس. عندما تختلف لوحتا بيانات، يقوم الوكيل بتشغيل كلا التعريفين، ومقارنة مجموعات الصفوف، والإبلاغ عن نقاط الاختلاف بينهما.

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

لماذا يؤدي الربط المباشر إلى فشل النظام على مستوى الفريق

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

أصبحت تكلفة الحوسبة الآن قراراً يتخذه الوكيل. تحاسب Snowflake على استخدام مستودع البيانات بالثانية طوال فترة تشغيله، مع فرض حد أدنى للرسوم عند كل عملية استئناف. يتخذ الوكيل الذي يكتب لغة SQL الخاصة به قراراً، دون إشراف، بشأن ما إذا كان سيقوم بمسح قسم واحد أو بيتابايت كامل، كما أن نسيان إضافة شرط WHERE في جدول بيانات ضخم قد يؤدي إلى خطأ بسيط في سطر واحد يتبعه فاتورة بأربعة أرقام. كما تقوم الوكلاء بإعادة المحاولة: فالاتصال الذي تنتهي مهلته عند 600 ثانية ويُعاد خمس مرات يعني إجراء خمس عمليات مسح كاملة، دون وجود أي بروتوكول يوجهه للتوقف. هذا هو النظام الوحيد الذي تُعد فيه مقاييس الأدوات وحدود المعدل بمثابة أداة للتحكم في الميزانية، وليست مجرد ميزة تشغيلية.

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

بيانات الاعتماد المشتركة تقضي على إمكانية تحديد المسؤولية. إذا قام كل وكيل بالمصادقة كمستخدم خدمة واحد بدور واحد، فسيكون لكل صف في سجل استعلامات Snowflake نفس الفاعل. لن تتمكن من الإجابة على سؤال "أي وكيل، وبالنيابة عن من، قرأ جدول المدفوعات في الساعة الثانية صباحاً؟"، كما أن تطبيق سياسات خاصة بكل مستخدم يصبح أمراً مستحيلاً لأنه لا يوجد سوى مستخدم واحد.

لا أحد يمتلك المواصفات. سيقوم فريقان بكتابة نسختين، إحداهما حذرة والأخرى بضبط read_only: false وبدون مهلة زمنية، ولن يتحكم أحد في الوكلاء الذين يتم استخدامهم في بيئة الإنتاج.

هذا هو السبب الذي يستدعي وجود مستوى تحكم (control plane) أمامه، وهو ما توفره بوابة MCP .

Want per-user Snowflake access without a shared service account?

Register your Snowflake MCP server on TrueFoundry and let each analyst authorize their own account over OAuth.

Get started free

ربط خادم Snowflake MCP عبر TrueFoundry

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

أنت بحاجة إلى حساب Snowflake ضمن باقة مدفوعةنظرًا لأن تنفيذ SQL محظور في النسخ التجريبية، بالإضافة إلى الحاجة إلى صلاحية ACCOUNTADMIN أو صلاحية إنشاء التكامل (CREATE INTEGRATION) على مستوى الحساب، ومستودع بيانات قابل للاستئناف، ورابط حسابك مكتوبًا بشرطات بدلاً من الشرطات السفلية، وTrueFoundry مجموعة خادم MCP.

الخطوة 1: إنشاء كائن خادم MCP. في ورقة عمل SQL داخل Snowsight (المشاريع > أوراق العمل، وليس شاشة الاستيعاب)، قم بتشغيل أمر CREATE OR REPLACE MCP SERVER مع مواصفات الأداة الخاصة بك. ستصبح قاعدة البيانات والمخطط واسم الخادم جزءًا من رابط الموصل، لذا اختر مخططًا قابلاً للكتابة وغير تابع للنظام وتجنب استخدام رمز $ في الأسماء.

الخطوة 2: إنشاء تكامل أمان OAuth. يمكن لـ ACCOUNTADMIN فقط القيام بذلك. استخدم TYPE = OAUTH، وOAUTH_CLIENT = CUSTOM، وOAUTH_CLIENT_TYPE = 'CONFIDENTIAL' لضمان بقاء السر على جانب الخادم، وOAUTH_ISSUE_REFRESH_TOKENS = TRUE، مع تحديد صلاحية رمز التحديث بالثواني، وOAUTH_ENFORCE_PKCE = TRUE. عنوان URI لإعادة التوجيه هو رابط الاستدعاء المعروض في نموذج TrueFoundry إضافة خادم MCP :

https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback

فخ واحد: لا تقم بإضافة قائمة BLOCKED_ROLES_LIST تحتوي على ACCOUNTADMIN أو SECURITYADMIN. يقوم الإعداد OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST بحظرها افتراضيًا بالفعل، لذا فإن إدراجها سيؤدي إلى حدوث خطأ. استرجع بيانات الاعتماد باستخدام SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<INTEGRATION_NAME>')، مع كتابة الاسم بأحرف كبيرة.

الخطوة 3: إنشاء دور غير إداري ومنح صلاحية الوصول. أدوار المسؤول محظورة في OAuth، لذا يجب أن يهبط المستخدم على دور افتراضي غير ذي صلاحيات. امنح صلاحية USAGE على المستودع وقاعدة البيانات والمخطط وخادم MCP، ثم امنح صلاحيات كل أداة على حدة، مثل USAGE ON CORTEX SEARCH SERVICE أو SELECT ON SEMANTIC VIEW. الوصول إلى الخادم لا يمنح صلاحية الوصول إلى أدواته. قم بتعيين DEFAULT_ROLE وDEFAULT_WAREHOUSE للمستخدم؛ فلن تتم تهيئة جلسة OAuth بدونهما.

الخطوة 4: السماح بخروج حركة مرور البوابة (Gateway Egress). إذا كانت سياسات الشبكة مفعلة، قم بإضافة عناوين IP الخاصة بـ TrueFoundry إلى القائمة المسموح بها. يتصل البوابة من خادم إلى خادم من بنية TrueFoundry التحتية، وليس من متصفح المستخدم، لذا فإن جلسة المتصفح النشطة لا تعد دليلاً على الاتصال. في حسابات PrivateLink، قم بتسجيل الـ عام عنوان الحساب واجعل نقطة نهاية الرمز المميز (token endpoint) عامة.

الخطوة 5: التسجيل في TrueFoundry. في مجموعة خوادم MCP الخاصة بك، انقر على إضافة خادم MCP واختر الاتصال بأي خادم MCP عن بُعد.

أدخل عنوان URL الخاص بخادم MCP، والذي يتبع هذا الشكل:

https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name>

حدد OAuth2 مع نوع المنح رمز التفويض، ثم املأ عنوان URL للتفويض https://<account_url>/oauth/authorize، وعنوان URL للرمز المميز https://<account_url>/oauth/token-request، ومعرف العميل الخاص بك وكلمة السر، طرق تحدي الكود المدعومة S256، مصدر JWT رمز الوصول، و النطاقات رمز التحديث (refresh_token). قم بتعيين التحكم في الوصول، ثم حفظ. قم بتخزين معرف العميل (client ID) والسر (secret) في مخزن أسرار TrueFoundry وأشر إلى الاسم المؤهل بالكامل (FQN) بدلاً من تضمينهما مباشرة.

بخصوص النطاقات: احتفظ بـ refresh_token، لأنه بدون ذلك تنتهي صلاحية الجلسات كل عشر دقائق تقريباً. احذف الخيار الآخر، session:role:<role>: يتجاهله الخادم، حيث يقوم بتحديد الدور من DEFAULT_ROLE، كما أنه يضيف وضع فشل متعلق بحساسية حالة الأحرف.

كيف تعمل المصادقة فعلياً

تحتفظ TrueFoundry بـ الواردة ، وهي كيفية إثبات العميل لهويته أمام البوابة، بشكل منفصل عن الصادرة، وهي كيفية إثبات البوابة لهويتها أمام Snowflake. هاتان الطبقتان مستقلتان.

تدعم المصادقة الواردة أربع طرق:

تمنح رموز الحساب الافتراضي (Virtual Account tokens) كل طلب وصولاً متطابقاً، لذا فهي غير قابلة للاستخدام هنا. بالنسبة للمستودع، حيث تعتمد حجة الأمان بالكامل على وراثة كل شخص لدوره الخاص، استخدم رمز PAT أو رمز IdP للوارد.

المصادقة الصادرة هي Snowflake OAuth مقابل التكامل الذي أنشأته. للتفويض، افتح الخاص بالخادم الأدوات قسم، أو إضافة خوادم الأدوات/MCP في ساحة التجارب (Playground)، ثم انقر على اتصل الآن. ستتم إعادة توجيهك إلى Snowflake للموافقة، ولن تطلع TrueFoundry مطلقاً على بيانات اعتمادك.

هذا هو الجزء الذي يحمي بياناتك. يعمل كل مستخدم بموجب أذونات التحكم في الوصول المستندة إلى الأدوار (RBAC) الخاصة به في Snowflake، والتي يتم تحديدها من خلال DEFAULT_ROLE الخاص به. البوابة لا تقرر الصفوف التي يمكنك رؤيتها، بل Snowflake هو من يفعل ذلك. كل ما قمت ببنائه هناك يظل سارياً دون تغيير: منح الأدوار على قواعد البيانات والمخططات والجداول، بالإضافة إلى سياسات الوصول إلى الصفوف وإخفاء البيانات الديناميكي إذا كنت تستخدمها، وكلاهما يتطلب إصدار Snowflake Enterprise أو أعلى [تحقق]. الوكيل الذي يعمل نيابة عن محلل مبتدئ يرى بالضبط ما يراه ذلك المحلل.

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

إذا كان لكل عميل حساب Snowflake خاص به، فلا يمكن لمعرف عميل واحد أن يغطيها جميعاً، لذا يجب عليك تسجيل إدخال منفصل لكل حساب.

تحديد نطاق الأدوات قبل الإطلاق

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

مفاتيح تبديل لكل أداة. عند إيقاف تشغيل أداة، يتم حذفها تماماً من قائمة الأدوات. لا يراها العملاء ولا يمكن استدعاؤها؛ وهذا يختلف عن التصفية على مستوى المطالبة (prompt-layer). النمط الشائع في المستودعات هو إبقاء Cortex Analyst وCortex Search مفعلين مع تعطيل SYSTEM_EXECUTE_SQL الخام. بهذه الطريقة، يواصل المحللون استخدام الاستعلام باللغة الطبيعية عبر عرض دلالي قمت بتنظيمه، بينما يفقد الوكيل القدرة على كتابة استعلامات SQL عشوائية على جداول عشوائية. وهذا أكثر أماناً وأقل تكلفة.

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

انقر على أيقونة القلم بجانب أي أداة لتجاوز طريقة عرضها للنموذج:

إن الوصف المتجاوز، والذي يصل إلى 20,000 حرف، ذو قيمة استثنائية هنا. أوصاف أدوات Snowflake هي ما تكتبه أنت في المواصفات، والوصف الغامض يجعل النموذج يلجأ إلى SYSTEM_EXECUTE_SQL بينما كان بإمكان أداة تحليل منظمة الإجابة على السؤال. تعليقات أداة MCP تحدد الأداة كـ للقراءة فقط أو تدميرية، مما يضبط readOnlyHint أو destructiveHint، ويغذي سياسات الموافقة أدناه.

من يمكنه فعل ماذا: أدوار المتعاونين

يتم ربط التحكم في الوصول بالمستخدمين أو الفرق أو الحسابات الافتراضية عبر بُعدين: الخوادم التي يمكن للهوية الوصول إليها، والأدوات التي يمكنها استدعاؤها.

يتمتع فريق المنصة بصلاحية المدير (Manager)، وتحصل فرق التحليلات على صلاحية المستخدم (User)، بينما يحصل مالك الحوكمة على صلاحية الموافق (Approver). هذا هو نفسه التحكم في الوصول إلى MCP النموذج المستخدم عبر كل خادم في السجل.

Ready to put a boundary around your warehouse?

Register Snowflake, disable raw SQL execution, and hand your analysts a curated text-to-SQL agent in one sitting.

Start free on TrueFoundry

u

الموافقة البشرية على الأدوات ذات التأثير التدميري

يُعد تعطيل الأدوات إجراءً صارماً. في بعض الأحيان، قد ترغب في أن يقوم الوكيل بالكتابة في جدول أو تشغيل استعلام غير محدود، ولكن ليس دون إشراف. عند استدعاء أداة مقيدة، يتم تعليق الطلب، وإنشاء طلب موافقة، وإخطار الموافقين. بمجرد موافقة شخص ما، تنجح الاستدعاءات لفترة زمنية قابلة للتهيئة. أنشئ سياسة ضمن AI Gateway > Policies > MCP Tool Approval، والتي تحمل علامة "تجريبي" (Beta) في وحدة التحكم:

تحدد كل سياسة الخوادم التي تقيدها وتختار نطاق الموافقة:

بالنسبة لـ Snowflake، عادة ما يكون التحديد بالاسم على أداة تنفيذ SQL هو الخيار الأنسب: حافظ على استمرار عمل أدوات Cortex المنسقة وقم بتعليق كل استدعاء SQL خام لمراجعته من قبل شخص. عندما تتداخل النطاقات، يسود النطاق الأكثر تحديداً: التحديد بالاسم يتفوق على التحديد التدميري، وكلاهما يتفوق على النطاق العام. الصلاحية إما لمرة واحدة أو مستندة إلى الوقت بالدقائق، وعند تعارض السياسات، تسود السياسة الأكثر تقييداً؛ لذا فإن خيار "لمرة واحدة" يتفوق على نافذة الـ 10 دقائق، والتي بدورها تتفوق على نافذة الـ 30 دقيقة.

يتم إخطار الموافقين عبر البريد الإلكتروني، أو Slack، أو PagerDuty، أو MS Teams، ويعرض كل طلب الأداة، والسياسة، والجهة الطالبة، و وسيطات الأداة الفعلية. في بيئة المستودع، هذا الجزء الأخير هو الميزة الأساسية: حيث يقرأ الموافق نص استعلام SQL الحرفي قبل تشغيله، مما يضمن اكتشاف أي استعلام "cross-join" غير محدود من قبل شخص بدلاً من اكتشافه في فاتورة الشهر التالي. أثناء حالة الانتظار، يتلقى الطرف المستدعي نتيجة JSON-RPC تحمل _meta.approval_status: "pending" بدلاً من خطأ، مما يسمح للوكيل المصمم جيداً بالانتظار بدلاً من التوقف عن العمل.

تُحدد صلاحيات الوصول لكل مستخدم على حدة، لذا فإن منح الصلاحية لمحلل واحد لا يعني منحها للفريق بأكمله.

الاختبار في بيئة تجربة الأدوات (Tool Playground)

قبل ربط الوكيل (Agent) بالأداة، قم بتجربة الأدوات يدوياً. انقر على تجربة بجوار الأداة، واملأ المعلمات، ثم تنفيذ الأداة لقراءة بيانات JSON الخام. تجربة معطلة للأدوات التي قمت بإيقاف تشغيلها.

هذا هو المكان الأمثل لاكتشاف أخطاء الإعداد بتكلفة بسيطة. الأداة التي تظهر خطأً تكون غالباً بسبب نقص في صلاحيات الوصول، حيث أن صلاحية USAGE ON MCP SERVER تتيح الاكتشاف فقط ولا تتيح التنفيذ. أما الأداة التي تتوقف عن الاستجابة فغالباً ما تعني عدم وجود مستودع بيانات (Warehouse) افتراضي، أو أن المستودع الحالي لا يمكن استئنافه.

استخدامها من بيئة التطوير (IDE) الخاصة بك

افتح علامة التبويب كيفية الاستخدام للحصول على رابط البوابة (Gateway URL) الخاص بمستأجرك ومقتطفات برمجية جاهزة للنسخ.

تغطي هذه الميزة كلاً من Claude Code وVS Code وClaude Desktop وCursor وWindsurf وCodex، بالإضافة إلى حزم تطوير MCP للغتي Python وTypeScript. استخدم الرابط الموجود في علامة التبويب هذه بدلاً من تجميعه يدوياً؛ فبناء الرابط يدوياً هو السبب الأكثر شيوعاً لاتصال العميل دون ظهور أي أدوات.

ما تحصل عليه بمجرد تفعيل البوابة

في مستودع البيانات، تُعد الطبقة التشغيلية هي الوسيلة التي تعرف من خلالها التكاليف التي تستهلكها وكلاؤك.

مقاييس مستوى الأداة. توفر لوحة تحكم مقاييس MCP تحليلاً لعدد الطلبات في الثانية، وزمن الاستجابة عند مستويات P50/P75/P90/P99، ومعدل الفشل حسب نوع الخطأ، بالإضافة إلى ترتيب الأدوات حسب عدد الطلبات.

تعامل مع هذه البيانات كلوحة تحكم للنفقات، وليس كلوحة تحكم لزمن الاستجابة. فمؤشر زمن الاستجابة P99 لأداة SQL يعد مقياساً تقريبياً لحجم الحوسبة التي تستهلكها سلسلة طويلة من الاستعلامات، كما أن ارتفاع معدل الفشل مقترناً بزيادة عدد الاستدعاءات هو علامة على وجود حلقة إعادة محاولة تستنزف الأرصدة. لا يغني أي من هذا عن أدوات التحكم الخاصة بـ Snowflake: احتفظ بمراقب للموارد على المستودع الذي تستخدمه الأدوات، واحرص على ضبط مهلة الاستعلام query_timeout بدقة.

مراقبة كاملة للطلبات. يتم تتبع كل استدعاء للأداة مع هوية المتصل، واسم الأداة، والمدخلات، وزمن الاستجابة، وتصديرها عبر OpenTelemetry إلى Grafana أو Datadog أو Prometheus. ولأن المصادقة الخارجية تعتمد على OAuth لكل مستخدم، فإن هوية المتصل تتطابق مع المستخدم في سجل استعلامات Snowflake، مما يجعل الإجابة على سؤال "من قام بتشغيل هذا" واضحة ومحددة.

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

عبء تشغيلي منخفض. تضيف البوابة حوالي 3-4 مللي ثانية من زمن الاستجابة وتتعامل مع أكثر من 350 طلباً في الثانية على وحدة معالجة مركزية افتراضية (vCPU) واحدة. مقارنة باستعلام يُقاس بالثواني، يعتبر هذا ضئيلاً جداً.

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

إلغاء الوصول

يمكن لمسؤولي المستأجر مسح جميع بيانات الاعتماد المخزنة على الخادم في إجراء واحد، من خلال القائمة المكونة من ثلاث نقاط بجوار تعديل:

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

الحد مهم: هذا يمسح الرموز المميزة عند البوابة فقط، وليس المنح في Snowflake. أثناء وقوع حادث فعلي، قم أيضًا بتعطيل تكامل الأمان وتدوير سر العميل.

نقاط هامة يجب معرفتها

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

الوصول إلى الخادم لا يعني الوصول إلى الأداة. يتيح GRANT USAGE ON MCP SERVER للدور الاتصال واكتشاف الأدوات. يتطلب تشغيلها الحصول على الأذونات الأساسية: USAGE على خدمة Cortex Search، وSELECT على العرض الدلالي، وامتيازات الجدول لـ SQL.

العروض الدلالية، وليس النماذج الدلالية. تقبل CORTEX_ANALYST_MESSAGE معرف عرض دلالي. توجيهها إلى نموذج دلالي لن ينجح، والخطأ الناتج ليس واضحًا.

قراءات ذات صلة

• ما هي بوابة MCP: البنية وحالات الاستخدام
• شرح مصادقة MCP
• التحكم في الوصول إلى MCP: تأمين وكلاء الذكاء الاصطناعي باستخدام بوابة MCP
• شرح خادم MCP الافتراضي
• أفضل ممارسات أمان خادم MCP

الخلاصة

يُعد خادم Snowflake MCP أقوى أداة يمكنك منحها للوكيل، ولكنه في الوقت نفسه يحمل مخاطر فشل باهظة التكلفة. فبينما قد تؤدي معظم الخوادم في السجل إلى عمليات كتابة غير مقصودة ومحرجة، فإن هذا الخادم قد يتسبب في فواتير ضخمة وقراءة واسعة النطاق لبيانات تم دمجها مسبقاً لتسهيل الوصول إليها.

أنت لا تبدأ من الصفر فيما يتعلق بالمخاطرة الثانية؛ إذ تُعد سياسات التحكم في الوصول المستندة إلى الأدوار (RBAC)، وسياسات الوصول إلى الصفوف، وسياسات الإخفاء في Snowflake هي خط الدفاع الأول. كما أن استخدام OAuth لكل مستخدم هو ما يضمن توريث الوكيل لهذه الصلاحيات بدلاً من تجاوزها عبر حساب خدمة مشترك. وتتمثل مهمة البوابة في النصف الآخر من المعادلة: تحديد الأدوات المتاحة، وحجز الأدوات الخطرة للمراجعة البشرية، وتوفير سجل للمكالمات وعرض للمقاييس لضمان عدم مفاجأتك بالتكاليف.

Connect your Snowflake MCP server on TrueFoundry,

Free to start