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

הסוכנים בהתאמה אישית ו-סוכן Notion שלכם יכולים להתחבר ל-Snowflake דרך שרת MCP (Model Context Protocol) ש-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.

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

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

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

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

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

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

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

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

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

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

לפני הרצת ה-SQL הזה, מתאמים עם מנהל סביבת העבודה של Notion. מבקשים ממנו להזין את כתובת ה-URL של שרת Snowflake בטופס הגדרת ה-MCP של סביבת העבודה ולהפעיל את Manually configure authentication ואת Use a workspace-shared OAuth client. 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 של השרת, הלקוח וההיקפים שאישרת.

• אינה יוצרת הפעלת 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" אחרי שההוראות שלו מבהירות מתי להשתמש בו. עם סוכן Notion שלכם, ציון השם Snowflake עוזר לסוכן לבחור את המקור המתאים.

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

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

תצטרכו להיכנס שוב אם:

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

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

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

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

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

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

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

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

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

• התבקשתם לספק מזהה לקוח או סוד לקוח. כנראה בחרתם באפשרות של שרת 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 שלכם

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