MCP is becoming a hot topic and I enjoy staying on top the AI trends right now. I am cautiously MCP optimistic but I am not sold on the idea that MCP is going to become the agentic communication protocol of the promised land.
Where I find MCP interesting is a distribution play. This is the first layer where third parties can distribute into chatgpt.com and claude.com. I suspect there are going to be full cottage industries targeting direct sales, engagement and signups through those portals. Most likely before the walled garden effect hits and we all get surprised again.
MCP is an odd duck for process replacements
Most business processes are deterministic flows, not conversations. That's the whole point of automating them. MCP feels like an odd fit here when I think through each case more deeply.
A workflow or deterministic process has a set of nodes wired together - likely with some AI prompts. In this case we make a direct API call to the third party API with known parameters and load in known data. The call either succeeds or it returns a known error. The prompt isn't in the loop for the call itself: it received inputs and produced the next step.
A prompt utilizing MCP works differently. The prompt or runtime AI has a full list of tools it can call. The runtime AI will make those calls based on direction or its own choice (sometimes that alone can be difficult to control).
This is a bigger difference than it seems
Zeroing in on this difference helps one see where the positives and negatives are. For agentic processes where I want a runtime AI to make decisions - and I am comfortable providing a loose criteria with no guarantee - there is no better choice. But if I am working through a known process the benefits null out pretty quickly:
- Speed. A direct API call is milliseconds. A model call is seconds. The model is the slowest piece of the stack, and this becomes excruciating on long-running or batch calls.
- Reliability. Sometimes filters get applied wrong with MCP. Models do make bad decisions from time to time, and a 2% deviation rate sounds fine until you run the workflow thousands of times.
- Cost & Token Usage. MCP calls are a recipe for token burns.
- Hallucinations. I have observed many cases where models hallucinate the result of failed MCP calls. When you are just receiving a prompt's response, this can be difficult to discern.
- Debuggability. A direct call gives you the exact request and response. These logs are obfuscated in MCP.
- Compliance. "The model decided to call this tool" isn't an answer for an auditor.
This is part of why we treat Workflows at Aisle as factory-style pipelines. Each node does one job: prompts, HTTP calls, code, branches, connector actions.
I do use MCP a lot personally - mostly one-offs and creative work where I don't need repeatability and just want to burn tokens to a result. It's also great for distribution: ship an MCP server, meet users where they are. I would also note that MCP feels like a transitionary protocol and you should expect most of the bigger AI platforms to become walled gardens over time.
But when I think about MCP as the runtime for a business workflow that has to run the same way every time? At least today it is not a good fit. You do not gain much - as we do not want to defer decision making. And in the meantime cost goes up while speed and reliability goes down.