MCP Is the New ODBC: Connecting AI Agents to Enterprise Data
For decades we argued about how BI tools should connect to data. AI agents bring the same question back, with higher stakes. The Model Context Protocol is the most promising answer I've seen.
Years ago, as a consultant, I spent a surprising amount of time on one unglamorous question: how should the dashboard connect to the data? Live or extract? Native connector or generic ODBC? Custom SQL or a governed view? Those choices quietly decided whether a deployment was fast, trusted and maintainable, or none of the above.
AI agents bring that question back. And the stakes are higher, because an agent doesn't just display data. It reasons over it and acts on it.
The integration problem, again
Every AI tool wants your data, and every data source has its own API. Without a standard, you get the familiar mess: one bespoke integration per tool per source, each with its own auth, its own definitions and its own blind spots. It's the web data connector problem all over again.
The Model Context Protocol (MCP) is an open standard for exposing tools and data to AI applications. Build an MCP server once in front of a data source, and any MCP-compatible client (Claude, Gemini-based agents, IDE assistants, your own apps) can use it.
If that sounds like what ODBC did for databases and BI tools, that's exactly the point.
What I've learned building on MCP
I've built agents on top of MCP servers for both a cloud data warehouse (Snowflake) and a workforce analytics platform (Visier). A few lessons have held up across both.
1. Expose questions, not tables
The temptation is to give the agent one giant run_sql tool and let it figure things out. That's the agent equivalent of a 50-page custom SQL query. It works in a demo and becomes a liability in production.
Better tools look like good data products: get_metric, compare_periods, list_dimensions. They're narrow, well named and built on definitions the business already trusts.
2. Put semantics on the server side
An agent shouldn't have to guess that "active employees" excludes contractors, or that revenue means net of refunds. Those definitions belong in a semantic layer behind the MCP server, where they're governed once and reused everywhere: dashboards, notebooks and agents alike.
3. Let users bring their own permissions
The best pattern I've used is having the agent prompt the user to connect, so every query runs with that user's access. No shared super-user service account, no accidental data leakage through a chat window. Row-level security doesn't stop mattering because the interface is now conversational.
4. Read-only by default
Most valuable agent use cases (analysis, summaries, scenario models) only need to read. Start there. Add write actions deliberately, one at a time, with human approval.
5. Log everything
Every tool call should be traceable: who asked, what the agent called, what data came back. When someone challenges a number, "the AI said so" is not an answer. A query log is.
Why this matters now
A year ago, most enterprise AI pilots were a model plus a pile of exported CSVs. That approach doesn't scale and can't be governed. MCP gives us a way to connect agents to the same trusted data our analytics already run on, with the same controls.
The question isn't whether your agents will connect to enterprise data. It's whether they'll connect through the front door or climb in through a window.
If you spent years building data platforms, this is your moment. The connectivity layer for AI looks a lot like the one you already know how to build.