MCP is becoming a hot topic, and I enjoy staying on top of it. I'm cautiously optimistic about some applications, but I'm not sold that it's going to be the agentic communication layer of the promised land.
But I love it as a distribution play. MCP might be the first layer where other tools distribute into chatgpt.com and claude.com, which makes it a great platform for reach. There are probably some MCP servers that make sense to release even for us at Aisle.
Where my spidey senses tingle
Most business processes are deterministic flows, not conversations. That's the whole point of automating them. To see why MCP is a bad fit there, it helps to look at what's actually happening in each case.
A workflow with a direct API call. You have a prompt that produces some structured output. The next step is an HTTP node that takes that output and makes a specific call to a specific endpoint. The call either succeeds or it returns a known error. The Prompt isn't in the loop for the call itself: it produced inputs, and your workflow executed them. Perhaps another Prompt receives the API response.
A model with an MCP call. When an LLM is using MCP, it has a full list of tool definitions and descriptions the server exposes. It then decides which one to call from a set of descriptions, generates the arguments, and executes the call.
Who controls the API call?
The difference isn't really about MCP as a protocol. It's about who decides what call gets made. In the first case, you decided, at build time. In the second, the model decides, at runtime, every time it runs. The trade-offs become pretty obvious from there:
- 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. 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. 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. It's also great for distribution: ship an MCP server, meet users where they are. Keep in mind MCP feels like a transitionary protocol, and you should expect most of the bigger AI platforms to become walled gardens over time.
MCP as the runtime for a business workflow that has to run the same way every time: no. Use a deterministic pipeline where the model produces inputs and your workflow executes them.