The tax that scales with success
This fintech had a genuinely good data platform. Properly modeled and documented, with a dbt, BigQuery, and Metabase stack that most companies would envy. The problem: the data team built it so well that everyone wanted to use it, and “using it” meant asking the data team for queries.
The head of data described it as “running a free SQL consulting service for the company.” Product managers wanted cohort breakdowns. Marketing wanted campaign attribution. Finance wanted custom reconciliation reports. All reasonable requests, all requiring a data engineer to write a query.
The data team had five people. They were spending roughly two days per week each responding to these requests. That is 40% of a team that could have been modeling new data sources, improving pipeline reliability, or building the dashboards that would have made the ad-hoc requests unnecessary.
What an MCP server actually solved here
The request was: “Can we give our non-technical team a way to ask the data platform questions in plain English?”
The obvious answer is to use a text-to-SQL tool. We evaluated five of them. The problem: generic text-to-SQL tools do not know your business logic. They do not know that “active users” at this company means something very specific, a user who has completed at least one transaction in the last 30 days, excluding test accounts, converted to the reporting currency at the week’s opening exchange rate. That definition is not in the schema. It lives in the data team’s heads.
What we built instead was an MCP server that exposes the data platform’s pre-built, business-logic-correct metrics as tools. Not raw SQL access, but curated, tested, documented tools.
The server has 34 tools:
get_active_users(start_date, end_date, segment?), returns the metric with the correct definition appliedget_cohort_retention(cohort_month, weeks_out), uses the retention model the data team actually trustsget_revenue_by_channel(period, breakdown?), applies the attribution model correctlyget_churn_signals(threshold_days?), runs the churn model with parameters
Each tool has documentation written by the data team. Claude reads that documentation before constructing its answer, so it explains results using the same definitions the data team uses. A human analyst reviews any query that returns results marked as anomalous before those numbers are shared broadly.
The 3-week build
Week 1: Audit the existing dbt models and Metabase dashboards to identify the 40 most-requested query types. Interview the data team about which questions are safe to automate (deterministic, well-defined outputs) vs. which need human judgment (anything involving trend interpretation or causal inference).
Week 2: Build the MCP server in TypeScript using @modelcontextprotocol/sdk. Each tool maps to a parameterized BigQuery query that runs through the dbt-generated views. Authentication uses the company’s existing Google Cloud IAM. Deployed on Cloud Run with a Cloudflare Access tunnel so internal Claude Code sessions can reach it.
Week 3: Testing with real users, documentation passes, and a Slack integration that lets teams query the data platform from a dedicated #data-ask channel using a simple slash command that routes to Claude + the MCP server.
What changed
200-plus internal queries per day arrived in the first month of deployment. The data team’s “incoming requests” Slack channel, previously the most active channel in the company, dropped to near zero for routine queries.
The data team spent the reclaimed time rebuilding their dbt project structure, which had accumulated technical debt over two years. They also shipped three new dashboard areas that had been on the backlog for six months.
Humans remain in the loop for anything involving forward projections, causal claims (“did this campaign cause X?”), or novel metric definitions. The MCP server returns an explicit message when a query falls outside its scope: “This question requires custom analysis. Please post in #data-team.”
The unexpected benefit
Non-technical staff started asking better questions. Before the system, requests arrived as “I need a report on users.” With the tool available, they would investigate first, then ask something specific: “I checked active users for Q1 and got X, but I am trying to understand why it dipped in week 8, can someone look at that?” That is a much more specific and solvable request.
The data team called it “the best change to our working dynamic in two years.”
Tech used
@modelcontextprotocol/sdk (TypeScript) · Google BigQuery · dbt · Cloudflare Access · Cloud Run · Slack API · Claude Sonnet 4.6 (via Claude Code for internal users)