הגדרת 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 חייבת להיות בתוכנית לעסקים (Business) או בתוכנית 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 של סביבת העבודה ולהפעיל את 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 שמסומן Workspace Managed. לא בוחרים באפשרות Custom MCP server ולא מזינים את כתובת ה-URL של השרת ידנית.

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

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

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

7. בוחרים באפשרות Connect ומוודאים שהחיבור מופיע במצב Connected.

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

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

שיתוף הסוכן

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

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

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

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

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

4. בוחרים באפשרות Connect.

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

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

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

8. מוודאים שסטטוס השרת הוא Connected ולא Needs authentication.

אחרי שמתחברים, 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 שמסומן Workspace Managed.

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

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

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

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

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

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

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

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

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

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

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

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

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

• מופיעה שגיאת הפניה מחדש (שגיאה 390307). כתובת ההפניה מחדש ששמורה ב-Snowflake אינה תואמת לכתובת שבה Notion משתמשת. כדאי לבקש ממנהל המערכת שלכם להגדיר באינטגרציית האבטחה את כתובת ההפניה מחדש המדויקת של 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 שלכם

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