What Is an MCP Server for Data? The Complete Guide (2026)

Your VP of Sales asks the company's AI assistant: "What is our net revenue retention this quarter?"

The agent connects to your Snowflake MCP server, inspects the table schemas, writes a SQL query joining subscriptions to accounts, and returns 97%.

The real answer is 84%. The agent excluded trial downgrades incorrectly, used the wrong cohort window, and forgot to filter out internal accounts. It returned a confident, wrong number — and nobody in the room knew to question it until the board meeting two weeks later.

That is the MCP server for data problem in one paragraph. This guide explains what an MCP server is, why the naive wiring to a warehouse falls short for analytics, what the full agentic data stack looks like when it is built correctly, and how to evaluate options for your team.

What is the Model Context Protocol?#

To understand what an MCP server for data is, you need to understand the protocol it runs on.

The Model Context Protocol (MCP) is an open standard, originally published by Anthropic in November 2024, that defines how AI models connect to external tools and data sources. Before MCP, every AI integration was custom-built: if you wanted Claude to query Slack, you wrote a Claude-specific integration. If you then wanted GPT to do the same, you wrote it again. N models times M tools equaled N×M custom integrations.

MCP eliminates that duplication. It defines a standard interface — a shared language for AI clients and external services — so any MCP-compatible AI model can use any MCP server without a custom adapter. Build the server once; any client that speaks MCP can use it.

The protocol uses a client-server architecture:

• MCP client — the AI model or agent (Claude, Cursor, a custom agent built on the Claude API)
• MCP server — a process that exposes capabilities the client can call
• Transport layer — how they communicate (typically stdio for local servers or HTTP with Server-Sent Events for hosted ones)

The server exposes three types of things:

1. Tools — functions the AI can call (run a query, fetch a metric, trigger an action)
2. Resources — read-only data the AI can access (a file, a database record, a metric definition)
3. Prompts — reusable prompt templates the AI can invoke

When a user asks "what is our churn rate this month?", the AI client queries the MCP server's tool list, finds a tool called get_metric, calls it with { metric: "churn_rate", period: "this_month" }, and returns the result — without the user writing SQL or knowing anything about the underlying data system.

What is an MCP server?#

An MCP server is any process that implements the Model Context Protocol and exposes tools, resources, or prompts for an AI client to use.

MCP servers exist for everything now: GitHub, Slack, Jira, Atlassian, Figma, Notion, Postgres, Snowflake, Datadog. The model is simple: instead of an AI model needing a custom plugin for every external system, you run an MCP server in front of each system and any MCP-compatible AI client can use it.

In practice, an MCP server is usually a small process running locally (via stdio) or a hosted endpoint (via HTTP). You configure your AI client to point at it. From that point, the AI can use every tool the server exposes, in every conversation, without any custom code on the AI side.

Why data teams need an MCP server specifically#

Connecting an AI agent to your data sounds straightforward. Run a Postgres MCP server. Point Claude at it. Done.

The problem is what that actually does. A Postgres MCP server — or a Snowflake MCP server, or a BigQuery MCP server — exposes your raw database schemas: tables, columns, foreign keys. The AI agent reads those schemas and writes SQL to answer questions.

That is text-to-SQL. And text-to-SQL has a well-known failure mode: it works for simple lookups ("how many customers signed up in May?") and breaks on anything with business logic attached ("what is our net revenue retention for the enterprise cohort, excluding trials and internal accounts, using a 12-month lookback?").

The agent does not know:

• That subscriptions has three different status codes and two of them should be excluded from NRR
• That "enterprise" in your business means accounts with arr_band = 'enterprise' AND segment != 'startup_program'
• That NRR should use the MRR at the start of the cohort window, not the current MRR
• That internal accounts have domain ILIKE '%yourcompany%' and need to be filtered out

It guesses. Sometimes it guesses correctly. More often it returns a plausible-looking number that is quietly wrong, and there is no audit trail to catch it.

This is why a raw warehouse MCP server is insufficient for business analytics. You do not need an AI that can write SQL. You need an AI that can retrieve certified, pre-defined business metrics — the same ones every other tool in your company returns. And just as data readiness determines whether a machine learning model produces trustworthy predictions, the cleanliness and governance of the data behind an MCP server determine whether your agent returns trustworthy answers.

The missing piece is the semantic layer.

Vendor-bound MCPs and why they fall short#

The MCP servers shipping from data infrastructure vendors today are warehouse-bound: the Snowflake MCP, the Postgres MCP, the BigQuery MCP. They work by exposing the table schemas of a specific warehouse so an AI agent can query it directly.

These are useful for some things — a data engineer using Claude to explore an unfamiliar schema, a developer asking questions about a specific table's structure. But they are not the right tool for business analytics, for three reasons:

1. They expose raw tables, not governed metrics.

Your subscriptions table does not define MRR. Your accounts table does not define customer health score. Those definitions live in the heads of your analysts and the comment blocks of SQL files nobody maintains. A warehouse MCP server gives the AI access to the ingredients, not the recipe.

2. They are tied to one warehouse.

A Snowflake MCP server only works if your data is in Snowflake. If your CRM data is in Postgres, your billing in BigQuery, and your product events in Redshift, you need a separate MCP server for each — and none of them share a common definition of "active customer."

3. They do not enforce business rules or access controls.

The semantic layer is where you define once that a field is PII, that a dimension requires row-level security, that certain metrics are available only to the finance team. A warehouse MCP bypasses all of that: the AI agent queries whatever it wants, against whatever tables it can reach.

The semantic layer is the missing piece#

The fix is to put a semantic layer between your warehouse and your MCP server.

A semantic layer defines your business metrics — revenue, churn, NRR, DAU, health score — exactly once, as governed, version-controlled code. Instead of every dashboard and AI agent writing its own SQL, they all query the semantic layer by metric name and get the same, certified answer back.

When an AI agent queries an MCP server backed by a semantic layer, it does not write SQL. It asks for a metric by name:

get_metric(metric="net_revenue_retention", period="this_quarter", segment="enterprise")

The semantic layer resolves that to the correct SQL — the one that everyone has agreed on, with the right joins, the right filters, and the right cohort logic — runs it, and returns the number. The agent reports 84%. The real answer is 84%.

This is what an MCP server for data means when it is built correctly: not a thin SQL-generation layer on top of raw tables, but a governed interface to a semantic model that your whole organization trusts.

For a deeper look at what a semantic layer is and why AI agents need one, see our guide: What Is a Semantic Layer? (And Why Your AI Agents Need One).

The anatomy of an agentic data stack#

A properly wired agentic data stack has four layers. Each one is necessary. Skip one and the whole thing degrades.

Layer 1: Ingestion#

Data arrives from your source systems — your CRM (HubSpot, Salesforce), your billing platform (Stripe, Chargebee), your product events (Segment, Mixpanel), your support system (Zendesk, Intercom). Ingestion pipelines pull that data on a schedule, or in real time, and land it in your warehouse.

Common tooling at this layer: Fivetran, Airbyte, Meltano, or custom ETL scripts. The output is raw tables that mirror the source: hubspot_contacts, stripe_subscriptions, segment_events.

The gap without governance: raw tables have no shared business meaning. MRR in Stripe means the monthly charge. MRR in your board deck means something slightly different after you back out refunds, trials, and internal accounts. That gap lives entirely at this layer if you do not address it further upstream.

Layer 2: Warehouse#

The warehouse is where raw tables are stored, transformed, and made queryable. In most modern stacks this is Snowflake, BigQuery, or Redshift. Transformation happens here — the Bronze/Silver/Gold pattern, or the staging/marts model from dbt — turning raw source data into cleaner, business-ready tables. This curated Gold layer is the foundation of any modern data strategy: governed, trusted tables that the layers above can build on.

But cleaned tables are not the same as governed metrics. Even a Gold-layer dim_customers table is still a table. It does not know what "active customer" means to your business. That definition still lives in the next layer.

Layer 3: Semantic model#

The semantic model is where your business vocabulary is defined: entities (customer, subscription, opportunity), metrics (MRR, NRR, churn rate, DAU, pipeline coverage), dimensions (segment, region, plan tier, cohort), and the relationships between them.

This is the layer that makes the whole stack trustworthy. When you define net_revenue_retention here — exactly once, with the right logic, right filters, and right cohort window — every tool that reads it returns the same number. The board dashboard, the RevOps Slack bot, the AI agent your sales rep uses: all the same.

Common tooling: Cube.dev, dbt Semantic Layer, AtScale. The semantic model is usually code, version-controlled alongside your data transformations.

This layer is where most agentic data stacks break. Teams connect an AI agent to the warehouse (Layer 2) and skip this layer entirely. The agent writes SQL, the SQL is sometimes wrong, trust degrades, and the "AI data assistant" initiative gets quietly shelved.

Layer 4: MCP server#

The MCP server is the consumption interface — the API that sits on top of your semantic model and exposes it to AI agents and other consumers.

When it is backed by a proper semantic model, the MCP server exposes tools like:

• get_metric(name, period, filters) — return a single metric for a time window
• list_metrics() — enumerate all available metrics with their descriptions
• get_dimension_values(dimension, filters) — return valid values for a dimension
• run_query(measures, dimensions, filters, time_range) — compose a governed multi-metric query

The AI agent calls these tools. It never touches raw SQL. Every query it runs goes through the semantic model's certified logic. Governance, access control, and business-rule alignment come for free, because they are baked into the semantic model, not re-implemented in the agent.

This is the layer RevOS ships as part of its bundled platform: a hosted MCP server endpoint sitting on top of a Cube-based semantic model, ready for any MCP client to connect to.

For data engineers: setting up an MCP server for your data stack#

There are two paths to an MCP server for data.

Option 1: Build it yourself#

If you have an existing semantic layer (Cube, dbt Semantic Layer, AtScale), you can build an MCP server on top of it using the open MCP SDK.

The rough steps:

1. Set up an MCP server using the official TypeScript or Python SDK from Anthropic.
2. Implement tool handlers that call your semantic layer's API — typically a REST or GraphQL endpoint from Cube, or a dbt CLI call.
3. Register your tools with descriptions that AI agents can use to route queries correctly.
4. Configure your MCP clients (Claude Desktop config, Cursor settings) to point at your server.
5. Add authentication — the MCP server should validate that the calling agent is acting on behalf of an authorized user and enforce that user's access rules.

This is a few hundred lines of code for a basic implementation. A production-ready version that handles auth, streaming, error reporting, and multi-user access is a multi-week project.

Option 2: Use a bundled platform#

If you do not have an existing semantic layer, or you want to skip the multi-week build, a bundled platform like RevOS ships the entire stack — ingestion, warehouse, semantic model, and MCP server — as a single managed service.

The RevOS CLI scaffolds the semantic model from your connected data sources:

npm install -g revos
revos init
revos connect --source hubspot --source stripe --source segment
revos model build   # AI agent drafts the semantic model from your data
revos serve         # starts the MCP server endpoint

From that point, you add the RevOS MCP server endpoint to your Claude or Cursor config and your AI assistant can query your semantic model immediately — without writing SQL, without building infrastructure, and with the access controls you define in the semantic model enforced on every query.

The tradeoffs are the same as any managed-vs-build decision: you trade flexibility for speed, and you accept the vendor's opinionated stack (BigQuery + Cube under the hood) in exchange for not having to assemble it yourself.

For RevOps and business users: what you can actually do with an MCP server for data#

The developer story above describes how to build it. Here is what it unlocks for the people who use the data.

Before an MCP server for data:

• A RevOps analyst wants to know which enterprise accounts have not expanded in the last 90 days. They open a dashboard, realize the filter they need is not there, file a ticket for a data team analyst, wait three days, get the data, import it to a spreadsheet, do the analysis.
• A VP of Sales wants to know pipeline coverage for the next quarter by segment. They ask their ops analyst, who runs a Salesforce report, a HubSpot extract, and an Excel model to reconcile the two.
• A customer success manager wants to know which accounts are showing early churn signals. They log into the BI tool, find the customer health score dashboard, manually cross-reference it against their account list.

After an MCP server for data connected to a semantic model:

Every one of those questions becomes a natural-language query in the tools those people already use:

"Which enterprise accounts have had no expansion in the last 90 days 
and a health score below 70?"

"What is pipeline coverage for next quarter, broken down by segment 
and compared to the same period last year?"

"Show me the 10 accounts with the biggest recent drop in product 
engagement, sorted by ARR."

The AI agent calls the MCP server, the MCP server calls the semantic model, the semantic model runs the certified SQL, and the answer comes back in seconds — the same answer the BI dashboard would return, because it is the same metric definition.

This is what "AI agents that can answer business questions about your data" actually means in practice. Not a demo that works on a cleaned-up sample. A production system that answers the questions your RevOps team asks every day, against live data, with the governance your finance team requires.

Common failure modes to watch for#

Even with the right architecture, there are a few ways MCP-for-data implementations go wrong in practice.

Failing to version-control the semantic model. If metric definitions live in a hosted UI and not in code, you lose audit trails. When the NRR number changes, you cannot tell whether it changed because the underlying data changed or because someone edited the metric definition. Version-control your semantic model the same way you version-control your application code.

Skipping row-level security. An AI agent that can answer any question for any user is a data breach waiting to happen. Define access rules at the semantic model layer — which dimensions and metrics each role can see, which row filters apply — and verify that the MCP server passes the calling user's identity through to the semantic layer to enforce them.

Not auditing the tool descriptions. The AI agent chooses which MCP tool to call based on the natural-language descriptions you give each tool. If a tool description is vague or misleading, the agent will misroute queries and return wrong results. Treat tool descriptions as carefully as you treat metric definitions.

Connecting to raw tables as a fallback. Some teams set up a semantic MCP server and also leave a raw warehouse MCP server running "for edge cases." Every query that falls through to raw tables is a query that bypasses governance. If a metric is not in the semantic model, add it to the semantic model — do not route around it.

How to evaluate an MCP server for your data#

When comparing options, these are the questions that matter:

The answers that point to a well-designed system: exposes governed metrics, warehouse-agnostic, passes user identity through, works with any MCP client, semantic model is code, managed or well-documented self-hosted.

The open white space: semantic MCP for business analytics#

The current MCP landscape is dominated by vendor-bound servers: GitHub MCP (9,900/mo search volume), AWS MCP (4,400/mo), Snowflake MCP (1,000/mo), Postgres MCP (1,000/mo). Every major infrastructure vendor has shipped or is shipping an MCP server that exposes their specific system.

What does not exist yet — at any meaningful scale — is an MCP server for governed business analytics: one that sits in front of a semantic model and exposes certified revenue metrics, customer health scores, and pipeline coverage numbers to any AI agent, regardless of which warehouse stores the raw data.

That is the gap RevOS is built to fill: the full agentic data stack — ingestion, warehouse, semantic model, and MCP server — as a single managed bundle, so the AI agent your RevOps lead uses on Monday morning returns the same NRR number your board slides showed on Friday.

Where to go from here#

Two paths depending on where you are:

If you are a data engineer who wants to wire an AI agent to your existing semantic layer, the RevOS CLI connects to Cube-backed models and exposes an MCP server in minutes. Start with npm install -g revos and follow the quickstart.

If you are a RevOps lead or VP who wants AI-powered answers on your revenue data without a multi-quarter data engineering project, talk to a RevOS expert — we can assess your current data stack and show you what the MCP-ready version looks like for your specific CRM, billing, and product event sources.

The agentic data stack is not complicated once you see the four layers clearly. The hard part — the one most teams get wrong — is not forgetting the semantic model in the middle.

Read more about revenue operations, growth strategies, and metrics in our blog and follow us on LinkedIn and Youtube.