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

> Source: <https://pub.towardsai.net/wiring-snowflake-cowork-to-salesforce-slack-and-jira-via-mcp-54d6ce3277ac?source=rss----98111c9905da---4>
> Published: 2026-07-09 11:30:41+00:00

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.