הגדרת Snowflake MCP עבור Notion

הסוכנים המותאמים אישית ו-סוכן Notion שלכם יכולים להתחבר ל-Snowflake דרך שרת MCP (פרוטוקול הקשר מודל) ש-Snowflake מריצה. לאחר ההגדרה, תוכלו לשאול את הסוכן שלכם על נתוני מחסן הנתונים של Snowflake ולקבל תשובות ישירות ב-Notion.

ההגדרה מתבצעת בשלבים, ולאנשים שונים יש אחריות על כל אחד מהם:

• מנהל Snowflake מגדיר את התפקיד, מחסן הנתונים ושרת ה-MCP המנוהל על ידי Snowflake.

• בעלים או מנהל של סביבת עבודה ב-Notion מגדיר את חיבור ה-Snowflake MCP עבור סביבת העבודה.

• חברי סביבת העבודה יכולים לאחר מכן להתחבר ל-Snowflake MCP מסוכנים מותאמים אישית באמצעות אישורי ה-Snowflake שלהם, או לחבר את Snowflake ישירות לסוכן Notion שלהם. שלבים 1–10 במאמר זה זהים עבור שני הנתיבים. הנתיבים מתפצלים בשלב 11, בהתאם לסוכן שברצונכם לחבר.

• הכלים הזמינים עשויים להשתנות בהתאם לאזור הענן של Snowflake שלכם.

• שרת ה-MCP המנוהל של Snowflake אינו זמין בסין היבשתית או באזורים ממשלתיים.

• סביבת העבודה שלכם ב-Notion חייבת להיות בתוכנית לעסקים או בתוכנית Enterprise.

• אפשר להשתמש ב-Notion בדפדפן או באפליקציה למחשב. התכונה הזו לא זמינה בנייד.

• לחברה שלכם דרוש חשבון Snowflake.

• כדי לבנות סוכן מותאם אישית, עליכם להיות בעלי הרשאה ליצירת סוכנים בסביבת העבודה שלכם.

לפני שהצוות שלכם יוכל לחבר את Snowflake ל-Notion, מנהל Snowflake צריך להגדיר גישה. זהו השלב המורכב ביותר, וצריך לבצע אותו רק פעם אחת. מתאמים את ההגדרה עם מנהל סביבת העבודה ב-Notion: ‏Notion מספקת URI להפניה מחדש, ו-Snowflake מספקת מזהה לקוח וסוד לקוח של OAuth.

תגדירו תפקיד ומחסן נתונים, תיצרו את שרת ה-MCP המנוהל על ידי Snowflake, תעניקו לו גישה למשאבים הדרושים לו, תגדירו את היקף ה-OAuth ואת אינטגרציית האבטחה, ותוסיפו מדיניות רשת אם הארגון שלכם דורש זאת.

לפני שמתחילים, ממלאים את דף העבודה הזה עם מנהל סביבת העבודה ב-Notion. חברי סביבת העבודה יכולים לדלג על השלב הזה ולהיכנס באמצעות חשבונות Snowflake משלהם לאחר השלמת ההגדרה.

שם המארח של החשבון כולל מקפים, לא קווים תחתונים. כל שם אובייקט בכתובת ה-URL של השרת צריך להתאים לשם האובייקט המקביל ב-Snowflake.

ככל האפשר, משתמשים בתפקיד ייעודי עם הרשאות מינימליות ובמחסן נתונים מאושר אחד.

תפקיד מוגבל ללא תפקידים משניים (מומלץ). קל יותר להבין את המודל הזה ולבקר אותו. מגדירים OAUTH_USE_SECONDARY_ROLES = NONE, מציינים ALLOWED_ROLES_LIST ומשתמשים בהיקף ההרשאות של Notion‏ session:role:<mcp_access_role>.

תפקידי המשנה המוגדרים כברירת מחדל של המשתמש (אופציונלי). משתמשים במודל הזה רק אם השרת זקוק להרשאות שכל משתמש מקבל דרך DEFAULT_SECONDARY_ROLES שלו ב-Snowflake. מגדירים OAUTH_USE_SECONDARY_ROLES = IMPLICIT, לא כוללים את ALLOWED_ROLES_LIST ומשתמשים בהיקף הרשאות מפורש לתפקיד הראשי. Snowflake אינה מאפשרת תפקידים משניים מסוג IMPLICIT יחד עם ALLOWED_ROLES_LIST, ולכן לא כוללים את רשימת התפקידים המותרים כשמשתמשים במודל הזה.

ככל האפשר, משתמשים בתפקיד ייעודי עם הרשאות מינימליות עבור שרת ה-MCP.

מעניקים את התפקיד הזה דרך תהליך ניהול הזהויות הרגיל בארגון. אם החברות בתפקידי Snowflake מנוהלת באמצעות Okta או SCIM, לא מוסיפים משתמשים ידנית מחוץ לתהליך הזה.

יוצרים או בוחרים מסד נתונים וסכימה שבבעלות הצוות שיפעיל את השרת.

לשאלות עסקיות הכפופות לממשל נתונים, אפשר להעמיד סוכן Cortex לרשות חברי סביבת העבודה ככלי. הוא מרכז במקום אחד תצוגות סמנטיות, שאילתות מאומתות, חיפוש ותזמור. סוכן Cortex הוא אופציונלי. אם יוצרים סוכן כזה, משתמשים במפרט שלהלן. אם מחליפים סוכן קיים, מוודאים שהסוכן החדש תואם למפרט שאושר בארגון.

סוגי כלי MCP אחרים הנתמכים ב-Snowflake כוללים CORTEX_ANALYST_MESSAGE, CORTEX_SEARCH_SERVICE_QUERY, GENERIC ו-SYSTEM_EXECUTE_SQL.

נותנים לכל כלי שם ותיאור ברורים. מסבירים אילו נתונים הוא מכסה, מה רמת הפירוט של התוצאות ומתי משתמשים בו. כך קל יותר לסוכן לבחור את הכלי המתאים.

הרשאת USAGE בשרת MCP מאפשרת לתפקיד להתחבר לשרת ולגלות אילו כלים זמינים בו. היא אינה מעניקה לתפקיד גישה למחסן הנתונים, לסוכן, לתצוגה סמנטית, לשירות חיפוש, להליך מאוחסן או לנתונים שבבסיסם. מעניקים לתפקיד גישה לכל משאב שהכלים של השרת זקוקים לו.

מעניקים גישה רק למשאבים הנוספים שכל כלי צריך. לדוגמה, מעניקים הרשאת SELECT לתצוגה סמנטית מאושרת, הרשאת USAGE לשירות Cortex Search או הרשאת USAGE לפונקציה או להליך מסוימים. לא מעניקים את התפקיד ל-PUBLIC ולא מוסיפים הרשאות גורפות לאובייקטים קיימים או עתידיים.

לפני שמגדירים OAuth, בודקים את שרת ה-MCP ואת ההרשאות שניתנו לו:

מגדירים את סכימת ה-MCP כך שתציין את התפקיד המדויק שחברי סביבת העבודה צריכים לבקש:

מציינים היקף תפקיד מפורש. לא משתמשים ב-session:role:all. Snowflake מתייחסת לערך הזה כתפקיד הראשי שמוגדר למשתמש כברירת מחדל, ולא כגישה לכל התפקידים. מדיניות שחלה על תפקידים בעלי הרשאות גבוהות עשויה לחסום אותו. תפקיד מפורש מבהיר איזו גישה מבוקשת ומקל על בדיקתה.

לפני שמריצים את ה-SQL הזה, מתאמים עם מנהל סביבת העבודה של Notion. מבקשים ממנו להזין את כתובת ה-URL של שרת Snowflake בטופס הגדרת ה-MCP של סביבת העבודה, ולהפעיל את ההגדרה הידנית של האימות ואת השימוש בלקוח OAuth משותף לסביבת העבודה. Notion יוצרת URI להפניה מחדש. מעתיקים אותו ושולחים למנהל Snowflake. אחרי ש-Snowflake יוצרת את מזהה הלקוח והסוד, מנהל סביבת העבודה יכול להשלים את הגדרת החיבור.

משתמשים ב-URI להפניה מחדש בדיוק כפי ש-Notion מספקת אותו. לא מוסיפים לוכסן בסוף או פרמטרים של שאילתה, ולא משנים את המארח.

הגדרת IS_AGENTIC = TRUE מסמנת הפעלות שנוצרו דרך האינטגרציה הזו כהפעלות של סוכן. הפונקציה IS_AGENT_ACTIVATED() של Snowflake מחזירה אז TRUE, וכך Snowflake יכולה להחיל ביקורת ומנגנוני פיקוח ובקרה ייעודיים לסוכנים. אם משתמשים במודל האופציונלי של תפקיד משני, מגדירים OAUTH_USE_SECONDARY_ROLES = IMPLICIT ומשמיטים את ALLOWED_ROLES_LIST.

תוקף אסימון הרענון, 7776000 שניות, שווה ל-90 יום. לפני שמשתמשים בערך הזה, מוודאים שהוא תואם למדיניות הארגון שלכם לחידוש הרשאות ולרוטציה של אסימונים. בשינויים שגרתיים נמנעים משימוש ב-CREATE OR REPLACE SECURITY INTEGRATION. החלפת האינטגרציה עלולה לשבש חיבורים קיימים.

כדי לבדוק את האינטגרציה בלי להציג את הסוד שלה, מריצים:

מוודאים שהאינטגרציה מופעלת, שה-URI להפניה מחדש תואם בדיוק, שהתפקיד מורשה ולא חסום, שאסימוני הרענון ו-PKCE מופעלים, ושנקודות הקצה להרשאה ולאסימון משתמשות שתיהן במארח החשבון הציבורי של Snowflake.

השלב הזה נדרש רק אם הארגון שלכם דורש מדיניות רשת. מבקשים מהאחראים על האבטחה או על הרשת בארגון לאשר את טווחי כתובות היציאה הנוכחיים של Notion.

אינטגרציית ה-OAuth חייבת לאפשר את שני הנתיבים של Notion:

1. נתיב ה-API שמטפל בקריאות חוזרות של OAuth ומחליף קודי אישור

2. נתיב זמן הריצה של סביבת העבודה שמאמת את החיבור, מריץ כלים ומרענן אסימונים

הנתיבים האלה עשויים להשתמש בכתובות יציאה שונות של Notion. אם מאפשרים רק את הכתובת ששימשה להחלפת האסימון הראשונית, הכניסה עשויה להצליח, אבל אימות החיבור או רענון האסימון עלולים להיכשל. משתמשים בטווחי כתובות היציאה הנוכחיים והמאושרים של Notion. לא מוסיפים לרשימת הכתובות המותרות בסביבת הייצור כתובת IP חד-פעמית מדפדפן או מיומן.

מצרפים את מדיניות הרשת הזו לאינטגרציית ה-OAuth, ולא למשתמשים בודדים. לא משנים את המדיניות שחלה על החשבון כולו בנוגע לכניסה דרך דפדפן, לגישת VPN או לגישת משתמשים לרשת. אם מדיניות רשת חוסמת בקשת אסימון, Snowflake עשויה להחזיר invalid_client. השגיאה הזו לא בהכרח אומרת שמזהה הלקוח או הסוד שגויים.

מריצים זאת בגיליון עבודה מאובטח של Snowflake. שם האינטגרציה תלוי באותיות גדולות וקטנות, ובדרך כלל נכתב באותיות גדולות:

משתפים את מזהה הלקוח ואת הסוד התואם לו עם מנהל סביבת העבודה שלכם ב-Notion, בערוץ מאובטח ומאושר. Snowflake מספקת שני סודות תקפים, כך שאפשר להחליף ביניהם בלי להשבית את החיבור. לעולם לא מדביקים אף אחד מהסודות בתיעוד, בצ'אט, בכרטיסי תמיכה או במערכת לניהול קוד המקור.

כש-Snowflake מוכנה, בעלים או מנהל של סביבת העבודה מוסיפים את השרת פעם אחת עבור סביבת העבודה. לאחר מכן, חברי סביבת העבודה יכולים למצוא אותו בלי לראות את סוד לקוח ה-OAuth, בין שהם מחברים את שרת ה-MCP של Snowflake לסוכן בהתאמה אישית ובין שהם מחברים אותו לסוכן Notion משלהם.

1. עוברים אל ההגדרות של סביבת העבודה.

2. בוחרים חיבורים ← שרתי MCP משותפים לסביבת העבודה.

3. בוחרים שרת MCP חדש לסביבת העבודה.

ממלאים את השדות האלה, ואז בוחרים הוספת שרת MCP:

אחרי השמירה, מוודאים שהשורה החדשה מופיעה תחת משותף עם סביבת העבודה הזו ושבשדה לקוח OAuth של סביבת העבודה מוצג מוגדר.

מה ההגדרה הזו מאפשרת:

• עוזרת לחברים למצוא את השרת המאושר.

• שומרת את סוד הלקוח של OAuth פעם אחת באחסון החיבורים המוצפן של Notion.

• מוודאת שחברי סביבת העבודה נכנסים באמצעות כתובת ה-URL של השרת, לקוח ה-OAuth וההיקפים שאישרתם.

• אינה יוצרת הפעלת Snowflake משותפת ואינה עוקפת את בקרות הגישה של Snowflake.

• אינה מחברת כל חבר באופן אוטומטי. כל אדם חייב להיכנס בנפרד.

אם מסירים את ההגדרה הזו, חברי סביבת עבודה חדשים לא יוכלו עוד למצוא את השרת. חיבורים קיימים עשויים עדיין להופיע, לכן מתאמים את השינוי עם ביטול ההרשאות ב-Snowflake והסרת החיבורים הקיימים.

ברגע שמנהלי המערכת שלכם מכינים את חיבור ה-MCP של Snowflake, יש שתי דרכים להשתמש בו. אם מגדירים אותו לצוות, מתחילים בשלב 11A. אם רק רוצים לשאול שאלות משלכם, עוברים לשלב 11B. אפשר להשתמש בשתי הדרכים; אלה חיבורים נפרדים.

סוכן בהתאמה אישית נותן לצוות שלכם מקום אחד לשאול בו שאלות על נתוני Snowflake. מחברים את Snowflake פעם אחת, מוסיפים הוראות לגבי המדדים והטבלאות שלכם ומשתפים את הסוכן עם הצוות. כל מי שמשתמשים בו צריכים להיכנס ל-Snowflake עם פרטי ההתחברות שלהם, כך שכל אחד מקבל תשובות רק על סמך הנתונים שהוא מורשה לראות.

חיבור Snowflake לסוכן בהתאמה אישית

1. פותחים את הסוכן בהתאמה אישית שלכם, או יוצרים סוכן חדש.

2. עוברים אל ההגדרות → כלים וגישה.

3. בוחרים ב-הוספת חיבור, ואז בשרת Snowflake שמסומן כ-מנוהל על ידי סביבת העבודה. לא בוחרים ב-שרת MCP בהתאמה אישית ולא מזינים את כתובת ה-URL של השרת ידנית.

4. נכנסים ל-Snowflake בדפדפן. ייתכן שיופיע תהליך הכניסה הרגיל של הארגון דרך Okta או SSO.

5. בודקים את התפקיד המבוקש ב-Snowflake ומאשרים אותו.

6. בוחרים באילו כלים הסוכן יכול להשתמש. משאירים את הכלים שמאפשרים כתיבה ואת CORTEX_AGENT_RUN במצב שמבקש אישור, עד שבודקים אותם.

7. בוחרים ב-התחברות ומוודאים שהחיבור מופיע כ-מחובר.

מתן הקשר לסוכן

החיבור נותן לסוכן גישה ל-Snowflake. ההוראות שלכם מסבירות לו איך החברה שלכם משתמשת בנתונים האלה. בהוראות הסוכן מפרטים באילו כלים להשתמש לכל סוג של שאלה, איך הצוות שלכם מגדיר מדדים מרכזיים ומאילו טבלאות או תצוגות סמנטיות להתחיל. כמה שאלות לדוגמה שהתשובות עליהן אומתו יכולות לעזור מאוד. נקודת התחלה מוכנה תמצאו במדריך ערכת הכלים של Data Scout.

שיתוף הסוכן

משתפים את הסוכן עם הצוות באותו אופן שמשתפים כל סוכן בהתאמה אישית. בפעם הראשונה שמישהו שואל אותו שאלה שמצריכה גישה ל-Snowflake, הוא מתבקש להיכנס באמצעות חשבון Snowflake משלו. לא נדרשים מזהה לקוח או סוד.

כדי לשאול שאלות משלכם בצ'אט אישי, מחברים את Snowflake לסוכן Notion שלכם. נכנסים באמצעות חשבון Snowflake שלכם, כך שהסוכן יכול לגשת רק למידע שמותר לכם לראות.

1. עוברים אל ההגדרות → Notion AI.

2. תחת שרתי MCP, בוחרים ב-הוספת שרת MCP.

3. בוחרים בשרת Snowflake שמסומן כ-מנוהל על ידי סביבת העבודה. לא בוחרים ב-שרת MCP בהתאמה אישית ולא מזינים את כתובת ה-URL של השרת ידנית.

4. בוחרים ב-התחברות.

5. נכנסים ל-Snowflake בדפדפן. ייתכן שיופיע תהליך הכניסה הרגיל של הארגון דרך Okta או SSO.

6. בודקים את התפקיד המבוקש ב-Snowflake ומאשרים אותו.

7. כשהדפדפן שואל אם לפתוח את Notion, בוחרים ב-פתיחת Notion.

8. מוודאים שסטטוס השרת הוא מחובר, ולא נדרש אימות.

לאחר ההתחברות, Snowflake מופיע בצ'אט תחת כל המקורות → שרתי MCP.

1. שואלים שאלה בטוחה שהתשובה עליה ידועה, ושמצריכה שימוש ב-Snowflake.

2. מוודאים שהסוכן משתמש ב-Snowflake ומחזיר תוצאה.

3. מוודאים שאין לכם גישה לנתונים מחוץ להרשאות התפקיד שהוקצה לכם.

אם הגדרתם סוכן בהתאמה אישית, מבקשים גם מאחד מחברי הצוות, שיש לו הרשאות מצומצמות יותר ב-Snowflake, לנסות אותו. הוא אמור לראות רק את הנתונים שיש לו גישה אליהם, ולא את הנתונים שלכם. זו הדרך המהירה ביותר לוודא שהסוכן משתמש בהרשאות של כל משתמש, ולא בהרשאות של מי שבנה אותו.

לבדיקה מעמיקה יותר, מבקשים ממנהל Snowflake לבדוק את המשתמש, התפקיד, מחסן המחשוב והיסטוריית השאילתות שלכם. התחברות מוצלחת מאמתת את הזהות שלכם, אבל לא מבטיחה שכל ההרשאות הוגדרו כראוי.

שואלים את הסוכן שאלה ממוקדת על הנתונים שלכם ב-Snowflake. לדוגמה:

• "מ-Snowflake, מה היו סך ההרשמות שלנו בחודש שעבר?"

• "מ-Snowflake, מה היו 10 החשבונות בעלי ההכנסה הגבוהה ביותר שלנו ברבעון זה?"

עם סוכן בהתאמה אישית, בדרך כלל אפשר לוותר על 'מ-Snowflake' כשההוראות שלו כבר מבהירות מתי להשתמש ב-Snowflake. עם סוכן Notion שלכם, אזכור Snowflake עוזר לסוכן לבחור את המקור הנכון.

בקשות גדולות עשויות להימשך זמן רב יותר או להיכשל עקב חריגה ממגבלת הזמן. אם זה קורה, שואלים שאלה ממוקדת יותר או מפצלים את הבקשה לשאלות קטנות יותר.

ברוב המקרים נשארים מחוברים בלי לעשות דבר. Snowflake משתמש באסימוני גישה קצרי תוקף, ו-Notion מרענן אותם ברקע. אסימון גישה שעומד לפוג לא ינתק אתכם כשלעצמו.

נדרשת כניסה מחדש אם:

• אסימון הרענון שלכם פג תוקף או שמנהל מערכת ביטל אותו

• מנהל מערכת מחליף את אינטגרציית ה-OAuth או את סוד הלקוח

• התפקיד שלכם ב-Snowflake הוסר

• מנהל מערכת מסיר את הגדרות סביבת העבודה או את החיבור שלכם

• מדיניות רשת חוסמת את רענון האסימון

עם סוכן בהתאמה אישית, ההתחברות של כל אדם נפרדת. אם אדם אחד מתבקש להתחבר שוב, הדבר לא משפיע על אף אחד אחר, ומי שבנה את הסוכן לא צריך לעשות דבר.

אם מחליפים את סוד הלקוח: משתמשים בתהליך החלפת שני הסודות של Snowflake במקום להחליף את האינטגרציה. משאירים את שני הסודות בתוקף למשך זמן שיספיק לעדכן ולבדוק את הגדרות סביבת העבודה לפני שמוציאים את הסוד הישן משימוש.

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

• חיבור ה-MCP של Snowflake לא מופיע ברשימה. ייתכן שמנהל סביבת העבודה עדיין לא הוסיף אותו, או שסביבת העבודה מגבילה שרתים בהתאמה אישית. מבקשים עזרה ממנהל סביבת העבודה.

• התבקשתם לספק מזהה לקוח או סוד. כנראה בחרתם באפשרות של שרת MCP בהתאמה אישית. חוזרים ובוחרים במקום זאת בשרת Snowflake שמסומן כ-מנוהל על ידי סביבת העבודה.

• התבקשתם להיכנס שוב. ייתכן שפג תוקף החיבור שלכם ל-Snowflake, או שמנהל מערכת עדכן את החיבור. נכנסים שוב ל-Snowflake.

• פתחתם סוכן בהתאמה אישית והוא ביקש מכם להיכנס ל-Snowflake. זה צפוי בפעם הראשונה. כל מי שמשתמש בסוכן בהתאמה אישית שמנוהל על ידי סביבת העבודה נדרש להיכנס באמצעות פרטי ההתחברות האישיים שלו ל-Snowflake.

• אחד מחברי הצוות מקבל תוצאות שונות מאותו סוכן בהתאמה אישית. זה צפוי. הסוכן משתמש בהרשאות של כל משתמש ב-Snowflake, ולכן משתמשים בעלי תפקידים שונים רואים נתונים שונים.

• הסוכן בהתאמה אישית עובד בצ'אט, אבל לא לפי לוח זמנים. הרצות מתוזמנות והרצות שמופעלות באמצעות טריגר פועלות ללא משתמש מחובר, ולכן הן עדיין לא יכולות להשתמש ב-Snowflake באמצעות כניסה אישית.

• התחברתם, אבל החיבור לא הושלם או שהכלים לא פועלים. ההתחברות מאמתת את הזהות שלכם, אבל הגישה עדיין תלויה בהרשאות שלכם ב-Snowflake. מבקשים ממנהל Snowflake לוודא שהתפקיד שלכם מאפשר גישה לשרת, למחסן המחשוב, לסוכן ולנתונים.

• הסוכן לא מצליח למצוא טבלה. הסוכן יכול לגשת רק לנתונים שחשבון Snowflake שלכם יכול לגשת אליהם. כדאי לבדוק את ההרשאות שלכם ב-Snowflake ולציין את שם הטבלה בשאלה.

• הזמן שהוקצב לבקשה פג. כדאי לשאול שאלה ממוקדת יותר או לפצל את הבקשה לשאלות קטנות יותר.

השגיאות האלה נובעות בדרך כלל מההגדרות ב-Snowflake, ולא מ-Notion. כדאי לשתף אותן עם מנהל המערכת שלכם ב-Snowflake.

• נראה שכתובת ה-URL של השרת כפולה, למשל https://https%3A... הכתובת הודבקה עם https:// נוסף בהתחלה. צריך לתקן אותה כך שכתובת ה-URL תתחיל ב-https:// אחד בלבד.

• מופיעה ההודעה "This server does not support OAuth authentication." אינטגרציית האבטחה לא הוגדרה ל-OAuth, או שכתובת ה-URL של השרת שגויה. כדאי לבקש ממנהל המערכת שלכם ב-Snowflake לבדוק את אינטגרציית האבטחה של OAuth ואת כתובת ה-URL של השרת.

• מופיעה השגיאה invalid_client במהלך הכניסה או הרענון. מזהה הלקוח או סוד הלקוח שגויים, או שסוד הלקוח השתנה. כדאי לבקש ממנהל המערכת את מזהה הלקוח ואת סוד הלקוח העדכניים.

• הכניסה מצליחה, אבל החיבור נכשל מיד אחר כך. ייתכן שלתפקיד שלכם אין גישה לשרת, או שתפקיד או כלל רשת חוסמים את ההפעלה. כדאי לבקש ממנהל המערכת לבדוק את ההרשאות והמדיניות שחלות עליכם.

• מופיעה ההודעה "The role ALL requested has been explicitly blocked." החיבור ביקש את כל התפקידים בבת אחת (session:role:all), ובקשה כזאת חסומה. במקום זאת, יש להשתמש בתפקיד אחד בשם המדויק שלו, למשל session:role:analyst, עם שם התפקיד האמיתי שלכם.

• מופיעה שגיאת הפניה (שגיאה 390307). כתובת ה-URL להפניה שנשמרה ב-Snowflake לא תואמת לכתובת שבה Notion משתמשת. כדאי לבקש ממנהל המערכת להגדיר באינטגרציית האבטחה את כתובת ה-URL להפניה לערך המדויק שבו Notion משתמשת.

• מופיעה שגיאה 390311 לגבי אתגר קוד לא תקין. יש אי-התאמה ב-PKCE. כדאי לבקש ממנהל המערכת לוודא שהערך של OAUTH_ENFORCE_PKCE מוגדר כראוי באינטגרציית האבטחה.

• החיבור הצליח, אבל לא מופיעים כלים. ייתכן שלתפקיד שלכם חסרה הרשאת USAGE בשרת MCP. כדאי לבקש ממנהל המערכת לוודא שההרשאה הוקצתה, ואז להריץ DESCRIBE MCP SERVER כדי לבדוק את ההגדרות.

• יש לכם גישה ליותר או לפחות נתונים ממה שציפיתם. תפקידים משניים משפיעים על הנתונים שזמינים בהפעלה שלכם. כדאי לבדוק עם מנהל המערכת אילו תפקידים פעילים בהפעלה.

• החיבור עבד קודם, ועכשיו הוא נכשל אצל כולם אחרי שינוי של סוד הלקוח. סוד הלקוח הוחלף, ולכן החיבור השמור כבר לא מעודכן. כדאי לבקש ממנהל המערכת את סוד הלקוח החדש, ואז להתחבר שוב.

• החיבור עבד קודם, ועכשיו הוא נכשל רק אצלכם. ייתכן שתפקיד, הרשאה או מדיניות השתנו, או שתוקף ההפעלה שלכם פג. כדאי להיכנס שוב ולבקש ממנהל המערכת לוודא שהגישה שלכם לא השתנתה.

• מזהה החשבון שלכם נדחה. יש להשתמש בפורמט organization-account עם מקף, למשל myorg-myaccount, ולא עם נקודות.

• חשבון PrivateLink לא מצליח להתחבר. חשבונות PrivateLink דורשים הגדרות רשת נוספות. כדאי לשאול את מנהל המערכת אם PrivateLink מאפשר את החיבור ל-Notion.

• Snowflake אינו זמין בהרצות מתוזמנות או בהרצות שמופעלות באמצעות טריגר. בהרצות האלה אין משתמש מחובר, ולכן הן עדיין לא יכולות להשתמש בכניסה אישית לכל משתמש. במקום זאת, אפשר להריץ את הבקשה בצ'אט.

• מופיעה השגיאה oauth_security_error אחרי כניסה דרך הדפדפן. ייתכן שמדיניות רשת ברמת החשבון חוסמת את הבקשה. מנהל המערכת יכול לבדוק זאת באמצעות הרצת הפקודה הבאה:

• נראה שהכניסה מצליחה, אבל מתקבלת שגיאה שקשורה לתפקיד גם כשהיקף ההרשאות נכון. ייתכן שתפקיד ברירת המחדל שלכם חסום, למשל ACCOUNTADMIN או תפקיד ברשימת BLOCKED_ROLES_LIST. מנהל המערכת יכול לבדוק ולתקן זאת:

הפקודות האלה לקריאה בלבד עוזרות למנהל המערכת לוודא שהכול מוגדר כראוי בלי לשנות דבר. יש להריץ אותן ב-Snowflake.

המדריכים האלה של Snowflake יעזרו להשלים את ההגדרה:

• שרת MCP מנוהל על ידי Snowflake

• יצירת אינטגרציית אבטחה מסוג Snowflake OAuth

• Snowflake OAuth עבור לקוחות מותאמים אישית

• סקירה כללית של Snowflake OAuth

• מזהי חשבון Snowflake

• סוכנים בהתאמה אישית

• חיבורי MCP עבור סוכנים בהתאמה אישית

• חיבור שרתי MCP לסוכן Notion שלכם

• שיטות עבודה מומלצות לאבטחה עבור חיבורי סוכנים