Wiring Snowflake CoWork to Salesforce, Slack, and Jira via MCP

Snowflake announced the general availability of its managed MCP server and previews of external and custom MCP connectors, enabling AI agents to take action across Salesforce, Slack, Jira, and other enterprise tools. The company also revealed its intent to acquire Natoma, an enterprise MCP platform for secure AI agent connectivity and governance. The Model Context Protocol standard allows agents to discover and invoke tools dynamically, bridging the gap between AI insights and real-world action.

Feature Status: The Snowflake-managed MCP server CREATE MCP SERVER is Generally Available GA , but it is not supported in government regions. External MCP connectors CREATE EXTERNAL MCP SERVER are in Preview Open and available to all accounts. SPCS-hosted MCP servers CREATE CUSTOM MCP SERVER are also in Preview Open . Summit 2026 confirmed MCP connectors forGmail, Google Drive, Salesforce, and Slack— teams can move from idea to action instantly across all of the systems they use. Critical announcement: Snowflake’sintent to acquire Natoma— an enterprise MCP platform providing secure connectivity, governance, identity-aware authorization, and auditability for AI agents operating across enterprise systems and tools. Reference:https://www.snowflake.com/en/blog/snowflake-cowork-personal-work-agent/ Imagine a scenario where an AI system flags a $2.3M enterprise account with a high churn risk — say 74%. The model doesn’t just give a score; it explains why. It points to a specific contract clause that’s causing friction and shows usage patterns that suggest the customer is starting to disengage. On paper, everything needed to act is already there. But the insight sits in a dashboard for two days before an account manager notices it. By the time they reach out, the customer has already begun evaluating competitors. Nothing is wrong with the AI. The detection worked exactly as intended. The problem is what happens after — the insight doesn’t move fast enough into the systems where action is taken, like Salesforce, Slack, or Jira. A simple analogy: it’s like your payment app detecting a suspicious transaction instantly, but only notifying you days later. The signal was correct — it just didn’t reach you in time to matter. That’s the gap MCP is designed to solve — not better predictions, but faster action where work actually happens. I assumed MCP was another outbound connector — CoWork calls Salesforce, done. That’s half the story. Model Context Protocol https://modelcontextprotocol.io/docs/getting-started/intro is an open standard for AI tool discovery and invocation. An MCP client asks the server “what tools do you have?” and gets back a typed manifest. The agent reasons about when and how to use each tool during its planning loop. No hard-coded endpoints. No bespoke connectors per tool. Think of it like a human analyst at a desk. Instead of memorizing every API endpoint for every system, they have a phone directory that says: “Salesforce can create opportunities and update contacts. Jira can create tickets and add comments. Slack can post messages.” The analyst agent decides when to pick up the phone based on the problem at hand. MCP is that directory — standardized, discoverable, typed. Snowflake implements both sides: Snowflake as MCP Server outbound exposure : Your Snowflake objects become MCP tools via CREATE MCP SERVER. MCP-compatible clients — Claude Desktop, Cursor, LangGraph, custom Python apps — connect, discover tools, and invoke them. The client authenticates as a Snowflake user; their default role governs what tools they can see and use. Snowflake as MCP Client inbound action : CoWork agents call out to external MCP servers via CREATE EXTERNAL MCP SERVER. The Summit blog is explicit: draft emails in Gmail, update Jira tickets, post to Slack and log activity in Salesforce, all from the same conversation. The first time I read “managed MCP server” I assumed it meant Snowflake hosts an MCP-compatible container for you. It’s simpler than that. One DDL statement wraps existing Snowflake objects as MCP-discoverable tools: -- Creates a managed MCP server wrapping a Cortex Analyst semantic view as a discoverable toolCREATE MCP SERVER CORTEX AI.AGENTS.FINANCE MCP SERVER FROM SPECIFICATION $$ tools: - name: "finance-analyst" type: "CORTEX ANALYST MESSAGE" identifier: "cortex ai.semantic views.finance revenue" title: "Finance Revenue Analysis" description: "Query governed finance metrics via Cortex Analyst" $$; The specification supports five tool types, verified against documentation: Tool Type Wraps Use Case CORTEX ANALYST MESSAGE Semantic views Natural language → governed SQL CORTEX SEARCH SERVICE QUERY Cortex Search services RAG / knowledge base search CORTEX AGENT RUN Cortex Agents Invoke another agent as a tool SYSTEM EXECUTE SQL SQL execution Direct SQL against Snowflake GENERIC UDFs / stored procedures Custom logic as MCP tools Here’s a multi-tool example combining Cortex Analyst and direct SQL execution in a single server: -- Multi-tool MCP server combining natural language analytics and direct SQL executionCREATE OR REPLACE MCP SERVER CORTEX AI.AGENTS.ANALYTICS MCP SERVER FROM SPECIFICATION $$ tools: - name: "revenue-analyst" type: "CORTEX ANALYST MESSAGE" identifier: "cortex ai.semantic views.finance revenue" title: "Revenue Analysis" description: "Query governed revenue metrics via natural language" - name: "sql-executor" type: "SYSTEM EXECUTE SQL" title: "SQL Execution" description: "Execute arbitrary SQL queries against connected databases" $$; No container to deploy. No TLS cert to manage. No health checks to configure. The MCP server runs inside Snowflake’s compute layer, inherits network policies, and authenticates through Snowflake’s identity providers OAuth, PAT, key-pair JWT . Production Note:The managed MCP server is a schema-level object. In multi-account environments, each account needs its own. Naming convention:{domain} {env} mcp server e.g.,finance prod mcp server . Reference: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp SQL Reference: https://docs.snowflake.com/en/sql-reference/sql/create-mcp-server https://docs.snowflake.com/en/sql-reference/sql/create-mcp-server The use case that surprised me most: teams that never open Snowsight now consume our governed semantic layer through their own tooling. Any MCP-compatible client can connect. The endpoint pattern uses your account identifier and the MCP server’s fully qualified path: { "mcpServers": { "snowflake-analytics": { "url": "https://<account identifier .snowflakecomputing.com/api/v2/cortex/mcp", "headers": { "X-Snowflake-MCP-Server": "CORTEX AI.AGENTS.FINANCE MCP SERVER" } } }} Note:Verify the exact endpoint URL and authentication pattern in current documentation. Snowflake supports OAuth 2.0, PATs, and key-pair JWT for MCP client authentication. Reference:https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp The connecting client only sees tools the authenticated user’s default role can access. RBAC controls visibility at the MCP level: -- Grant access to the MCP server; RBAC governs which tools are visible per user roleGRANT USAGE ON MCP SERVER CORTEX AI.AGENTS.FINANCE MCP SERVER TO ROLE DATA ANALYSTS; Analysts see finance tools. The same MCP server returns different tool manifests to different users based on their role privileges. To inspect what’s been created: SHOW MCP SERVERS IN SCHEMA CORTEX AI.AGENTS;DESCRIBE MCP SERVER CORTEX AI.AGENTS.FINANCE MCP SERVER; Back to the renewal scenario. With external MCP connectors Preview Feature — Open , the same agent that detected churn risk can: update the Salesforce opportunity, alert the Slack channel, create a Jira ticket. Same conversational turn. The setup requires three objects. First, an API integration with the external MCP provider, using Dynamic Client Registration for OAuth: -- API integration for Jira MCP connectivity; API PROVIDER = external mcp is the correct valueCREATE API INTEGRATION JIRA MCP API INTEGRATION API PROVIDER = external mcp API ALLOWED PREFIXES = 'https://mcp.jira.atlassian.com' API USER AUTHENTICATION = TYPE = OAUTH DYNAMIC CLIENT OAUTH RESOURCE URL = 'https://mcp.atlassian.com/v1/mcp' ENABLED = TRUE; Then create the external MCP server referencing that integration: -- External MCP server referencing the API integration; URL, API INTEGRATION, and DISPLAY NAME are requiredCREATE EXTERNAL MCP SERVER CORTEX AI.AGENTS.JIRA MCP SERVER URL = 'https://mcp.jira.atlassian.com/v1/mcp' API INTEGRATION = JIRA MCP API INTEGRATION DISPLAY NAME = 'Jira Project Management'; Finally, wire the external MCP server into a Cortex Agent via the mcp servers field in the agent specification: -- Cortex Agent spec wiring both Cortex Analyst tools and external MCP servers in one definitionCREATE OR REPLACE AGENT CORTEX AI.AGENTS.OPERATIONS ASSISTANT FROM SPECIFICATION $$ models: orchestration: auto tools: - tool spec: type: "cortex analyst text to sql" name: "ChurnAnalysis" description: "Query customer health metrics" tool resources: ChurnAnalysis: semantic view: "cortex ai.semantic views.customer health" execution environment: type: warehouse warehouse: "COMPUTE WH" mcp servers: - server spec: name: "CORTEX AI.AGENTS.JIRA MCP SERVER" - server spec: name: "CORTEX AI.AGENTS.FINANCE MCP SERVER" $$; Reference: https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp-connectors https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp-connectors Screenshot recommendation: Snowsight CoWork conversation showing the agent creating a Jira ticket in the same turn as the analysis. IMPORTANT — What the docs don’t emphasize:An agent with write access to four systems simultaneously is dangerous with vague instructions. I learned this when a loosely-instructed agent posted an internal churn analysis to a customer-facing Slack channel during testing. Treat write-capable MCP tools the same way you treat stored procedures with DML: grant carefully, audit always. This distinction tripped me up initially. The documentation covers three separate DDL commands for three use cases: DDL Command Feature Status Purpose CREATE MCP SERVER GA Wrap Snowflake-native objects as MCP tools managed CREATE EXTERNAL MCP SERVER Preview Open Connect to remote MCP providers Jira, Salesforce, Slack CREATE CUSTOM MCP SERVER Preview Open Register SPCS service endpoints as MCP servers The managed MCP server first row wraps objects that already exist in your Snowflake account. The external MCP server second row connects to remote providers. The custom MCP server third row lets you expose arbitrary code running in Snowpark Container Services as MCP tools — useful when you need a language or framework not supported by UDFs. This article covers the first two. SPCS-hosted servers are a separate topic. The Summit 2026 announcement that changes the operational model most: Automations and time-based subscriptions public preview soon . From the blog: “Every Monday, compare each account’s consumption to the prior week. If any drops more than 20%, brief me with the root cause and recommended action.” This transforms MCP from reactive user asks → agent acts to proactive agent monitors → agent acts → user is briefed . CoWork runs in the background, checks conditions, identifies anomalies, and delivers updates via email, Slack, or mobile alerts. For enterprise architects: proactive agents multiply the governance requirements. An agent that runs autonomously every Monday needs the same cost controls, audit trail, and action boundaries as an interactive session — possibly more, because nobody is watching in real time. External tools connect to Snowflake’s semantic layer through the managed MCP server. Metrics defined once in semantic views; every client inherits governed definitions. No metric drift between tools. -- Governed semantic layer MCP server exposing both Cortex Analyst and Cortex Search toolsCREATE OR REPLACE MCP SERVER CORTEX AI.AGENTS.SEMANTIC LAYER MCP FROM SPECIFICATION $$ tools: - name: "revenue-metrics" type: "CORTEX ANALYST MESSAGE" identifier: "cortex ai.semantic views.finance revenue" title: "Revenue Metrics" description: "Governed revenue metrics — definitions match across all consumers" - name: "customer-search" type: "CORTEX SEARCH SERVICE QUERY" identifier: "cortex ai.agents.customer knowledge base" title: "Customer Knowledge Base" description: "Search customer documentation and support history" $$; CoWork detects something → invokes external MCP tools in the same turn. With automations/subscriptions coming , this becomes proactive. The agent spec below combines Cortex Analyst for analysis with external MCP servers for action — and uses explicit instructions to prevent unwanted writes: -- Churn response agent with constrained action boundaries; instructions prevent unauthorized writesCREATE OR REPLACE AGENT CORTEX AI.AGENTS.CHURN RESPONSE AGENT FROM SPECIFICATION $$ models: orchestration: auto instructions: | You are a customer health monitor. When asked to analyze churn risk: 1. Query customer health semantic view for at-risk accounts 2. For any account above 70% churn probability, create a Jira ticket with severity P2 and assign to the account owner 3. Do NOT post to external Slack channels without explicit confirmation tools: - tool spec: type: "cortex analyst text to sql" name: "CustomerHealth" description: "Query customer health and churn probability metrics" tool resources: CustomerHealth: semantic view: "cortex ai.semantic views.customer health" execution environment: type: warehouse warehouse: "COMPUTE WH" mcp servers: - server spec: name: "CORTEX AI.AGENTS.JIRA MCP SERVER" $$; Multiple domain-specific MCP servers, each wrapping different Snowflake objects. An external orchestrator LangGraph, etc. connects to all of them as MCP clients. Domain isolation stays in Snowflake; cross-domain reasoning happens in the orchestrator. Multi-agent orchestration public preview soon may eventually handle this routing natively inside CoWork, reducing the need for external orchestrators. The surprise: RBAC propagation through MCP is more seamless than expected. I built application-layer auth middleware that turned out to be completely redundant — Snowflake’s identity layer handles it at the protocol level. Every MCP invocation carries the user’s identity and role. The limitation the docs don’t highlight: The managed MCP server is a schema-level object. For the Federated Hub pattern, that means your client configuration grows linearly with domain count. There’s no “meta-server” that aggregates tools from multiple schemas into a single endpoint yet. The dangerous mistake: External MCP connectors Jira, Salesforce, Slack use per-user OAuth. That means the agent acts with the individual user’s permissions on the remote system. If a user has admin permissions in Jira, the agent has admin permissions in Jira. Scope your connected accounts deliberately — don’t wire up your personal Salesforce admin account for testing and forget to switch it. My recommendation: Start with Pattern 1 managed MCP server exposing Cortex Analyst . It’s GA, requires no external OAuth setup, and validates end-to-end auth flow. Add write-capable external MCP connectors only after you’ve written explicit, tested agent instructions that constrain action boundaries. When automations enter preview, apply the same rigor to proactive agents as interactive ones. MCP integration makes CoWork bi-directional. External tools query Snowflake’s governed semantic layer through the managed MCP server GA . CoWork agents reach out to Gmail, Jira, Salesforce, and Slack through external MCP connectors Preview — Open . The governance model — user identity, default role, admin-defined RBAC — holds across all surfaces. Start with the managed server. Constrain write access deliberately. When proactive automations arrive, remember that an unsupervised agent needs more guardrails than an interactive one. Next: Article 4 — Govern CoWork at Scale: RBAC, Resource Budgets, and Cost Enforcement. 👏 Give it a clap if it added value 🔗 Share it with your team ➕ Follow for more 📘 Medium: @SnowflakeChronicles 🔗 LinkedIn: satishkumar-snowflake See you in the next one 👋 This article represents the author’s personal views and experience, not those of any employer. -- Run these cleanup commands after testing the examples aboveDROP AGENT IF EXISTS CORTEX AI.AGENTS.OPERATIONS ASSISTANT;DROP AGENT IF EXISTS CORTEX AI.AGENTS.CHURN RESPONSE AGENT;DROP MCP SERVER IF EXISTS CORTEX AI.AGENTS.FINANCE MCP SERVER;DROP MCP SERVER IF EXISTS CORTEX AI.AGENTS.ANALYTICS MCP SERVER;DROP MCP SERVER IF EXISTS CORTEX AI.AGENTS.SEMANTIC LAYER MCP;DROP EXTERNAL MCP SERVER IF EXISTS CORTEX AI.AGENTS.JIRA MCP SERVER;DROP INTEGRATION IF EXISTS JIRA MCP API INTEGRATION; Wiring Snowflake CoWork to Salesforce, Slack, and Jira via MCP https://pub.towardsai.net/wiring-snowflake-cowork-to-salesforce-slack-and-jira-via-mcp-54d6ce3277ac was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.