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 data i ditt virtuella datalager i Snowflake och få svar direkt i Notion.

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

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

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

• Medlemmar i arbetsytan kan sedan ansluta till Snowflake MCP från skräddarsydda agenter med sina egna Snowflake-inloggningsuppgifter, eller ansluta Snowflake direkt till sin Notion-agent. Steg 1–10 i den här artikeln är desamma för båda alternativen. Alternativen skiljer sig åt från steg 11, beroende på vilken agent du vill ansluta.

• Vilka verktyg du har tillgång till kan variera beroende på vilken molnregion du använder i Snowflake.

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

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

• Använd Notion på webben eller i skrivbordsappen. 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 ordna åtkomsten. Det här är det mest omfattande steget, men du behöver bara göra det en gång. Samarbeta med administratören för din Notion-arbetsyta: Notion tillhandahåller en omdirigerings-URI, och Snowflake tillhandahåller ett OAuth-klient-ID och en klienthemlighet.

Du kommer att ställa in en roll och ett virtuellt datalager, 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.

Se till att kontots värdnamn innehåller bindestreck, inte understreck. Kontrollera att varje objektnamn i serverns webbadress stämmer överens med motsvarande objektnamn i Snowflake.

Använd en dedikerad roll med lägsta möjliga behörighet och ett godkänt virtuellt datalager när så är möjligt.

Begränsad roll utan sekundära roller, vilket vi rekommenderar. Den här modellen ä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 sekundära standardroller, om du vill använda dem. Använd bara den här modellen när servern behöver behörigheter som ärvs från varje användares Snowflake-inställning DEFAULT_SECONDARY_ROLES. Ställ in OAUTH_USE_SECONDARY_ROLES = IMPLICIT, utelämna ALLOWED_ROLES_LIST och ange ett uttryckligt omfång för den primära rollen. Snowflake tillåter inte sekundära roller med IMPLICIT tillsammans med ALLOWED_ROLES_LIST, så utelämna listan över tillåtna roller när du använder den här modellen.

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

Tilldela rollen genom er vanliga process för identitetshantering. Om Okta eller SCIM styr vilka som har Snowflake-roller ska du inte lägga till användare manuellt vid sidan av 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 göra en Cortex Agent tillgänglig som verktyg för medlemmarna. Den samlar semantiska vyer, verifierade frågor, sökning och orkestrering på ett ställe. En Cortex Agent är valfri. Om du skapar en sådan använder du specifikationen nedan. Om du ersätter en befintlig agent ser du till att ersättaren följer den godkända specifikationen.

Andra stödda Snowflake MCP-verktygstyper 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 information verktyget omfattar, hur detaljerade resultaten är och när det ska användas. Då blir det lättare för agenten att välja rätt verktyg.

Behörigheten USAGE på en MCP-server gör att en roll kan ansluta till servern och hitta dess verktyg. Den ger inte rollen åtkomst till det virtuella datalagret, agenten, den semantiska vyn, Cortex Search-tjänsten, den lagrade proceduren eller underliggande data. Ge rollen åtkomst till varje resurs som serverns verktyg behöver.

Bevilja bara åtkomst till de ytterligare resurser som varje verktyg behöver. Bevilja till exempel SELECT på en godkänd semantisk vy, USAGE på en Cortex Search-tjänst eller USAGE på en specifik funktion eller procedur. Tilldela inte rollen till PUBLIC och lägg inte till omfattande behörigheter för befintliga eller framtida objekt.

Innan du konfigurerar OAuth kontrollerar du MCP-servern och dess behörighetstilldelningar:

Konfigurera MCP-schemat så att det anger exakt vilken roll medlemmarna ska begära:

Ange ett specifikt rollomfång. Använd inte session:role:all. Snowflake tolkar det värdet som användarens förvalda primära roll, inte som åtkomst till alla roller. Policyer för privilegierade roller kan dessutom blockera det. Med en specifik roll blir det tydligt vilken åtkomst som begärs och lättare att kontrollera den.

Stäm av med administratören för din Notion-arbetsyta innan du kör den här SQL-koden. Be administratören ange Snowflake-serverns webbadress i arbetsytans MCP-formulär och aktivera Konfigurera autentisering manuellt och Använd en OAuth-klient som delas inom arbetsytan. Notion skapar en omdirigerings-URI. Kopiera den och skicka den till Snowflake-administratören. När Snowflake har skapat klient-ID och klienthemlighet kan arbetsytans administratör slutföra anslutningen.

Använd omdirigerings-URI:n exakt som du får den från Notion. Lägg inte till ett avslutande snedstreck eller frågeparametrar och ändra inte värdnamnet.

Inställningen IS_AGENTIC = TRUE markerar sessioner som skapats genom denna integrering som agentsessioner. Snowflakes funktion IS_AGENT_ACTIVATED() 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äller du in OAUTH_USE_SECONDARY_ROLES = IMPLICIT och utelämnar ALLOWED_ROLES_LIST.

Giltighetstiden för uppdateringstoken är 7776000 sekunder, alltså 90 dagar. Kontrollera innan du använder värdet att det följer organisationens policyer för ny auktorisering och tokenrotation. Undvik CREATE OR REPLACE SECURITY INTEGRATION vid rutinändringar. Om du ersätter integreringen kan befintliga anslutningar avbrytas.

Kör följande för att kontrollera integreringen utan att visa hemligheten:

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

Det här steget behövs bara om din organisation kräver en nätverkspolicy. Be den som ansvarar för säkerhet eller nätverk att godkänna Notions aktuella IP-adressintervall för utgående trafik.

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 tokenutbytet kan inloggningen lyckas, men validering eller uppdatering av token kan misslyckas. Använd Notions aktuella, godkända intervall för utgående trafik. Lägg inte till en tillfällig IP-adress från en webbläsare eller logg i en lista över tillåtna adresser i produktionsmiljön.

Koppla nätverkspolicyn till OAuth-integreringen, inte till enskilda användare. Ändra inte policyerna för hela kontot som gäller webbläsarinloggning, VPN-åtkomst eller användares nätverksåtkomst. Om en nätverkspolicy blockerar en tokenbegäran kan Snowflake returnera invalid_client. Det betyder inte nödvändigtvis att klient-ID:t eller hemligheten är felaktig.

Kör detta i ett säkert Snowflake-arbetsblad. Integreringsnamnet är skiftlägeskänsligt och skrivs vanligtvis med versaler:

Dela klient-ID:t och dess matchande hemlighet med administratören för din Notion-arbetsyta 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 av arbetsytan 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 Inställningar för arbetsytan.

2. Välj Anslutningar → Delade MCP:er för arbetsytan.

3. Välj Ny MCP för arbetsytan.

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

När du har sparat bekräftar du att den nya raden visas under Delad med den här arbetsytan och att Arbetsytans OAuth-klient visar Konfigurerad.

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.

• Ser till att medlemmar loggar in med serverns webbadress, klienten och de OAuth-behörigheter du har 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 administratörerna har konfigurerat Snowflake MCP-anslutningen kan du använda den på två sätt. Ska du konfigurera den för ett team börjar du med 11A. Vill du bara ställa egna frågor hoppar du till 11B. Du kan också göra båda. Det är två separata anslutningar.

En skräddarsydd agent ger ditt team en samlad 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 webbadress 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 får använda. Låt verktyg med skrivbehörighet och CORTEX_AGENT_RUN vara inställda på att begära godkännande tills du har testat dem.

7. Välj Anslut och bekräfta att anslutningen visas som 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 exempelfrå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 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 klienthemlighet.

Om du vill ställa dina egna frågor i din egen chatt ansluter du 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äljer du Lägg till MCP-server.

3. Välj Snowflake-servern märkt Workspace Managed. Välj inte Custom MCP server och ange inte serverns webbadress 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äljer du Ö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 kräver data från 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 har konfigurerat en skräddarsydd agent, be också en teammedlem med en mer begränsad Snowflake-roll att testa den. Teammedlemmen ska bara se de data hen själv har åtkomst till, inte dina. Det är det snabbaste sättet att kontrollera att agenten använder varje persons åtkomst och inte åtkomsten för den som skapade den.

För en djupare kontroll, be din Snowflake-administratör att bekräfta ditt användarkonto, din roll, ditt virtuella datalager och din 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:

• ”Hur många registreringar hade vi totalt förra månaden enligt Snowflake?”

• ”Vilka var våra tio konton med högst intäkter det här kvartalet enligt Snowflake?”

Med en skräddarsydd agent kan du oftast utelämna ”från Snowflake” när instruktionerna tydligt anger när Snowflake ska användas. Om du använder din Notion-agent hjälper det att nämna Snowflake så att agenten väljer rätt källa.

Stora förfrågningar kan ta längre tid eller överskrida tidsgränsen. 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. Att en åtkomsttoken håller på att gå ut gör inte i sig att du kopplas från.

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;

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

• Du ombeds ange ett klient-ID eller en klienthemlighet. Du valde förmodligen alternativet för en anpassad MCP-server. Gå tillbaka och välj Snowflake-servern märkt Workspace Managed i stä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 blev ombedd att logga in på Snowflake. Det är väntat första gången. Alla som använder en hanterad skräddarsydd agent måste logga in med sina egna inloggningsuppgifter för Snowflake.

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

• Den skräddarsydda agenten fungerar i chatten men inte vid schemalagda körningar. Vid schemalagda och utlösta körningar finns ingen inloggad person. Därför kan de ännu inte använda Snowflake med individuell inloggning.

• Du loggade in, men anslutningen fungerar inte eller så fungerar inte verktygen. Inloggningen bekräftar din identitet, men din åtkomst beror fortfarande på dina Snowflake-behörigheter. Be din Snowflake-administratör kontrollera att din roll har åtkomst till servern, det virtuella datalagret, agenten och data.

• 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 tar för lång tid. Ställ en mer specifik fråga eller dela upp din förfrågan i mindre frågor.

Felen beror oftast på inställningarna i Snowflake, inte på Notion. Visa dem för din Snowflake-administratör.

• Serverns webbadress ser dubblerad ut, som https://https%3A... Adressen klistrades in med ett extra https:// framför. Ta bort det extra prefixet så att webbadressen börjar med ett enda 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 förnyar sessionen. Klient-ID:t eller klienthemligheten är felaktig, eller så har klienthemligheten ändrats. Be din administratör om aktuellt klient-ID och aktuell klienthemlighet.

• Inloggningen fungerar, men misslyckas direkt efteråt. Din roll kanske inte har åtkomst till servern, eller så blockerar en roll eller nätverksregel sessionen. Be din administratör kontrollera dina behörigheter och policyer.

• Du ser ”The role ALL requested has been explicitly blocked.” Anslutningen begärde alla roller samtidigt (session:role:all), men det är blockerat. Använd i stället en enda specifik roll, till exempel session:role:analyst, med ditt faktiska rollnamn.

• Du ser omdirigeringsfel 390307. Webbadressen för omdirigering som sparats i Snowflake matchar inte den som Notion använder. Be din administratör att ställa in webbadressen för omdirigering i säkerhetsintegreringen till exakt det värde som Notion använder.

• Du ser fel 390311 om en ogiltig kodutmaning. Det beror på att PKCE-värdena inte stämmer överens. 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 med din administratör vilka roller som är aktiva i sessionen.

• Det fungerade tidigare, men nu fungerar det inte för någon efter att klienthemligheten ändrades. Klienthemligheten har bytts ut, så den sparade anslutningen är inaktuell. Be din administratör om den nya hemligheten och anslut sedan igen.

• Det fungerade tidigare, men nu fungerar det inte längre 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 kontrollera att din åtkomst inte har ändrats.

• Din kontoidentifierare avvisas. Använd formatet organization-account med bindestreck, till exempel myorg-myaccount, utan 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 körningar eller körningar som startas av utlösare. Ingen är inloggad under de körningarna, så de kan ännu inte använda individuell inloggning. Kör din förfrågan i en chatt i stä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 det:

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 säkerhetsintegrering för Snowflake OAuth

• 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

• Bästa praxis för säkerhet vid agentanslutningar