MCP Is the Authority on Your Data

The pitch goes like this: connect a model to the warehouse, and anyone in the company can ask questions in plain English. No more waiting on the data team. No more dashboards nobody opens. Sales asks for churn by region, and the model writes the SQL.

It’s half right. The interface is right. Plain English is the correct front door for people who will never learn a join. The part that’s wrong is what sits behind the door. A model with raw warehouse access does not know what your company means by “churn.” It will find a table with a plausible name, pick a plausible column, and return a confident number. For a less technical user, that number is the answer. They have no way to tell that it counted trial accounts, or used the deprecated customers_v2 table, or summed revenue in two currencies.

The fix is to make the MCP server the authority: the place where the company’s definitions, permissions, and sources of truth live, so the model works from reviewed definitions.

The Problem Is Meaning

Text-to-SQL demos fail in a specific way. The query runs. The SQL is valid. The result is wrong because the question had a business definition the schema doesn’t encode.

Every warehouse I’ve seen has the same features. Three tables that each look like the customer table. A status column with values that changed meaning in a migration two years ago. Revenue that is gross in one place and net in another. The people who know these things are analysts, and they carry it in their heads. When an analyst writes the query, that knowledge comes along for free. When the model writes it, the knowledge is gone.

Technical users catch some of this. They read the SQL, notice the wrong table, and push back. Non-technical users can’t. They’re exactly the audience the whole project was built for, and they’re the least equipped to check the output. That asymmetry is the design problem.

Put the Definitions in the Tools

An MCP server can carry the analyst’s head. Instead of one run_sql tool, it exposes the things the business actually asks about.

• get_metric(name, filters, period) that only knows approved metrics, each with one definition.
• list_metrics() that returns those definitions in plain language, so the model can explain what “active customer” means before it reports a number.
• describe_dataset(name) that says what a dataset is for, how fresh it is, and what it should never be used for.

The model still does the translation from English. It just translates into “churn, by region, last quarter” instead of a forty-line query against tables it has never seen. The definition of churn is code someone reviewed. It gives the same answer on Tuesday as on Monday, and it gives the same answer to finance and to sales.

This is the same lesson as the model has to read the manual, pushed one step further. The manual teaches the model how to query. Here the server removes most of the queries the model shouldn’t be writing at all.

Raw SQL can still exist. Give it to the analysts, behind a separate tool with a separate permission. The people who can audit a query get that tool.

Access Belongs at the Server

Once the server is the front door, it is also the right place for access control. The user connects as themselves. The server knows who they are and what they’re allowed to see, and it enforces that on every call. The regional manager sees their region. HR data never reaches the sales team’s model, because the tool that would return it isn’t in their tool list.

The alternative is putting permissions in the prompt, and rules are not controls. A system prompt that says “don’t show salary data” is a request. A tool that doesn’t return salary data to this user is a control. For a dataset that matters, only the second one counts.

The argument in MCP is the OAuth layer applies here. Identity flows from the user to the server, and the server makes the call. No shared service account quietly seeing everything.

Every Answer Carries Its Source

The last job of the authority is provenance. Every result the server returns should say where it came from: which metric definition, which dataset, as of when. The model can pass that through to the user in one sentence. “Churn was 4.1% last quarter, using the finance definition, from data refreshed this morning.”

That sentence does more for trust than any accuracy benchmark. A non-technical user can’t verify SQL, but they can read a definition and a date. When the number surprises them, they have something to ask about. When two people get different numbers, they can see they asked different questions.

It also makes the system correctable. If the definition is wrong, you fix it in one place and every future answer changes. If the model was writing its own queries, there’s nothing to fix. There’s just a model that guessed differently this time.

What This Costs

Someone has to write the definitions down. That’s the real project, and it is mostly not an AI project. It’s the semantic layer work data teams have been asking to do for years, now with a reason to get funded. In my experience the first ten metrics cover most of the questions people actually ask. Start there, ship it to one team, and watch which questions fall through to “I can’t answer that.” Those are your next ten.

The model is a good translator and a poor authority.