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

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

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

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

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

• חברי סביבת העבודה יכולים לאחר מכן לחבר סוכנים בהתאמה אישית ל-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 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. נכנסים להגדרות של סביבת העבודה דרך Settings.

2. בוחרים Connections ← Workspace shared MCPs.

3. בוחרים New workspace MCP.

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

לאחר השמירה, מוודאים שהשורה החדשה מופיעה תחת Shared with this workspace ושהשדה Workspace OAuth client מציג Configured.

מה הגדרה זו עושה:

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

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

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