Konfigurera Snowflake MCP för Notion

Dina skräddarsydda agenter och Notion-agent kan ansluta till Snowflake via en MCP-server (Model Context Protocol) som Snowflake kör. När den är konfigurerad kan du fråga din agent om dina Snowflake-datalager och få svar direkt i Notion.

Konfigurationen sker i etapper, och olika ägare ansvarar för varje del:

• En Snowflake-administratör ställer in rollen, lagret och den Snowflake-hanterade MCP-servern.

• En Notion-arbetsytaägare eller administratör konfigurerar Snowflake MCP-anslutningen för arbetsytan.

• Arbetsytamedlemmar kan sedan ansluta till Snowflake MCP från skräddarsydda agenter med sina egna Snowflake-uppgifter, eller ansluta Snowflake direkt till sin Notion-agent. Steg 1–10 i den här artikeln är desamma för båda vägarna. Vägarna delas vid steg 11, beroende på vilken agent du vill ansluta.

• De tillgängliga verktygen kan variera beroende på din Snowflake-molnregion.

• Snowflakes hanterade MCP-server är inte tillgänglig i Kina eller i myndighetsregioner.

• Din Notion-arbetsyta måste vara på ett Business- eller Enterprise-abonnemang.

• Använd Notion på webben eller skrivbordet. Den här funktionen är inte tillgänglig på mobilen.

• Ditt företag behöver ett Snowflake-konto.

• För att bygga en skräddarsydd agent behöver du behörighet att skapa agenter i din arbetsyta.

Innan ditt team kan ansluta Snowflake till Notion måste en Snowflake-administratör ställa in åtkomst. Detta är det mest omfattande steget, och du behöver bara göra det en gång. Samarbeta med din Notion-arbetsytaadministratör: Notion tillhandahåller en omdirigerings-URI, och Snowflake tillhandahåller ett OAuth-klient-ID och en hemlighet.

Du kommer att ställa in en roll och ett lager, skapa den Snowflake-hanterade MCP-servern, ge den åtkomst till de resurser den behöver, konfigurera OAuth-omfånget och säkerhetsintegreringen, samt lägga till en nätverkspolicy om din organisation kräver en.

Fyll i detta arbetsblad tillsammans med administratören för din Notion-arbetsyta innan du börjar. Medlemmar kan hoppa över detta och logga in med sina egna Snowflake-konton när konfigurationen är klar.

Kontots värdnamn använder bindestreck, inte understreck. Se till att varje objektnamn i server-URL:en matchar motsvarande objektnamn i Snowflake.

Använd en dedikerad roll med lägsta möjliga behörighet och ett godkänt lager när det är möjligt.

Begränsad roll utan sekundära roller (rekommenderas). Denna modell är enklare att förstå och granska. Ställ in OAUTH_USE_SECONDARY_ROLES = NONE, ange ALLOWED_ROLES_LIST och använd Notion-omfånget session:role:<mcp_access_role>.

En användares standard sekundära roller (valfritt). Använd denna modell endast när servern behöver behörigheter som ärvts från varje användares Snowflake DEFAULT_SECONDARY_ROLES. Ställ in OAUTH_USE_SECONDARY_ROLES = IMPLICIT, utelämna ALLOWED_ROLES_LIST och använd en explicit primär rollomfattning. Snowflake tillåter inte IMPLICIT sekundära roller med ALLOWED_ROLES_LIST, så utelämna allowlist när du använder denna modell.

Använd en dedikerad roll med lägsta möjliga behörighet för MCP-servern när det är möjligt.

Bevilja denna roll genom din normala process för identitetshantering. Om Okta eller SCIM hanterar Snowflake-rollmedlemskap, lägg inte till användare manuellt utanför den processen.

Skapa eller välj en databas och ett schema som ägs av det team som ska köra servern.

För styrda affärsfrågor kan du exponera en Cortex Agent som det verktyg medlemmarna använder. Det håller semantiska vyer, verifierade frågor, Snabbsökning och orkestrering på ett ställe. En Cortex Agent är valfri. Om du skapar en, använd specifikationen nedan. Om du ersätter en befintlig agent, se till att ersättningen matchar din godkända specifikation.

Andra verktygstyper som stöds av Snowflake MCP inkluderar CORTEX_ANALYST_MESSAGE, CORTEX_SEARCH_SERVICE_QUERY, GENERIC och SYSTEM_EXECUTE_SQL.

Ge varje verktyg ett tydligt namn och en beskrivning. Förklara vilken data det täcker, hur detaljerade resultaten är och när det ska användas. Detta hjälper agenten att välja rätt verktyg.

USAGE-privilegiet på en MCP-server låter en roll ansluta till servern och upptäcka dess verktyg. Det ger inte rollen åtkomst till lagret, agenten, den semantiska vyn, Snabbsökningstjänsten, lagrade procedurer eller underliggande data. Bevilja rollen åtkomst till varje resurs som serverns verktyg behöver.

Bevilja endast åtkomst till de ytterligare resurser som varje verktyg behöver. Bevilja till exempel SELECT på en godkänd semantisk vy, USAGE på en Cortex Snabbsökning, eller USAGE på en specifik funktion eller procedur. Bevilja inte rollen till PUBLIC och lägg inte till breda privilegier för nuvarande eller framtida objekt.

Innan du konfigurerar OAuth, kontrollera MCP-server och dess beviljanden:

Konfigurera MCP-schemat för att annonsera den exakta roll som medlemmarna bör begära:

Använd ett explicit rollomfång. Använd inte session:role:all. Snowflake behandlar det värdet som användarens primära roll, inte som åtkomst till varje roll, och policyer för privilegierade roller kan blockera det. En explicit roll gör den begärda åtkomsten tydlig och lättare att kontrollera.

Innan du kör denna SQL, samordna med administratören för din Notion-arbetsyta. Be dem ange Snowflake-serverns webbadress i formuläret för MCP-konfiguration i arbetsytan och aktivera Manually configure authentication och Use a workspace-shared OAuth client. Notion genererar en omdirigerings-URI. Kopiera den och skicka den till Snowflake-administratören. När Snowflake har skapat klient-ID och hemlighet kan arbetsytans administratör slutföra konfigurationen av anslutningen.

Använd omdirigerings-URI:n exakt som Notion tillhandahåller den. Lägg inte till ett avslutande snedstreck eller frågeparametrar, och ändra inte värd.

Att ställa in IS_AGENTIC = TRUE markerar sessioner som skapats genom denna integrering som agentsessioner. Snowflakes IS_AGENT_ACTIVATED()-funktion returnerar då TRUE, vilket gör att Snowflake kan tillämpa agentspecifik granskning och styrning. Om du använder den valfria modellen för sekundära roller, ställ in OAUTH_USE_SECONDARY_ROLES = IMPLICIT och utelämna ALLOWED_ROLES_LIST.

Giltighetsvärdet för uppdateringstoken på 7776000 sekunder motsvarar 90 dagar. Innan du använder det, bekräfta att det matchar organisationens policyer för omauktorisering och token-rotation. För rutinändringar, undvik CREATE OR REPLACE SECURITY INTEGRATION. Att ersätta integreringen kan avbryta befintliga anslutningar.

För att kontrollera integreringen utan att visa dess hemlighet, kör:

Bekräfta att integreringen är aktiverad, att omdirigerings-URI:n matchar exakt, att rollen är tillåten och inte blockeras, att uppdateringstokens och PKCE är aktiverade, och att både auktoriserings- och token-slutpunkterna använder Snowflakes offentliga kontovärd.

Detta steg behövs endast om din organisation kräver en nätverkspolicy. Be din säkerhets- eller nätverksägare att godkänna Notions nuvarande utgående intervall.

OAuth-integreringen måste tillåta båda Notion-sökvägarna:

1. API-sökvägen som hanterar OAuth-återanrop och utbyter auktoriseringskoder

2. arbetsytans körningssökväg som validerar anslutningen, kör verktyg och uppdaterar tokens

Dessa sökvägar kan använda olika utgående Notion-adresser. Om du endast tillåter den adress som användes under det initiala token-utbytet kan inloggningen lyckas, men validering eller token-uppdatering kan misslyckas. Använd Notions nuvarande, godkända utgående intervall. Lägg inte till en engångs-IP-adress från en webbläsare eller logg till en allowlist för produktion.

Koppla denna nätverkspolicy till OAuth-integreringen, inte till enskilda användare. Ändra inte dina kontoomfattande policys för inloggning via webbläsare, VPN-åtkomst eller användarnätverksåtkomst. Om en nätverkspolicy blockerar en tokenbegäran kan Snowflake returnera invalid_client. Detta fel innebär inte nödvändigtvis att klient-ID:t eller hemligheten är felaktig.

Kör detta i ett säkert Snowflake-kalkylblad. Integreringsnamnet är skiftlägeskänsligt och är vanligtvis versalt:

Dela klient-ID:t och dess matchande hemlighet med din Notion-arbetsytas administratör via en godkänd säker kanal. Snowflake tillhandahåller två giltiga hemligheter, så att du kan rotera dem utan driftstopp. Klistra aldrig in någon av hemligheterna i dokumentation, chatt, ärenden eller källkodshantering.

När Snowflake är redo lägger en ägare eller administratör till servern en gång för arbetsytan. Medlemmar kan sedan hitta den utan att se OAuth-klienthemligheten, oavsett om de ansluter Snowflake MCP till en skräddarsydd agent eller till sin egen Notion-agent.

1. Gå till Settings för arbetsytan.

2. Välj Anslutningar → Workspace shared MCPs.

3. Välj Ny MCP i arbetsyta.

Fyll i dessa fält och välj sedan Lägg till MCP-server:

När du har sparat, bekräfta att den nya raden visas under Delade med denna arbetsyta och att Workspace OAuth client visar Configured.

Vad den här konfigurationen gör:

• Hjälper medlemmar att hitta den godkända servern.

• Lagrar OAuth-klienthemligheten en gång i Notions krypterade anslutningslagring.

• Säkerställer att medlemmar loggar in med server-URL:en, klienten och de OAuth-omfång du godkänt.

• Skapar inte en delad Snowflake-session och kringgår inte Snowflakes åtkomstkontroller.

• Ansluter inte varje medlem automatiskt. Varje person måste logga in separat.

Om du tar bort den här konfigurationen kan nya medlemmar inte längre hitta servern. Befintliga anslutningar kan fortfarande visas, så samordna denna ändring med att återkalla Snowflake-behörigheter och ta bort befintliga anslutningar.

När dina administratörer har Snowflake MCP-anslutningen redo finns det två sätt att använda den. Om du konfigurerar detta för ett team, börja med 11A. Om du bara vill ställa dina egna frågor, hoppa till 11B. Du kan göra båda; de är separata anslutningar.

En skräddarsydd agent ger ditt team en gemensam plats för att ställa frågor om Snowflake-data. Du ansluter Snowflake en gång, lägger till instruktioner om dina mätvärden och tabeller, och delar agenten med ditt team. Alla som använder den kommer att behöva logga in på Snowflake med sina egna inloggningsuppgifter, så att varje person endast får svar baserat på den data de har behörighet att se.

Anslut Snowflake till en skräddarsydd agent

1. Öppna din skräddarsydda agent, eller skapa en ny.

2. Gå till Inställningar → Verktyg och åtkomst.

3. Välj Lägg till anslutning, välj sedan Snowflake-servern märkt Workspace Managed. Välj inte Custom MCP-server och ange inte serverns URL manuellt.

4. Logga in på Snowflake i din webbläsare. Din organisations vanliga Okta- eller SSO-inloggning kan visas.

5. Granska och godkänn den begärda Snowflake-rollen.

6. Välj vilka verktyg agenten kan använda. Lämna skrivkapabla verktyg och CORTEX_AGENT_RUN inställda på att be om godkännande tills du har testat dem.

7. Välj Anslut och bekräfta att anslutningens status är Ansluten.

Ge agenten kontext

Anslutningen ger agenten åtkomst till Snowflake. Dina instruktioner talar om för den hur ditt företag använder den datan. Beskriv i agentens instruktioner vilka verktyg som ska användas för vilka typer av frågor, hur ditt team definierar nyckeltal och vilka tabeller eller semantiska vyer som ska användas som utgångspunkt. Några verifierade exempel på frågor räcker långt. För en färdig startpunkt, se guiden för Data Scout-verktygslådan.

Dela agenten

Dela agenten med ditt team på samma sätt som du delar vilken skräddarsydd agent som helst. Första gången någon ställer en fråga till den som kräver Snowflake, kommer de att uppmanas att logga in med sitt eget Snowflake-konto. De kommer inte att bli tillfrågade om ett klient-ID eller en hemlighet.

Om du vill ställa dina egna frågor i din egen chatt, anslut Snowflake till din Notion-agent. Du loggar in med ditt eget Snowflake-konto, så att din agent endast når det du har behörighet att se.

1. Gå till Inställningar → Notion AI.

2. Under MCP-servrar, välj Lägg till MCP-server.

3. Välj Snowflake-servern märkt Workspace Managed. Välj inte Custom MCP-server och ange inte serverns URL manuellt.

4. Välj Anslut.

5. Logga in på Snowflake i din webbläsare. Din organisations vanliga Okta- eller SSO-inloggning kan visas.

6. Granska och godkänn den begärda Snowflake-rollen.

7. När din webbläsare frågar om du vill öppna Notion, välj Öppna Notion.

8. Bekräfta att serverstatusen är Ansluten, inte Kräver autentisering.

När du har anslutit visas Snowflake under Alla källor → MCP-servrar i chatten.

1. Ställ en ofarlig fråga med ett känt svar som bör använda Snowflake.

2. Bekräfta att agenten använder Snowflake och returnerar ett resultat.

3. Bekräfta att du inte kan komma åt data utanför den roll du har tilldelats.

Om du konfigurerar en skräddarsydd agent, be även en teammedlem med en mer begränsad Snowflake-roll att testa den. De bör endast se sin egen data, inte din. Det är det snabbaste sättet att bekräfta att agenten använder varje persons åtkomst istället för skaparens.

För en djupare kontroll, be din Snowflake-administratör att bekräfta din användare, roll, lager och frågehistorik. En lyckad inloggning bekräftar din identitet, men den bekräftar inte att varje behörighet är korrekt.

Ställ en specifik fråga till agenten om din Snowflake-data. Till exempel:

• "Från Snowflake, vad var våra totala registreringar förra månaden?"

• "Från Snowflake, vilka var våra 10 konton med högst intäkter detta kvartal?"

Med en skräddarsydd agent kan du oftast hoppa över "från Snowflake" när dess instruktioner gör det tydligt när den ska användas. Med din Notion-agent hjälper det att nämna Snowflake för att agenten ska välja rätt källa.

Stora förfrågningar kan ta längre tid eller få timeout. Om det händer, ställ en mer avgränsad fråga eller dela upp förfrågan i mindre frågor.

För det mesta förblir du ansluten utan att behöva göra något. Snowflake använder kortlivade åtkomsttoken, och Notion uppdaterar dem i bakgrunden. En utgången åtkomsttoken i sig frånkopplar dig inte.

Du behöver logga in igen om:

• Din uppdateringstoken går ut eller en administratör återkallar den

• En administratör ersätter OAuth-integreringen eller klienthemligheten

• Din Snowflake-roll tas bort

• En administratör tar bort arbetsytans konfiguration eller din anslutning

• En nätverkspolicy blockerar token-uppdateringen

Med en skräddarsydd agent är varje persons inloggning separat. Om en person ombeds logga in igen påverkar det inte någon annan, och personen som byggde agenten behöver inte göra någonting.

Om du roterar klienthemligheten: Använd Snowflakes rotation med två hemligheter istället för att ersätta integreringen. Behåll båda hemligheterna giltiga tillräckligt länge för att uppdatera och testa arbetsytans konfiguration innan du drar tillbaka den gamla.

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

• Snowflake MCP-anslutningen finns inte i listan. Din arbetsyteadministratör kanske inte har lagt till den än, eller så kan din arbetsyta begränsa anpassade servrar. Be din administratör om hjälp.

• Du ombeds ange ett klient-ID eller en hemlighet. Du valde förmodligen det anpassade MCP-alternativet. Gå tillbaka och välj Snowflake-servern märkt Workspace Managed istället.

• Du ombeds logga in igen. Din Snowflake-session kan ha gått ut, eller så kan en administratör ha uppdaterat anslutningen. Logga in på Snowflake igen.

• Du öppnade en skräddarsydd agent och den bad dig logga in på Snowflake. Det är förväntat första gången. Varje person som använder en hanterad skräddarsydd agent måste logga in med sina egna Snowflake-uppgifter.

• En teammedlem får olika resultat från samma skräddarsydda agent. Det är förväntat. Agenten använder varje persons Snowflake-åtkomst, så personer med olika roller ser olika data.

• Den skräddarsydda agenten fungerar i chatt men inte enligt ett schema. Schemalagda och utlösta körningar har ingen inloggad person, så de kan ännu inte använda Snowflake med inloggning per person.

• Du loggade in, men den ansluter inte eller verktygen misslyckas. Inloggningen bevisar vem du är, men din åtkomst beror fortfarande på dina Snowflake-behörigheter. Be din Snowflake-administratör bekräfta att din roll kan nå servern, lagret, agenten och datan.

• Agenten kan inte hitta en tabell. Agenten kan bara nå den data som ditt Snowflake-konto kan nå. Kontrollera dina Snowflake-behörigheter och inkludera tabellnamnet i din fråga.

• En förfrågan får timeout. Ställ en mer specifik fråga eller dela upp din förfrågan i mindre frågor.

Dessa fel beror vanligtvis på Snowflake-inställningar, inte Notion. Dela dem med din Snowflake-administratör.

• Serverns webbadress ser dubblerad ut, som https://https%3A... Adressen klistrades in med ett extra https:// framför. Fixa det så att webbadressen bara börjar med ett https://.

• Du ser "This server does not support OAuth authentication." Säkerhetsintegreringen är inte konfigurerad för OAuth, eller så är serverns webbadress felaktig. Be din Snowflake-administratör att kontrollera OAuth-säkerhetsintegreringen och serverns webbadress.

• Du ser invalid_client när du loggar in eller uppdaterar. Klient-ID:t eller hemligheten är felaktig, eller så har hemligheten ändrats. Be din administratör om det aktuella klient-ID:t och hemligheten.

• Inloggningen fungerar, men misslyckas omedelbart därefter. Din roll kanske inte når servern, eller så blockerar en roll eller nätverksregel sessionen. Be din administratör att kontrollera dina behörigheter och policyer.

• Du ser "The role ALL requested has been explicitly blocked." Anslutningen efterfrågade varje roll samtidigt (session:role:all), vilket är blockerat. Använd en specifik roll istället, som session:role:analyst, med ditt faktiska rollnamn.

• Du ser ett omdirigeringsfel (fel 390307). Omdirigeringswebbadressen som sparats i Snowflake matchar inte den som Notion använder. Be din administratör att ställa in omdirigeringswebbadressen i säkerhetsintegreringen till det exakta Notion-värdet.

• Du ser fel 390311 om en ogiltig kodutmaning. Detta är ett PKCE-fel. Be din administratör att bekräfta att OAUTH_ENFORCE_PKCE är korrekt inställt i säkerhetsintegreringen.

• Du är ansluten, men inga verktyg visas. Din roll kanske saknar USAGE på MCP-servern. Be din administratör att bekräfta behörigheten och kör sedan DESCRIBE MCP SERVER för att kontrollera konfigurationen.

• Du kan nå mer eller mindre data än du förväntade dig. Sekundära roller ändrar vad din session kan se. Kontrollera vilka roller som är aktiva i din session med din administratör.

• Det fungerade tidigare, men nu misslyckas alla efter en hemlig ändring. Den klienthemliga nyckeln roterades, så den sparade anslutningen är inaktuell. Be din administratör om den nya nyckeln och anslut sedan igen.

• Det fungerade tidigare, men nu misslyckas det bara för dig. En roll, behörighet eller policy kan ha ändrats, eller så har din session löpt ut. Logga in igen och be sedan din administratör att bekräfta att din åtkomst inte har ändrats.

• Ditt konto-ID avvisas. Använd formatet organization-account med ett bindestreck, som myorg-myaccount, inte punkter.

• Ett PrivateLink-konto kan inte ansluta. PrivateLink-konton kräver extra nätverkskonfiguration. Fråga din administratör om PrivateLink tillåter Notion-anslutningen.

• Snowflake är inte tillgängligt i schemalagda eller utlösta körningar. Dessa körningar har ingen inloggad person, så de kan ännu inte använda personlig inloggning. Kör din förfrågan i chatt istället.

• Du ser oauth_security_error efter att ha loggat in via webbläsaren. En nätverkspolicy på kontonivå kan blockera förfrågan. Din administratör kan bekräfta detta genom att köra:

• Inloggningen verkar fungera men du får ett rollfel, även med rätt omfattning. Din standardroll kan vara blockerad, till exempel ACCOUNTADMIN eller en roll i BLOCKED_ROLES_LIST. Din administratör kan kontrollera och åtgärda detta:

Dessa skrivskyddade kommandon hjälper din administratör att bekräfta konfigurationen utan att ändra något. Kör dem i Snowflake.

Använd dessa Snowflake-guider för att slutföra konfigurationen:

• Snowflake-hanterad MCP-server

• Skapa en Snowflake OAuth-säkerhetsintegrering

• Snowflake OAuth för anpassade klienter

• Översikt över Snowflake OAuth

• Snowflake-kontoidentifierare

• Skräddarsydda agenter

• MCP-anslutningar för skräddarsydda agenter

• Anslut MCP-servrar till din Notion-agent

• Säkerhetens bästa praxis för agentanslutningar