How to Build an MCP Server for AI Data Analytics

Five years ago, asking your database a question in plain English and getting a chart back sounded like a demo trick. Now, it’s a common, repeatable pattern. One of the ways to do that is via the Model Context Protocol (MCP). MCP gives any large language model a standard way to reach your analytics data, run governed queries, and return results you can trust.

This guide shows how to build an MCP server on top of Metabase, the open-source business intelligence platform. You will get the concepts, a step-by-step setup, a worked natural-language query, a comparison with other open-source options, and best practices for querying. The framing throughout is practical: connect any LLM to your data through a governed semantic layer, without abandoning the permissions and definitions your team already relies on.

What is Model Context Protocol (MCP)?

The Model Context Protocol is an open standard for communication between large language models and external applications or data sources. Instead of hand-coding a one-off integration every time you want an LLM to reach a database, an API, or a file store, MCP defines a consistent contract that both sides speak.

Mixpanel describes MCP as a universal “handshake” that makes context exchange reliable and reusable [1]. Rather than treating an AI model as a black box, MCP creates a controlled framework where models can request and receive data securely, consistently, and in a format they can act on. The same post frames it as a translator sitting between complex data and an AI assistant, turning a question like “what was revenue last quarter” into a structured request the data layer understands.

Teradata makes a related point: MCP is an open standard designed to let AI systems talk to the outside world in a trusted, governed way [2]. By standardizing how an LLM interacts with external tools, it lets developers focus on agent behavior instead of rebuilding plumbing for every new data source. That standardization is why major analytics platforms have adopted it. Google offers a Google Analytics MCP server that connects your Analytics data to an LLM like Gemini, and Mixpanel published its own guidance on querying analytics data through the protocol [3].

How MCP connects LLMs to your data

MCP works through a three-part architecture:

• Data source: your analytics database or warehouse, for example PostgreSQL, BigQuery, Snowflake, or Databricks.
• MCP server: the bridge that exposes tools (query, schema inspection, dashboard access) and enforces access rules.
• LLM: the model doing the reasoning, such as Claude or Gemini, invoked through a chat interface or an agent.

A question travels from the LLM to the MCP server, which translates it into a valid query against the data source, runs it under the correct permissions, and passes structured results back for the model to interpret and visualize. In Metabase, that middle layer is more than a passthrough. An active AI connection turns your instance into a source of governed context, which is where the Metabot AI capabilities and the MCP server both draw their power.

The value of the standard is that the same server works for any compliant client. Build the bridge once, and you can swap the LLM on the other end without rewiring the data side.

Why Use an MCP Server for Your Data Analytics?

The core problem MCP solves is the bottleneck between a question and an answer. Traditionally you either click through dashboards hunting for the right view or file a request and wait for the data team to write SQL. As Mixpanel puts it, MCP eliminates that trade-off: you can ask complex questions in natural language and get actionable insights instantly.

The benefit looks different depending on who is asking.

For data teams

An MCP server backed by a governed model enforces access at the source. The LLM only queries pre-approved metrics and models, so a “revenue” question resolves to the one definition your team blessed rather than an ad-hoc calculation someone invented. In Metabase, the server inherits the logged-in user’s permissions and grounds answers in your semantic layer, which keeps data consistent and reduces the flood of one-off SQL requests. This is where ai powered bi through mcp earns its keep: fewer tickets, one source of truth, and an audit trail through the query builder and SQL editor.

For product managers and business users

Non-technical users get instant answers without waiting on anyone. “How did signups trend over the past 30 days by plan?” returns a chart, not a queue position. The speed matters as much as the self-service. When open source mcp servers for data exploration sit on top of a well-defined model, a PM can investigate a hunch during a meeting instead of after it.

For executives

Leadership gets genuine data democratization. Instead of commissioning a report and waiting days, an executive can self-serve a complex question and drill into it, making faster decisions with the confidence that the numbers match the definitions the business agreed on. The governance underneath means self-service does not turn into a room full of conflicting spreadsheets.

Building Your MCP Server with Metabase

Metabase is an open-source BI platform used by more than 100,000 companies to query data in natural language, build dashboards, and explore insights without writing code. It connects to 20+ data sources and runs either self-hosted or in the cloud. Those properties make it a strong foundation for an MCP server: broad connectivity, an existing permission model, and a built-in semantic layer.

An active Metabase AI connection does more than switch on the Metabot assistant. According to the AI settings documentation, one active connection provides Metabot, an MCP server, inline SQL generation and debugging. You do not build the MCP server from scratch, you enable and configure it.

Metabase’s connector list covers most stacks. Official connectors, available in all editions, include PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle, SQLite, BigQuery, Amazon Redshift, Amazon Athena, Snowflake, Databricks, MongoDB, ClickHouse, Druid, Presto, Spark, Starburst, and Vertica, plus built-in CSV Uploads and Google Sheets that need no external database or ETL pipeline. Self-hosted deployments can add community connectors for platforms like DuckDB, StarRocks, Materialize, Dremio, Teradata, and Firebolt. Whatever the LLM asks, the query resolves against the source you already trust.

The steps below follow the same shape as common MCP tutorials, adapted to Metabase. If you want a from-scratch reference for building a custom Python server instead, the Towards Data Science six-step tutorial and this walkthrough for LLM agents are useful companions [4] [5].

Step 1: Prerequisites and Environment Setup

Before enabling the server, make sure you have:

• A running Metabase instance, either Metabase Cloud or a self-hosted deployment. AI SQL-generation features integrate with self-hosted Metabase.
• Admin access to the instance, since AI configuration lives in the Admin panel.
• At least one connected database. If you are starting fresh, connect a source such as PostgreSQL or BigQuery so the server has something to query.
• An AI provider API key if you self-host. Metabase supports a Bring Your Own Model approach, and current support is limited to Anthropic models for the self-hosted key option. The Metabot offering from the Metabase Store is cloud-only.

If you plan to build a custom MCP server around Metabase’s APIs rather than use the built-in one, most tutorials standardize on uv as the package manager and the MCP Python SDK. A typical setup initializes a project directory, creates a virtual environment, and installs the mcp[cli] and httpx packages before writing a server file, as shown in the Towards Data Science guide [4].

Step 2: Configuring Metabase AI Connection

AI settings live in the Admin panel under AI > Connection Settings. Open that page and add your AI provider connection.

• On Metabase Cloud, add the Metabot AI add-on, which handles the model connection for you.
• Self-hosting, choose the Bring Your Own API Key option and supply your Anthropic key. This connects Metabase to your own provider and gives you cost control over model usage.

Once the connection is active, you can manage Metabot separately under Admin > AI > Metabot, where it can be enabled or disabled per instance. Metabot is enabled by default. For customer-facing deployments, embedded Metabot can be toggled independently and affects both full-app and modular embeds. Activating the AI connection is what makes the MCP server available alongside the assistant.

Step 3: Running the MCP Server

With an active AI connection, the MCP server is exposed by your Metabase instance. Point your MCP client at it and authenticate with credentials tied to a Metabase user account. Because the server impersonates the logged-in user’s permissions, the queries an LLM can run are exactly the ones that user is allowed to run, no more.

MCP servers generally support two transport types. As explained in this MCP tutorial, you define your tools and resources, then run the server over either standard IO (stdio) or HTTP [6]. A stdio transport suits a local setup where the LLM client runs on the same machine. HTTP suits a remote deployment where multiple clients connect over the network. Cloudflare’s write-up on remote MCP servers covers the authorization and remote transport handling that remote deployments need [7]. Choose the transport that matches where your LLM client lives.

The tools the server exposes cover the analytics workflow: schema inspection so the model can see available tables and fields, query execution against connected databases, and access to saved questions and dashboards. Those tools are what let the LLM reason about your data structure before it writes a query.

Step 4: A Worked Example: Querying Data with Natural Language

Suppose an analyst connects Claude to a Metabase instance backed by a PostgreSQL orders database and asks:

“Show me total revenue by month for the past 12 months, and chart it as a line graph.”

Here is what happens through the pipeline:

1. The LLM calls the schema-inspection tool and sees an orders table with created_at and amount columns, plus a governed Total Revenue metric from your semantic layer.
2. It maps the request to a query builder expression: sum the revenue metric, grouped by month, filtered to the last 12 months. Metabot creates queries through natural language that map to standard query builder expressions, including filtering, grouping, and aggregations.
3. The MCP server runs the query under the analyst’s permissions and returns rows.
4. The results come back as a line chart with interactive tooltips. Metabot converts natural-language results into visualizations such as tables, charts, and maps.

Because the request resolved through the Total Revenue metric rather than a raw SUM(amount), the answer matches what every dashboard in the company reports. If the analyst wanted to inspect or tweak the logic, Metabot can generate and edit SQL in the native editor and even fix SQL errors, and it indicates which models and metrics it referenced so the work is auditable.

Leveraging Metabase’s Semantic Layer for Governed AI

The MCP server is only as good as the context it feeds the model. Point an LLM at raw tables and it guesses at what “active user” or “revenue” means. Point it at a semantic layer and it uses your definitions. Metabot leverages your semantic layer and grounds answers in governed data models, metrics, and business definitions, which is the difference between a plausible answer and a correct one.

Metabase builds this layer in Data Studio, a workspace for curating a semantic layer and defining shared metrics. Two building blocks do most of the work:

• Models: curated datasets with clear names and descriptions that simplify querying and AI interpretation. They act as reliable starting points for questions and dashboards.
• Metrics: standardized, reusable calculations such as total revenue, conversion rate, and active users. Defined once, they return consistent results across every question, dashboard, and Metabot interaction.

Data Studio also holds a Glossary that defines business terms for both people and AI, a Dependency Graph that maps how content connects so you can foresee the impact of changes, and Transforms that clean or pre-aggregate data in SQL or Python and write results back to the database as reusable sources. The foundational features are available in the open-source edition, with advanced capabilities like Python transforms and lineage on Pro and Enterprise plans. Metabase notes the semantic layer matters most for organizations with many tables or multiple sources, and is less pressing below roughly 50 tables.

Metabase as a headless BI platform and LookML alternative

Because these definitions live behind an API and the MCP server, Metabase functions as a headless bi platform: the governed model can feed any front end, embedded product, or LLM. That positions it as a practical LookML alternative. Where LookML requires you to define a model in a proprietary language, Metabase lets analysts define models and metrics through a no-code or low-code interface and then exposes them anywhere through the API, the React SDK, or MCP. It fits the open source headless analytics pattern without forcing everything into code.

Semantic layer vs metrics layer

The semantic layer vs metrics layer distinction trips people up. A metrics layer is narrow: it defines standardized calculations, the “how do we compute revenue” part. A semantic layer is broader: it includes those metrics plus models, relationships, and business terminology, a shared map of business logic. Metabase combines both in Data Studio. Metrics give you the consistent calculations, models and the glossary give you the surrounding context, and together they hand the LLM everything it needs to answer accurately.

Contrast this with the metrics as code for business intelligence approach. Holistics positions itself as an AI analytics platform with a programmable semantic layer, where metrics are defined once in its AODL syntax and the entire model is written in code files checked into Git and plugged into AI agents as context [8]. That approach appeals to engineering-led teams comfortable managing analytics as code. Metabase reaches the same governed outcome through a more accessible interface, so analysts who do not write config files can still build and maintain the layer that grounds the AI.

Comparing Open-Source MCP Servers for Data Integration

Several platforms now expose their data through MCP, with different trade-offs on hosting, semantic layer, and model support. The table below compares the main options for teams evaluating the best tools for mcp data integration.

Microsoft’s Power BI MCP documentation describes two servers [9]. The remote server needs no installation, runs on Fabric, uses Streamable HTTP transport with OAuth via Microsoft Entra ID, and generates schema-aware DAX through Copilot. The local server requires VS Code or Node.js 20.0+, uses stdio transport, and supports bulk operations on hundreds of objects with transaction support and natural-language model editing. Both are in Public Preview. The catch for open source teams is that Power BI ties you to the Microsoft stack.

Superset and Lightdash represent the open-source alternatives. Lightdash’s dbt-native model appeals to teams already managing metrics in dbt, though it inherits dbt’s setup requirements. Metabase’s edge for open source headless analytics is the combination of a built-in MCP server, the widest set of database connectors, and a semantic layer that non-engineers can build and maintain.

Best Practices for Querying Your MCP Server

Good results depend on good prompts. These practices, drawn in part from Mixpanel’s guidance, consistently improve the answers an LLM returns through MCP [1].

• Be specific with time ranges. Say “the past 30 days” or “Q1 2026” instead of “recently.” Vague windows produce vague queries.
• Ask for the visualization you want. If you need a bar chart or a line graph, request it explicitly rather than hoping the model picks the right format.
• Break complex questions into smaller queries. Instead of one sprawling prompt, ask for the trend first, then drill into the outlier. Smaller steps are easier for the model to get right and easier for you to verify.
• Give the model context. Metabase returns better answers when the prompt references the relevant tables, fields, or existing metrics, and clear English prompts outperform terse ones.
• Cache frequently used data on the server. Caching common results reduces latency and load on your database for repeated questions.
• Reuse existing logic. Metabot surfaces existing dashboards and saved questions, so lean on those rather than regenerating a definition the team already trusts.

Frequently Asked Questions

What is the Model Context Protocol (MCP)?

MCP is an open standard that lets large language models communicate with external applications and data sources using structured context. It replaces one-off custom integrations with a consistent contract, so an LLM can request and receive data securely and reliably. Mixpanel describes it as a universal handshake between complex data and an AI assistant.

How does an MCP server improve data security for AI queries?

A well-built MCP server enforces access at the data layer rather than trusting the model to behave. In Metabase, the server impersonates the logged-in user’s permissions, so an LLM can only query what that user is allowed to see. Metabot also does not ingest or move data outside your environment, which keeps sensitive data in place. Admins can also audit MCP client activity in Admin > AI > MCP > Authorizations, which logs every OAuth client registration and whether it was approved or denied.

What’s the difference between a semantic layer and a metrics layer?

A metrics layer defines standardized calculations, the agreed way to compute things like revenue or active users. A semantic layer is broader, adding models, relationships, and business terminology on top of those metrics to form a shared map of business logic. Metabase combines both in Data Studio, so an LLM gets consistent calculations and the surrounding context.

Can I connect my own LLM to a Metabase MCP server?

Yes. Because MCP is an open standard, any MCP-compatible client can connect to the server that a Metabase AI connection exposes. For the self-hosted Bring Your Own Model option, Metabase currently supports Anthropic models for its own AI features, while the Metabot add-on from the Metabase Store is cloud-only.

Can AI agents manage Metabase beyond querying data, like dashboards, transforms, and permissions?

The MCP server is primarily for querying and creating analytics artifacts, like dashboards, questions, and metrics. For broader, scriptable access across any Metabase entity, including instance-level stuff like transforms and permissions, Metabase ships a CLI, built on the same underlying API. Think conversational tool-calling (MCP for chat-based agents) vs. scriptable automation (CLI for coding agents or CI pipelines).

Which data sources are supported by the Metabase MCP server?

The server can query any source connected to your Metabase instance. Official connectors, available in all editions, include PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite, BigQuery, Redshift, Athena, Snowflake, Databricks, MongoDB, ClickHouse, Druid, Presto, Spark, Starburst, and Vertica, plus CSV Uploads and Google Sheets. Self-hosted deployments can add community connectors such as DuckDB, StarRocks, Materialize, and Teradata.

Is Metabase’s MCP server open source?

Metabase is an open-source BI platform, and its foundational features, including core semantic layer capabilities, are available in the open-source edition. The MCP server becomes available when you enable an active AI connection, which also unlocks Metabot and inline SQL generation. Advanced Data Studio features are reserved for Pro and Enterprise plans.