MCPs means Maybe Correct Plumbing

Added: 2026-05-22

[00:00:00]I'm sick of hearing about MCPs. They're the flavor of the month in enterprise AI and it seems like every vendor is talking about them. My LinkedIn feed is full of people telling us that MCPs are some kind of groundbreaking new discovery.

[00:00:14]Officially, MCP stands for model context protocol. It's a standard that lets an AI model reach out and use tools, read data, and take actions in systems beyond the defined boundaries.

[00:00:27]But I tend to think of MCPs as maybe correct plumbing. And by the end of this video, you'll understand why.

[00:00:34]So, let me paint you a picture. Imagine you call a plumber to fix a leaking tap in your kitchen. Dave. Dave shows up, looks at the tap, walks back to the van, and comes in with the exact spanner and the exact washer that he needs. He's in and out in 10 minutes. Job done. Well done, Dave.

[00:00:52]Think of Dave like an API, an application programming interface.

[00:00:56]Which is the traditional way that data moves between applications.

[00:01:00]Just like Dave, if you give an API a problem, it will give you an exact answer. Nothing more, nothing less.

[00:01:07]Your payroll system talks to your bank through an API. Your ERP talks to your data warehouse through an API.

[00:01:13]Every time one piece of software needs to connect or get something from another piece of software, the API is the thing in the middle. It's like a contract that's written down before anyone exchanges anything.

[00:01:25]That contract or that protocol is the whole point. Because the developer who built the integration knew on the day that they built it exactly what data would move, in which direction, under what conditions. It was tested, it was signed off, and when something goes wrong, you can trace it.

[00:01:42]Now, let's imagine we have a new plumber show up called Claude. He doesn't have a van full of the right parts, but he's got a tool belt with a little bit of everything on it. He looks at your tap, he rummages around on the belt, he picks something that looks right, tries it, puts it back, tries something else.

[00:01:57]Eventually, the water stops dripping, sort of, mostly, and then he leaves.

[00:02:02]Did he fix the tap?

[00:02:03]Probably. Will it leak again next Tuesday? Maybe. Did he use the right washer? Yeah.

[00:02:09]You'll find out when the ceiling below starts getting damp.

[00:02:12]So, let me put some technical meat onto that. A traditional API is like a fixed pipe. You build it once, and it connects one specific system to another specific system to do one specific thing.

[00:02:23]Your ERP pushes general ledger data into your reporting tool through a pipe. Your payroll system sends figures to your finance platform through another pipe.

[00:02:32]Each pipe has a specific purpose. Water goes in one end and comes out the other.

[00:02:36]That's it.

[00:02:38]The model has worked fine for 20 years.

[00:02:40]It's predictable, it's testable, and you know exactly what goes through each pipe because you built the pipe.

[00:02:46]Now, the MCP is the new kid on the block that thinks it can do anything.

[00:02:50]Instead of building a dedicated pipe for each task, you give an AI agent belt with a set of tools hanging off it.

[00:02:57]One tool reads the data warehouse.

[00:02:59]Another tool queries the general ledger.

[00:03:01]Another tool sends emails. Another tool creates a document.

[00:03:05]The agent looks at what you've asked it to do, and picks tools off the belt in order to do what it thinks it's right.

[00:03:12]And maybe it picks the right tools, and maybe it doesn't. Hence, the term maybe correct plumbing.

[00:03:18]So, let me cut to the chase. MCPs are a bad idea for these reasons. Number one, auditability. MCPs replace a written contract or an API with an AI model's judgment.

[00:03:29]But, that judgment is not auditable. And unlike an API, you can't guarantee that the MCP is going to work the same way every time.

[00:03:37]Number two, security. Every MCP server that you connect to is a new attack surface. And it's been authenticated with your credentials and trusted with your data.

[00:03:47]We've just spent years putting multi-factor authentication and passwords into everything, and now we just hand over all our data to this AI agent and hope for the best.

[00:03:56]Number three, sovereignty. Most popular MCP servers route through overseas infrastructure. That means your data leaves the building and you have no idea where that building is or who has got access to it.

[00:04:09]Number four, control. MCP makes shadow IT trivially easy. A junior analyst can wire up chat GPT into your CRM in just a few minutes and nobody has any idea what they're doing with that data.

[00:04:23]Number five, lock-in. MCPs claim to be vendor neutral, but that's rubbish. If you swap out one AI model for another, your tool descriptions and your orchestration logic has to be all rebuilt and tested as best it can from scratch.

[00:04:38]Now to be fair, there are some good use cases for MCPs. They're great for prototyping. MCPs are great for proving out an idea before you commit to a production workflow.

[00:04:48]Number two, they're good for trivial use cases where it doesn't really matter if the AI gets it wrong.

[00:04:54]If the blast radius is small and the audit requirement is low, then maybe an MCP is a good idea, but it should never be used on something serious like a general ledger or a CRM.

[00:05:04]Read-only workflows.

[00:05:06]An agent could query a data warehouse for read-only access and that might be useful. Assuming, of course, that the token costs justify the output.

[00:05:14]So, in my view, traditional APIs are still the right answer for anything that has to be repeatable and deterministic, which in business is pretty much everything outside creativity and discovery.

[00:05:25]Anything where the same inputs need to give you the same outputs every time, you need fixed pipes which are always correct.

[00:05:32]MCP might be the right answer for tasks where flexibility is more valuable than repeatability.

[00:05:37]Exploration, um pulling information from systems to prototyping, that could be good enough.

[00:05:44]But the mistake I see is that teams treat this as the same thing, and they're not. If someone's pitching you as an MCP for a replacement for your reporting stack, ask them which plumber they'd want working in their own house.

[00:05:56]The one with the right parts in the van, or the guy with the tool belt who guesses at which washers to use?

[00:06:01]Now, I know that many people might strongly disagree with my characterization of MCP, and that's fine.

[00:06:06]Whether you agree or disagree, I'd love you to drop your thoughts in the comments. I do read each one, but it does take me a while to respond.

[00:06:14]Thanks again for watching. Please like and subscribe, and I'll see you in the next one.