When people first encounter MCP, they often fall into one of two traps.
The first is:
MCP will replace workflows.
The second is:
MCP is just a more fashionable version of webhooks or function calling.
The framing I trust much more now is this:
MCP is not here to replace workflows. It is a middle layer that lets agents use tools, data, and existing systems in a more consistent, governable, and safer way.
If a workflow is the conveyor belt that actually moves goods around the factory, handles retries, branches, and compensating actions, then MCP is closer to the factory’s control panel, socket standard, and permissions model. It packages capabilities into a format that a model can reliably understand and use.
The aim of this article is straightforward: put MCP back in its proper place, and draw cleaner boundaries between MCP, webhooks, Make, agents, and workflows.
The real problem is not that AI is not clever enough. It is that it has no reliable hands.
Early AI applications often ran into the same wall:
- they could answer questions
- they could generate text
- but they could not reliably do things in the outside world
Traditional software tends to look like this:
program → API → system
The AI stack, however, often looks more like this:
model → ??? → tools / data / external systems
What is missing in the middle is a layer that lets the model discover capabilities, invoke them, receive structured results, and do so within clear rules for schema, permissions, and connectivity.
That is where MCP starts to matter.
What MCP actually is
The official framing is quite clear. MCP, or Model Context Protocol, is an open protocol that allows LLM applications to connect more consistently to external tools and data sources.
It is not a single product, and it is not one company’s proprietary API. It is better understood as a standard interface for AI-facing capabilities.
The MCP specification and learning materials describe a client-server architecture with three broad roles:
- Host: the application that delivers the AI experience, such as an IDE, chat application, or assistant
- Client: the component inside the host that maintains a connection to an MCP server
- Server: the program that exposes tools, resources, or prompts
This matters because it tells you immediately what MCP is not:
MCP is not an agent, and it is not a workflow engine.
It is the communication and capability exposure standard that allows a host, through a client, to talk to one or more servers.
What are the three main things MCP exposes?
MCP is more than tool calling. If you only think of it that way, you miss a large part of its value.
Today, MCP’s core capabilities can be grouped into three categories.
1. Tools
This is the easiest part to grasp. Tools are callable operations. They let the model query data, call APIs, perform actions, or kick off processes.
2. Resources
Resources are contextual data entry points. They are not necessarily actions. They are more like external content or data sources that the model can read and incorporate.
3. Prompts
In MCP, prompts are not just “some text”. They are structured, parameterised, explicitly invokable interaction templates. The official documentation even notes that prompts can reference tools and resources to create more complete workflow experiences.
That detail is worth dwelling on because it makes one thing very clear:
MCP does not only expose isolated tools. It can also expose higher-level working templates and reusable task structures.
What problem does MCP actually solve?
1. It stops you from reinventing every integration by hand
Without MCP, the world quickly turns into this:
- every external system gets a bespoke integration
- every tool has its own schema and conventions
- permissions, authentication, validation, and result formats are all handled differently
- switching to a different AI client often means doing much of the work again
MCP does not eliminate all integration effort, but it standardises the foundation.
OpenAI’s MCP tool guide says this very plainly: instead of manually wiring each function call to each service, you can point the model at one or more MCP servers, which act as a centralised tool host. That makes orchestration simpler and tool management more coherent.
2. It makes tool discovery more formal
A tool is not useful merely because it can execute. The model also needs to know:
- what the tool is for
- when it should be used
- how its parameters are shaped
- what the result looks like
- how it differs from nearby tools
This is why the documentation keeps emphasising schemas, descriptions, and detailed scenario descriptions. MCP is not just about connectivity. It is also about making tool semantics legible to the model.
3. It brings auth, permissions, and transport into a governable layer
The MCP architecture documentation explicitly says that the transport layer handles communication channels and authentication. OpenAI’s Codex MCP documentation also makes clear that current support includes:
- local STDIO servers
- Streamable HTTP servers
- bearer-token and OAuth-style authentication
This matters because the biggest risk in agentic systems is not simply “the model might pick the wrong tool”. It is also:
- how credentials are issued
- how permissions are narrowed
- which capabilities are exposed
- which capabilities should only be revealed in constrained ways
MCP does not magically solve security, but it gives you a more standard place to organise it.
But what does MCP not solve?
This part is even more important, because many people load too many expectations onto MCP and then wonder why it does not behave like a universal solution.
MCP does not directly solve the following.
1. It is not a workflow engine
MCP does not give you:
- long-chain workflow design
- retry policy
- scheduling
- compensating transactions
- human approval stages
- idempotency
- data transformation pipelines
- long-running state management
Those concerns belong more naturally to tools such as Make, n8n, Temporal, Airflow, or your own orchestration layer.
2. It is not a replacement for business logic
Company rules, operational exceptions, approval conditions, and error handling do not disappear just because you connected an MCP server.
MCP exposes capabilities. It does not define your business process for you.
3. It is not “a more advanced webhook”
Webhooks solve event notification. Their usual shape is:
- something happens
- an HTTP request is sent to a configured endpoint
- a downstream system reacts
MCP solves a different problem:
- how a model discovers tools
- how it chooses among them
- how it invokes them
- how it reads structured context
- how it combines capabilities
A webhook can absolutely be the trigger for a workflow.
MCP can absolutely be how an agent gains access to that workflow or to related tools.
They may meet, but they are not substitutes for one another.
Why I say MCP will not replace workflows
Because both the official documents and real products are pointing in the same direction:
MCP is better understood as the bridge that turns workflows into callable capabilities for agents, not as the mechanism that swallows workflows whole.
The clearest example is Make.
The current Make MCP Server documentation states this directly: active, on-demand scenarios can be turned into callable tools for AI. Clients such as Claude and ChatGPT can use MCP to run scenarios and manage related resources, while scopes determine which tools are exposed.
The implications are bigger than they first appear:
- the Make scenario does not disappear
- the workflow engine is not replaced
- the agent does not suddenly “understand every API”
- the workflow is wrapped in a model-usable tool interface
In other words, MCP is not erasing workflows. It is making workflows usable by agents.
That is why this remains my favourite architectural summary:
MCP lets agents use workflows.
Not replace them. Connect to them.
Where Make sits in this stack
If I slice the stack cleanly, this is how I see it:
- LLM / Agent: understands the goal, makes decisions, chooses tools
- MCP: exposes tools, resources, and prompts in a standard way
- Workflow engine (for example, Make): executes multi-step processes reliably, manages data flow, retries, logging, and operational rules
- Apps / APIs / databases: the external systems where the real actions happen
So for me, Make is not a competitor to MCP. In many architectures it becomes one of the most valuable execution engines behind MCP.
Make’s own documentation makes this concrete. For a scenario to become an MCP tool, it needs clear inputs and outputs, should be active and on-demand, and benefits greatly from a detailed description. In practice, that means turning a workflow that was originally legible to a human into a capability contract that is also legible to a model.
That is a good discipline. Mature agent systems should not rely on the model “guessing” how tools work.
MCP vs webhook vs direct API integration
People tend to blend these into one soup. I think it is cleaner to separate them like this.
Webhook
Best for:
- notifying other systems when an event occurs
- one-way triggers
- event-driven integration
Its strength is immediate triggering, not dynamic tool discovery for models.
Direct API integration
Best for:
- one product or one tightly scoped application
- a small number of tools
- teams willing to maintain custom schemas and permission handling by hand
- cases where client portability is irrelevant
Its strength is directness and custom fit. Its weakness is that every new tool adds bespoke integration work.
MCP
Best for:
- AI clients that need to discover and use multiple tools and resources
- systems that want schemas, descriptions, permissions, and transport handled in a standard layer
- teams that want the possibility of reusing the same capabilities across different hosts or clients
- architectures where workflows, data sources, and operational capabilities should be exposed through a common interface
It is not always the shortest path, but once the system becomes more complex, it is often the steadier middle layer.
A practical split: who decides, who standardises, who executes
The simplest framing I keep returning to is this.
The agent decides
It interprets the user’s goal, chooses the next move, and selects the right tool.
MCP standardises and connects
It stops tools and data sources from becoming bespoke integrations that must be rewritten for every client. It provides a discoverable, authorised, describable capability surface.
The workflow executes reliably
It handles the things that want:
- retries
- logging
- approvals
- mapping
- compensation
- scheduling
- data handling
If those layers are separated cleanly, the system is far less likely to turn into architectural porridge.
When you probably do not need MCP
Not everything should be wrapped in MCP. This matters because otherwise your architecture becomes bloated.
1. You only have one internal system and a few fixed functions
If the application is narrow and the set of operations is small and stable, direct function calling or direct API integration may simply be easier.
2. The tools do not need to be reused by different AI clients
If the capability surface only exists for one backend service and there is no portability requirement, MCP’s benefits may not justify the added layer.
3. Your actual gap is not standard interfaces, but process design and tool governance
Many teams think they need MCP when what they actually need is:
- better tool definitions
- narrower permissions
- cleaner workflow boundaries
- explicit error paths
- stronger observability
MCP cannot replace that thinking for you.
The more useful architecture question is not “Can MCP replace workflows?”, but “Can it help agents use workflows properly?”
That is the sentence I trust most after doing this round of research.
If you treat MCP as a workflow substitute, you will likely be disappointed. It will not magically handle:
- retries
- state machines
- branch orchestration
- compensation
- business rules
- operational visibility
But if you treat it as the standard middle layer between agents and external capabilities, its real value becomes much easier to see:
- it makes capability exposure more consistent
- it clarifies auth and scope
- it helps AI clients understand when to use which capability
- it allows existing workflow engines, data systems, and search tools to plug into an agent stack with more order and less guesswork
At that point, the system starts to look like this:
User → Agent → MCP → Workflow / APIs / DB → Result
instead of this:
Agent guessing how to call every API by itself
Conclusion: MCP is not the destination. It is the interface layer. Workflows are not outdated. They are the execution backbone.
If I had to compress this article into one sentence, I would put it this way:
The agent decides what to do, MCP connects capabilities in a standard form, and the workflow layer gets the work done reliably.
That is why I do not see MCP as a replacement for workflows.
I see it as an important bridge.
It means agents do not have to relearn the world from scratch every time.
And it means we do not have to force all execution logic into the model’s head.
That, to me, is the cleaner and more durable architectural split.
Image Asset Plan
-
filename: ai-agentic-workflow-series-07-01-mcp-stack.svg
purpose: A top-level diagram showing the relationship between Agent, MCP, Workflow, and Apps / APIs / DB
placement: Before the section “Where Make sits in this stack”
alt: Layered architecture showing Agent, MCP, Workflow, and external systems
prompt: A blog-friendly SVG architecture diagram. Top to bottom: User, Agent, MCP layer, Workflow Engine, Apps/APIs/DB. Show Agent as decision layer, MCP as standardised interface layer, Workflow as execution layer. English labels, rounded boxes, clean arrows, soft colours, modern product-doc style, uncluttered. -
filename: ai-agentic-workflow-series-07-02-mcp-vs-webhook-vs-api.svg
purpose: A comparison visual showing the responsibility boundaries of MCP, webhooks, and direct API integration
placement: After the section “MCP vs webhook vs direct API integration”
alt: Comparison diagram of MCP, webhook, and direct API integration
prompt: A clean comparison SVG for a technical blog comparing MCP, Webhook, and Direct API Integration. Show each as a separate lane with purpose, strengths, and limits. English labels only, minimal text, generous spacing, rounded cards, crisp arrows, no clutter.
Sources
See ./resource/references.md for the full reading list.