Snowflake MCP for GTM teams: what an agent can answer from your warehouse, and what it gets wrong without a context layer

The short version

Snowflake MCP is the Snowflake-managed Model Context Protocol server that lets AI clients such as Claude, ChatGPT and Cursor query a Snowflake account through Cortex Analyst, Cortex Search, Cortex Agents and SQL tools, under each user's role. RevSure, the agentic GTM platform built on the Full Funnel Data Graph, gives those agents resolved GTM data to read, so the warehouse answers the same way a pipeline report does.

Three weeks into a new RevOps job at an AI IT service management startup, the person who now owns attribution was building one table of every touchpoint the company records. She was doing most of the work through Claude and the warehouse, and her first ask in a meeting with us in October was about history: "do we have what we need to get more than like the 90 days of data into Snowflake."

Her second problem was harder. "We get sort of the same signal from a lot of different places," she said. A rep's email shows up as a Salesforce task, as a Salesforce email and again as a HubSpot email, "so it's like we kind of have like three different lines representing all the same thing." Website visits arrive the same way, from more than one tracker.

Point an AI agent at those tables and ask how many times target accounts engaged last quarter, and it will count every line. The query will run, the answer will be confident, and it will be wrong by a factor the agent cannot see. That is the gap this guide is about.

What is Snowflake MCP?

Snowflake MCP usually means the Snowflake-managed MCP server: an MCP server object that lives inside a Snowflake account and exposes chosen Snowflake capabilities as tools to any client that speaks the Model Context Protocol. An administrator creates the server with SQL and a YAML specification that lists the tools. According to Snowflake's documentation, a server can expose five kinds of tools:

• Cortex Analyst (type CORTEX_ANALYST_MESSAGE), which turns a natural language question into SQL against a semantic view.
• Cortex Search (CORTEX_SEARCH_SERVICE_QUERY), which searches unstructured text such as call notes or support tickets.
• SQL execution (SYSTEM_EXECUTE_SQL), which runs SQL the agent writes.
• Cortex Agents (CORTEX_AGENT_RUN), which hands the question to an agent already configured in Snowflake.
• Custom tools (GENERIC), which wrap a user-defined function or stored procedure.

Clients reach the server at an endpoint in the account, and Snowflake's MCP guide recommends OAuth for authentication. The earlier open source Snowflake-Labs MCP server is marked deprecated in its repository, which points users to the managed server, so new projects should start there.

The important design choice is access control. Snowflake's guide says "Access to the MCP Server does not give access to the tools. Permission needs to be granted for each tool." Every question runs under a Snowflake role, so the agent sees what that role can see and nothing more.

How do you connect Claude to Snowflake MCP?

The setup is a short sequence of SQL steps and one client setting. In order:

1. Create an OAuth security integration for the MCP client, with OAUTH_CLIENT set to CUSTOM and an allowed roles list that names the role you will use for MCP access. Read the client ID and secret with SYSTEM$SHOW_OAUTH_CLIENT_SECRETS.
2. Create a dedicated role for MCP access and grant it the SNOWFLAKE.CORTEX_AGENT_USER database role, plus USAGE on the warehouse, database and schema.
3. Grant tool privileges one by one: SELECT on each semantic view Cortex Analyst will use, USAGE on each Cortex Search service, agent, function or procedure. USAGE on the MCP server itself only lets a client connect and list tools.
4. Set the user's default role and warehouse to the MCP role and a running warehouse. Some clients, Claude among them, use the user's default role, and sessions fail without a default warehouse.
5. Create the MCP server with CREATE MCP SERVER and a YAML specification listing each tool's name, type, identifier and description.
6. Add the server in your client using the endpoint URL. In Claude, that means adding it as a connector with the client ID and secret from step 1.

CREATE MCP SERVER gtm_db.analytics.gtm_mcp
  FROM SPECIFICATION $$
tools:
  - name: "pipeline-metrics"
    type: "CORTEX_ANALYST_MESSAGE"
    identifier: "gtm_db.analytics.pipeline_semantic_view"
    title: "Pipeline metrics"
    description: "Opportunities, pipeline and conversion by segment, stage, source and quarter"
  - name: "call-notes"
    type: "CORTEX_SEARCH_SERVICE_QUERY"
    identifier: "gtm_db.analytics.call_notes_search"
    title: "Call note search"
    description: "Search sales call notes and meeting summaries by account or topic"
$$;

GRANT USAGE ON MCP SERVER gtm_db.analytics.gtm_mcp TO ROLE gtm_mcp_role;
GRANT SELECT ON SEMANTIC VIEW gtm_db.analytics.pipeline_semantic_view TO ROLE gtm_mcp_role;
GRANT USAGE ON CORTEX SEARCH SERVICE gtm_db.analytics.call_notes_search TO ROLE gtm_mcp_role;

Two details catch teams out. Snowflake notes that MCP connections have trouble with hostnames that contain underscores, so use the hyphenated form of the account URL. And the tool descriptions in the YAML matter more than they look: the agent reads them to decide which tool to call, so "Pipeline and opportunity metrics by segment, stage and quarter" will be used far more accurately than "semantic view 1". Our guide to Claude connectors covers the Claude side of adding a remote server.

12 prompts to run against Snowflake on day one

These prompts assume a semantic view over your opportunity, account and campaign tables. Each one tests something different: a count, a join, a time window or a definition.

1. How many opportunities were created last quarter, by segment and by source?
2. What was the stage-to-stage conversion rate from first meeting to closed-won for opportunities created in the first half of the year?
3. Which 20 accounts had the most web visits in the last 30 days and no open opportunity?
4. What is the average sales cycle in days for closed-won deals over $50,000, by region?
5. List opportunities that have sat in the same stage for more than 45 days, with owner and amount.
6. How much pipeline did each campaign type touch in the 90 days before opportunity creation?
7. Which accounts have more than five contacts engaged this month but fewer than two contacts on the open opportunity?
8. Compare win rates for opportunities with a completed demo against those without one.
9. Search call notes for mentions of security review in deals that slipped last quarter.
10. Which leads were created in the last 14 days and have not been contacted?
11. What share of closed-won revenue last year came from accounts on the target account list?
12. Show monthly new pipeline for the last 12 months next to the plan figure for each month.

Run the first three and check the answers against the CRM report your team already trusts. If they match, you have a usable setup. If they do not, the reason is rarely the agent's SQL. It is usually the data underneath.

What does an agent get wrong when it reads raw warehouse tables?

A warehouse holds what each source system sent it, in that system's shape. The agent writes correct SQL against those tables and still returns the wrong business answer, for reasons that sit one level below the query:

• The same touch is stored more than once. This is the startup's three-lines problem. A CRM task, a CRM email and a marketing automation email can all describe one message, and web visits can arrive from more than one tracker. Counting rows counts systems, not buyer behavior.
• The same buyer has several IDs. A lead in the marketing automation platform, a contact in the CRM and an anonymous visitor on the website can be one person at one account. Without identity resolution, an account looks less engaged than it is, and a person looks like three.
• Stage definitions live in people's heads. The CRM stores a stage name. Whether "Stage 2" means a qualified opportunity, and which date counts as entry, is a rule the semantic view has to encode. If it does not, every agent invents its own.
• Lookback windows are a choice. "Pipeline the campaign touched" depends on how many days before creation a touch still counts. Two people asking the same question with different windows get different numbers, and both look right.
• History is shorter than the question. The startup's first ask was for more than 90 days of history in the warehouse. An agent asked about year-over-year conversion will answer from whatever the tables hold, without saying the window is short.

None of these show up as errors. They show up as a number in a deck that does not match the one in the CRM, and a meeting spent arguing about which is right. Our post on context engineering explains why agents need this business context supplied, not inferred.

Raw warehouse tables vs a governed context layer

The table below shows where an agent's answer changes once it reads resolved, governed GTM data instead of raw source tables.

Where RevSure fits with Snowflake

Snowflake is where many GTM teams keep their data. Our platform connects to it in both directions: we ingest from Snowflake and push pre-computed tables back into the warehouse you already run, on a schedule you configure. Those tables come from the Full Funnel Data Graph, where touches are de-duplicated, people and accounts are resolved across systems, and funnel stages follow the definitions your team agreed.

That gives a team two good options. A semantic view built on those tables lets Cortex Analyst answer from resolved data inside Snowflake, under Snowflake's own roles. And for questions that span the full funnel, an assistant can call our MCP server alongside Snowflake's, through tools such as Get Account Context and Get Funnel Health Metrics.

Our Digital Marketing Analyst works from the same layer. It reads campaign, channel, funnel and pipeline performance daily, finds where pipeline leaks and sends a weekly read with recommendations for your marketing leader to approve. Our GTM engineers, working as an embedded GTM pod, keep the definitions it reads current as stages, segments and campaigns change. Reverse ETL, which copies modeled warehouse data back into operational tools, still has a place for teams that want warehouse tables in the CRM; the context layer is what makes those tables mean the same thing everywhere.

The query was never the hard part

The new RevOps owner at the startup knew her SQL. What she was building by hand was a rulebook: which of three lines is the real email, which tracker counts, where the funnel starts. Snowflake MCP makes it easy for every person on a team to ask the warehouse a question. It does not decide which rulebook the agent follows. Teams that settle that once, in a governed layer every agent reads, get answers that match the pipeline report. Teams that leave it to each prompt get as many versions of the truth as they have people asking.

FAQs

What is Snowflake MCP?

Snowflake MCP is the Snowflake-managed Model Context Protocol server, an object created inside a Snowflake account that exposes chosen tools to AI clients such as Claude, ChatGPT and Cursor. Tools can include Cortex Analyst over semantic views, Cortex Search, SQL execution, Cortex Agents and custom functions. Each tool needs its own privilege, so the agent sees only what the user's role allows.

How do I connect Claude to Snowflake?

Create an OAuth security integration, a dedicated role with the CORTEX_AGENT_USER database role and per-tool privileges, and set that role and a warehouse as the user's defaults. Then create the MCP server with CREATE MCP SERVER and a YAML tool specification, and add its endpoint URL in Claude as a connector using the OAuth client ID and secret.

Is the Snowflake-Labs MCP server still supported?

The open source Snowflake-Labs MCP server is marked deprecated in its GitHub repository, which points users to the Snowflake-managed MCP server. Teams starting now should use the managed server, which runs inside the Snowflake account, uses OAuth and applies role-based access control to each tool.

Why does Claude give a different number from Snowflake than our CRM report?

Usually because the warehouse tables hold duplicates and unresolved identities the CRM report does not count, such as the same email stored by two systems, or because the agent picked a different stage definition, date field or lookback window. A semantic view or context layer that encodes those rules once makes every agent answer the same way.

Does RevSure work with Snowflake?

Yes. RevSure ingests GTM data from Snowflake and pushes pre-computed tables from the Full Funnel Data Graph back into the customer's Snowflake warehouse on a configurable schedule. Teams can build a Snowflake semantic view on those resolved tables, and AI assistants can also query RevSure directly through the RevSure MCP server.

What is the difference between Snowflake MCP and reverse ETL?

Snowflake MCP lets an AI client ask questions of warehouse data and call warehouse tools in real time. Reverse ETL copies modeled warehouse data into operational systems such as the CRM on a schedule. Both depend on the warehouse holding clean, resolved data; neither one de-duplicates touches or resolves identities on its own.