How to connect Claude to your data warehouse with MCP

Claude can query your data warehouse. Not through a custom API wrapper. Not through a chatbot you build from scratch. Through MCP — Model Context Protocol — an open standard that lets AI models connect to external tools and data sources.

We use this daily. Claude connected to BigQuery, reading dbt documentation, answering questions about pipeline health, querying PostHog for engagement data. The setup takes 30 minutes. The value compounds from day one.

What MCP actually is

MCP is a protocol that lets an AI model call external tools. Instead of pasting SQL output into a chat window, the model connects to your database directly, writes the query, runs it, reads the results, and answers your question.

Think of it like this: without MCP, Claude is a smart colleague you have to hand-feed data. With MCP, Claude has a terminal open to your warehouse and can look things up on its own.

The protocol is open (Anthropic published the spec), and MCP servers exist for most data tools:

You're not limited to one. Connect Claude to BigQuery and PostHog and your dbt docs simultaneously. It uses whichever tool answers the question best.

Setting it up: BigQuery example

1. Install the MCP server

# In your Claude Code config (~/.claude/config.json)
{
  "mcpServers": {
    "bigquery": {
      "command": "npx",
      "args": ["-y", "@anthropic/bigquery-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json",
        "BQ_PROJECT_ID": "your-project-id"
      }
    }
  }
}

2. Grant the service account read access

Create a service account with BigQuery Data Viewer and BigQuery Job User roles. Read-only. Claude doesn't need write access to answer questions.

3. Ask questions in natural language

Once connected, you can ask Claude:

• "What were our top 10 blog posts by pageviews last month?"
• "Show me the conversion rate from /pricing to /contact/thanks for the last 30 days."
• "Which dbt models failed their tests this week?"
• "What's the month-over-month revenue trend for Q1?"

Claude writes the SQL, runs it against BigQuery, reads the results, and answers in plain English. If the first query doesn't get the right data, it iterates — checking schemas, adjusting joins, refining filters.

Snowflake setup

Same pattern, different server:

{
  "mcpServers": {
    "snowflake": {
      "command": "npx",
      "args": ["-y", "@anthropic/snowflake-mcp"],
      "env": {
        "SNOWFLAKE_ACCOUNT": "your-account.snowflakecomputing.com",
        "SNOWFLAKE_USER": "claude_readonly",
        "SNOWFLAKE_PASSWORD": "...",
        "SNOWFLAKE_WAREHOUSE": "COMPUTE_WH",
        "SNOWFLAKE_DATABASE": "ANALYTICS",
        "SNOWFLAKE_SCHEMA": "MARTS"
      }
    }
  }
}

Point it at your mart schema. Claude reads the clean, tested, documented tables — not the raw mess in staging.

PostHog: adding behavioral data

This is the combination we run on warehows.ai. Claude connected to PostHog can answer:

• "How many unique visitors hit the blog this week?"
• "What's the average session duration on /services pages?"
• "Show me the funnel from /blog/ to /contact to /contact/thanks."*
• "Which UTM campaigns drove the most contact form submissions?"

{
  "mcpServers": {
    "posthog": {
      "command": "npx",
      "args": ["-y", "@posthog/mcp-server"],
      "env": {
        "POSTHOG_API_KEY": "phx_your_personal_api_key",
        "POSTHOG_HOST": "https://us.i.posthog.com",
        "POSTHOG_PROJECT_ID": "12345"
      }
    }
  }
}

The multi-tool pattern

The real power is connecting multiple MCP servers. Claude sees all of them and picks the right tool for the question:

{
  "mcpServers": {
    "bigquery": { ... },
    "posthog": { ... },
    "dbt-cloud": {
      "command": "npx",
      "args": ["-y", "@dbt-labs/mcp-server"],
      "env": {
        "DBT_CLOUD_API_KEY": "...",
        "DBT_CLOUD_ACCOUNT_ID": "..."
      }
    }
  }
}

Now you can ask:

• "Check if any dbt tests failed this morning, and if so, query BigQuery to see if the downstream tables are affected." — Claude checks dbt Cloud first, then queries BigQuery.
• "Compare last week's blog traffic from PostHog with the GSC impression data in BigQuery." — Claude queries both and synthesizes.
• "What does the stg_orders model do?" — Claude reads the dbt documentation, not the raw SQL.

What we've built with this

Conversational analytics via Slack

PostHog MCP + Claude API + a Slack bot. Team members ask questions in a #data channel. Claude queries PostHog, returns the answer with a chart description. No dashboard login required.

Example exchange:

User: How did the new blog post perform this week? Claude: "Your QuickBooks data is lying to you" got 342 pageviews from 289 unique visitors since publish. Average session duration: 4m12s. 8 users clicked through to /contact. Top referrer: LinkedIn (utm_source=linkedin, 47% of traffic).

Automated review cycles

Every two weeks, Claude runs a set of queries against BigQuery (GA4 + GSC data) and PostHog, compiles a performance snapshot, identifies anomalies, and writes a summary. What used to take an analyst 3 hours happens in 2 minutes.

Pipeline health monitoring

Claude checks dbt test results via the dbt Cloud MCP server. If tests fail, it queries BigQuery to assess the blast radius — which mart tables are affected, which dashboards might show stale data. Summary goes to Slack.

Security: what to get right

MCP gives Claude direct access to your data. Treat the connection like any other service account:

1. Read-only access. Always. Claude doesn't need to write, delete, or modify. BigQuery Data Viewer + BigQuery Job User is the correct role set.
2. Scoped to the right schema. Point it at your mart layer, not your raw tables. Mart models are tested, documented, and contain the business-friendly column names.
3. Service account, not personal credentials. Create a dedicated claude-readonly service account. Audit its queries. Rotate keys on schedule.
4. No PII in the response path. If your warehouse contains PII, either restrict the service account to non-PII schemas or add BigQuery column-level security to mask sensitive fields.
5. API keys in environment variables. Never in config files committed to git. Use .env.local or a secrets manager.

MCP vs. text-to-SQL tools

How does this compare to Snowflake Cortex Analyst, Databricks AI/BI Genie, or custom text-to-SQL chatbots?

MCP is more flexible and tool-agnostic. Cortex Analyst is deeper within its vendor ecosystem. For teams already on dbt, MCP with Claude is the faster path — your dbt documentation is the semantic model.

The bigger picture

MCP is how AI agents stop being chat-only and start being operational. Instead of asking Claude to analyze data you paste in, you give Claude the ability to look things up, verify assumptions, and chain queries across tools.

The data warehouse becomes the agent's memory. dbt docs become the agent's schema reference. PostHog becomes the agent's eyes on user behavior. The agent works with the same tools your team uses — it just works faster.

Every company we work with that has a clean warehouse and a tested dbt layer is one MCP config file away from having a conversational analytics layer. The hard part was always the data foundation. The AI layer is surprisingly easy once that foundation exists.

We connect Claude to data warehouses, PostHog, and dbt for teams that want conversational analytics without building a custom chatbot. If your warehouse is clean and you want to put an AI layer on top of it, book a discovery call.