What is MCP, and why it matters for business data

MCP is a standard way for an AI assistant to connect to a system and use it. Before it, every AI-to-tool connection was custom-built. It matters for business data because the connection is defined outside the conversation - the permissions are set before the AI arrives, not negotiated in a prompt.

The term has started appearing in vendor material without much explanation, usually as a feature bullet. Here is what it actually is, and the part that matters for anyone thinking about letting an AI near their company data.

What MCP is

Model Context Protocol. An open standard, published by Anthropic in late 2024, for connecting AI assistants to external systems.

The problem it solves is boring and real. An AI model on its own knows nothing about your company. To be useful it needs to reach your database, your files, your ticketing system. Before MCP, each of those connections was bespoke - a different integration per tool, per assistant, maintained separately.

MCP defines a common shape for that. A system exposes an MCP server that describes what it offers - which tables can be read, which actions can be taken - and any MCP-capable assistant can connect to it without a custom build. We use it to connect Claude to our managed data warehouse.

It is closer to a plug standard than to a product. Not intelligent, not a model, not a feature. Just an agreed way for two things to talk.

Why it matters more for business data than for anything else

For a personal use case, the convenience is the point. For company data, the interesting property is different: the scope is defined server-side.

When we connect Claude to a client's warehouse, the server declares what exists and what is reachable. Read-only credentials. A specific set of tables. Permissions per team.

None of that is instruction. It is not a system prompt asking the model to behave, and it is not a filter applied to an answer after the fact. The AI cannot write, because there is no write path. It cannot see the payroll table, because that table is not in scope for the person asking - so it was never returned.

That distinction is the whole security argument, and it is worth being precise about. A model instructed not to reveal something can potentially be talked around. A model that never received the data cannot reveal it, no matter how the question is phrased.

What it looks like in practice

On our managed warehouse, the connection announces itself when a session opens: the MCP connection is established, read-only credentials authenticate, twelve tables and around four million rows are discovered, and the permission scope for that person is applied.

Then someone asks a question in plain language. The assistant reads the modeled tables it is allowed to read, and answers from them.

Switch to a marketing user and the payments and sales-rep tables show as locked. Same warehouse, same assistant, different scope. There is a working demo of exactly this on the warehouse page, cycling through five teams.

What MCP does not do

The part most write-ups skip, and the reason people are disappointed.

It does not make your data good. MCP connects an assistant to whatever you point it at. Point it at raw transactional tables and you get fast, convenient access to ambiguous data - and answers that do not match your dashboard. We covered why in why AI gets your numbers wrong.

It does not define what anything means. That is the semantic model's job. MCP decides what the AI can reach. The model decides whether what it reaches means anything consistent.

It is not automatically secure. It is a transport standard. A carelessly configured MCP server with write access to production is a bad idea that MCP will happily facilitate. The safety comes from the configuration, not the protocol.

It does not replace an analyst. It removes the export-and-assemble work. Deciding what to measure and what the answer means is still a person's job.

Do you need it?

Not necessarily. Export a CSV and paste it into a chat - that works, and for a one-off question it is the right amount of effort.

MCP earns its place when three things are true:

• The question gets asked repeatedly, so exporting each time is waste
• The answer needs to come from live data, not a snapshot from last Tuesday
• Different people should see different things, and you want that enforced rather than remembered

If all three hold, a connection beats a copy. If only the first, a scheduled report is simpler and cheaper.

The honest summary

MCP is plumbing, and plumbing is worth understanding because of what it makes possible rather than what it is.

What it makes possible: an assistant that reads governed data under enforced permissions, instead of a chat window you paste spreadsheets into. That is a meaningful difference in a company setting, and it is mostly a difference about control rather than intelligence.

What it does not make possible: correct answers from data nobody has modeled. That work still has to happen, and it happens before the AI is connected, not after.