Transcription
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. 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.
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. 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.
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.
Number four, control. MCP makes shadow IT trivially easy. A junior analyst can wire up ChatGPT into your CRM in just a few minutes and nobody has any idea what they're doing with that data.
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.
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.
Number two, they're good for trivial use cases where it doesn't really matter if the AI gets it wrong. 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.
Read-only workflows. 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.
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. Anything where the same inputs need to give you the same outputs every time, you need fixed pipes, which are always correct.
MCP might be the right answer for task where flexibility is more valuable than repeatability. Exploration, um pulling information from systems to prototyping, that could be good enough. But the mistake I see is that teams treat this as the same thing, and they're not.