Snowflake MCP server: give marketing answers without handing over the warehouse

Claude and ChatGPT only see the tools an MCP server lists. Snowflake's server lists the ones you write into its specification, and each tool runs under a Snowflake role you grant. That's what lets a data team give marketing answers from the warehouse without handing over the warehouse.

At martechdevs, we set this up as part of AI-ready data and MCP access projects, on top of the Snowflake and BigQuery builds we run for product companies. This guide is the setup we use, with the SQL.

What is the Snowflake MCP server?

MCP (Model Context Protocol) is the open standard AI tools use to call outside systems. An MCP server lists tools, and the AI client decides when to call them. Snowflake's version is managed: it runs inside your account, so there's nothing to host.

It went to preview on 1 October 2025 and became generally available on 4 November 2025, the same week as Cortex Agents. Snowflake said more than 1,000 customers had deployed more than 15,000 agents during the preview (SiliconANGLE, November 2025).

A server can expose five kinds of tool:

• Cortex Agent (CORTEX_AGENT_RUN): an agent you configure in Snowflake, with its own instructions and tools, usually Cortex Analyst and Cortex Search.
• Cortex Analyst (CORTEX_ANALYST_MESSAGE): turns a question into SQL over a semantic view. It works over semantic views only.
• Cortex Search (CORTEX_SEARCH_SERVICE_QUERY): search over text, such as call notes, tickets or product docs.
• SQL execution (SYSTEM_EXECUTE_SQL): runs SQL directly. It is read-only unless you switch that off.
• Custom tools (GENERIC): your own functions or stored procedures.

A server holds up to 50 tools. Snowflake notes that more tools can make the client worse at picking the right one, which is one more reason to keep the list short.

Why put one Cortex Agent in front of marketing?

Snowflake's docs recommend exposing a single Cortex Agent as the tool for governed business questions, and keeping SQL execution on a separate server with its own least-privileged role. For marketing data, that advice matters more than it looks.

Give Claude raw SQL and ask for CAC, and it picks the tables and the formula itself. It might count every lead source, use gross revenue, or join spend on the wrong date. Each answer reads confidently. Behind an agent, the question goes to Cortex Analyst, which answers over a semantic view where CAC is defined once, the way finance agreed it.

Gartner expects organisations to abandon 60% of AI projects unsupported by AI-ready data through 2026 (Gartner, February 2025). For a marketing team, the semantic view is most of what AI-ready means: one definition per metric, in a place the AI has to go through. The seven checks for AI-ready marketing data cover the rest.

How do you set up the Snowflake MCP server?

Model first, then the agent, then the server, then access. Each step below runs in a Snowsight worksheet, with a role that can create these objects. The names (a marketing database, an mcp schema) are examples.

1. Model the metrics as a semantic view

Cortex Analyst only answers over semantic views, so start there. Build the view on your modelled tables, from dbt or your own models, with the metrics marketing asks about most: spend, new customers, CAC, ROAS, pipeline created and MQL to SQL rate. Write a plain-English description for every metric and column. Those descriptions are what the agent reads.

2. Create a Cortex Agent

Create an agent in Snowsight that uses the semantic view through Cortex Analyst, and Cortex Search if it should read text such as call notes. Give it instructions in your team's words: which metrics it may report, which time zone and currency to use, and when to say it doesn't know.

3. Create the MCP server with the agent as its only tool

CREATE MCP SERVER marketing.mcp.marketing_answers
  FROM SPECIFICATION $$
  tools:
    - title: "Marketing data agent"
      name: "marketing_data_agent"
      type: "CORTEX_AGENT_RUN"
      identifier: "marketing.mcp.marketing_agent"
      description: "Answers questions about spend, CAC, ROAS, pipeline and conversion rates."
  $$;

The description is what the AI client reads to decide when to call the tool, so write it the way your team asks questions. SHOW MCP SERVERS IN ACCOUNT and DESCRIBE MCP SERVER confirm it exists.

4. Create a role with only what the agent needs

CREATE ROLE marketing_mcp_role;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE marketing_mcp_role;
GRANT USAGE ON WAREHOUSE mcp_wh TO ROLE marketing_mcp_role;
GRANT USAGE ON DATABASE marketing TO ROLE marketing_mcp_role;
GRANT USAGE ON SCHEMA marketing.mcp TO ROLE marketing_mcp_role;
GRANT USAGE ON MCP SERVER marketing.mcp.marketing_answers TO ROLE marketing_mcp_role;
GRANT USAGE ON AGENT marketing.mcp.marketing_agent TO ROLE marketing_mcp_role;
GRANT SELECT ON SEMANTIC VIEW marketing.mcp.marketing_metrics TO ROLE marketing_mcp_role;
-- Plus SELECT on any table the agent reads directly.
GRANT ROLE marketing_mcp_role TO USER marketing_analyst;

Access to the server doesn't grant access to its tools, so every grant counts. Give the role to named people, never to PUBLIC.

5. Create the OAuth integration

Snowflake OAuth is the default, and the server doesn't support dynamic client registration, so you create each client yourself. Claude uses a public client with PKCE:

CREATE SECURITY INTEGRATION marketing_mcp_claude
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  ENABLED = TRUE
  OAUTH_CLIENT_TYPE = 'PUBLIC'
  OAUTH_REDIRECT_URI = 'https://claude.ai/api/mcp/auth_callback'
  OAUTH_USE_SECONDARY_ROLES = NONE
  ALLOWED_ROLES_LIST = ('MARKETING_MCP_ROLE');

-- The client ID and secret to paste into Claude
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('MARKETING_MCP_CLAUDE');

-- So each session starts with the right role and warehouse
ALTER USER marketing_analyst SET DEFAULT_ROLE = 'MARKETING_MCP_ROLE' DEFAULT_WAREHOUSE = 'MCP_WH';

OAUTH_USE_SECONDARY_ROLES = NONE stops a session from picking up a person's other, wider roles. Use the redirect URI the client shows during setup; the one above is Claude's. ChatGPT and Cursor use a confidential client (OAUTH_CLIENT_TYPE = 'CONFIDENTIAL') with their own redirect URI.

6. Connect Claude, ChatGPT or Cursor

The server URL follows one pattern. In the account host name, replace any underscores with hyphens.

https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>

• Claude: Settings, Connectors, Add custom connector. Paste the URL, then the client ID and secret, and sign in to Snowflake.
• ChatGPT: turn on Developer mode under Settings, Connectors, Advanced. Then create a connector with the URL, choose OAuth and paste the client ID and secret.
• Cursor: add the URL with the client ID and secret to .cursor/mcp.json, then sign in from Cursor's MCP settings.

If your account has a network policy, allow the client provider's outbound IPs with an ingress network rule. Otherwise the connection fails before sign-in.

Should you expose SQL execution to an AI tool?

Only on a separate server, with its own read-only role, for people who already write SQL. SYSTEM_EXECUTE_SQL is read-only by default (read_only: true), and Snowflake's docs recommend putting it on its own server with a dedicated least-privileged role.

Read-only lowers the risk without removing it. Simon Willison calls it the lethal trifecta: private data, untrusted content and a way to send data out, in one agent session (Simon Willison, June 2025). A marketing stack has all three: CRM and revenue data, inbound emails and form fills, and tools that send email. Keep the warehouse server out of sessions that also hold an email-sending tool.

SQL and custom tool responses are cut at 250 KB, so a broad query comes back partial. Ask for aggregates, and keep row-level exports in the tools built for them.

What does the Snowflake MCP server cost?

Snowflake said at launch that the server needs no extra compute and has no separate charge (Snowflake, October 2025). The tools behind it still use credits: the warehouse that runs each query, plus Cortex Analyst, Cortex Search and the agent.

• Give the MCP role its own small warehouse with auto-suspend, so AI questions don't share or resize a production warehouse.
• Put a resource monitor on that warehouse, so a client stuck in a loop can't use a month of credits.
• If your team also uses Snowflake CoWork, set its resource budgets and per-user credit quotas.
• Review usage after the first two weeks, then decide whether the questions justify the spend.

What are the limits?

• Tools only. The server doesn't serve MCP resources or prompts.
• No dynamic client registration, so every client needs an OAuth integration you create.
• Up to 50 tools per server, across all tool types.
• SQL and custom tool responses are cut at 250 KB. Agent responses can pass 200 KB, because they include the intermediate steps.
• Up to 10 nested calls, so avoid agents and tools that call each other in a loop.
• MCP server objects aren't replicated in failover groups. Recreate them on the secondary account. The OAuth integrations do replicate.
• Snowflake supports MCP revision 2025-11-25.

Snowflake Intelligence, CoWork and Cortex Code: which is which?

The names moved in 2026, and most search results haven't caught up.

• Snowflake CoWork is how Snowflake's docs now describe the product launched as Snowflake Intelligence, which went GA on 4 November 2025. It's the chat assistant inside Snowflake, with your row access and column policies applied. CoWork Automations, which re-run a question on a schedule and email the result, went GA on 11 September 2026.
• Cortex Agents are the agents you configure. CoWork and the MCP server can both use them.
• Cortex Code is Snowflake's coding agent, in Snowsight, a desktop app and a CLI.
• Snowflake-Labs/mcp, the community server many guides still link, is marked deprecated on GitHub and points to the managed server.

If your team works in Claude or ChatGPT all day, the MCP server brings the warehouse to them. If they already work inside Snowflake, CoWork may be enough on its own.