MCP in Production: What It Actually Means for Your Business Systems

There's a question doing the rounds at the moment: who is actually using MCP in production, rather than just trying it out on a laptop? It's a fair question. A lot of what gets built with the Model Context Protocol is a demo. Something that looks great in a five-minute video and falls over the moment real data, real permissions and real customers get involved.

If you run a business and you've heard the term MCP but not what it means for you, here's the plain version, and what I'd check before letting an AI agent anywhere near your systems.

What MCP actually is

MCP (Model Context Protocol) is a standard way for an AI assistant, like Claude or a custom agent, to talk to a piece of software. Instead of every developer inventing their own way to let an AI read a database or send an email, MCP gives everyone a shared format. You build (or install) an "MCP server" for your system, and any AI that speaks MCP can use it.

In practice, this means an AI agent could look up a customer's order, check stock levels, create a support ticket, or update a spreadsheet, all by calling your systems directly instead of you copying and pasting information into a chat window. That's genuinely useful. It's also exactly the sort of thing that goes wrong quietly if nobody's checked it properly.

Demo versus production

A demo MCP server usually has one job, runs on someone's machine, and gets restarted the moment it breaks. Nobody minds because nothing depends on it.

A production one is different. It has to:

• Only give the AI access to what it actually needs, not your entire database
• Keep a record of what the agent did and when, so you can check it later
• Fail safely if the AI sends something malformed or asks for something it shouldn't
• Keep working when a dependency changes, the same problem that hits any integration relying on a third-party API
• Have someone who actually understands what it's doing, not just someone who copied a template

None of that is exotic. It's the same discipline you'd want from any integration between two pieces of software. MCP doesn't change the rules, it just makes it much easier to skip them, because getting something working at all can take an afternoon.

Why this matters more than it looks like it does

The risk with MCP isn't that the AI does something dramatic. It's that it does something small and wrong, quietly, and nobody notices for a while. An agent given write access to your CRM to "keep records tidy" might merge two customers who happen to share a similar name. One connected to your accounting package to "chase overdue invoices" might send a chaser to someone who paid last week, because the data it read was a few minutes stale. None of these are AI going rogue. They're ordinary integration bugs, the kind that have existed for as long as two systems have talked to each other. The difference is that an AI agent can make far more of these small mistakes, far faster, than a person doing the same task by hand.

Questions worth asking before you connect one

Before an MCP server, or any AI agent, gets access to a system that matters, I'd want clear answers to these:

• What can it actually do? Read-only is a very different risk to "can create, edit and delete records."
• What's it allowed to touch? Scope access to the specific tables, folders or endpoints it needs. Don't hand over a master key because it was quicker to set up.
• Is there a log? If a customer disputes something, or a record looks wrong, can you see exactly what the agent did and when, without guessing?
• What happens when it's wrong? If the AI misreads a request or the underlying API changes shape, does the connector fail loudly, or does it silently write bad data?
• Who maintains it? Someone needs to own this the way they'd own any piece of custom code, not treat it as a one-off script nobody revisits.

That last point matters more than people expect. An MCP connector someone knocked together in a weekend, with no tests and no documentation, is technical debt the moment it's plugged into anything real. The questions I'd ask about who owns it and what happens if the person who built it disappears are the same ones I'd raise about any bespoke software you commission.

Where this fits with existing integration work

Most of what MCP is being used for isn't new. Businesses have been connecting one system to another, and building tools that read and act on data, for years. What's changed is who's asking for the connection, an AI agent rather than a scheduled job or another human, and how quickly it can be built. If you're already thinking about connecting the tools your business runs on, an MCP server is one more way to do it, not a different category of problem. The same care applies: know what data is flowing, know who can see it, and build it properly the first time rather than patching a demo until it becomes load-bearing.

AI agents talking directly to business systems is going to become normal. That's fine. It just needs the same care you'd give any integration that touches customer data or money, built by someone who'll still be around to explain how it works if something goes wrong.