Model Context Protocol vs. Programmatic Workflows
What are the pros and cons of the Model Context Protocol over programmatic workflows?
Can the Model Context Protocol (MCP) dethrone the traditional programmatic way of managing workflows? The MCP was first introduced by Anthropic in November 2024. Its original goal was to build "two-way connections between data sources and AI-powered tools." Its latest available specification at the time of this writing also mentions that you can use MCP to "build composable integrations and workflows." Traditional systems, such as IFTTT, n8n, or Zapier, let you programmatically define your workflows. Which approach is the best one? Follow me while I explore and find out.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
I've been working with API workflow systems for around 20 years. Most of those systems fall into what you can call "integration Platform-as-a-Service" or, in short, iPaaS. More recently, the growing popularity of AI triggered the need to connect to APIs in a non-programmatic way. What do I mean by that? When you're interacting with an AI system—usually via a chat UI—and you ask it to perform an action on your behalf, it needs to connect to one or more APIs. Behind the scenes, the AI system has to figure out what action you want it to perform, what APIs can fulfill the action, how to connect to those APIs on your behalf, plan the execution of a chain of requests, and finally, actually execute those requests. Every time you ask something different the AI system will infer a different execution plan, or workflow. That's why it's not programmatic. You can't program how the workflow will behave.
On the other hand, when you set up a programmatic workflow, it will behave in a deterministic way every time it runs. A workflow consists of a series of steps that can run sequentially or in parallel. Some of those steps can also give way to conditional branches that will only run under a specific situation. Because the workflow is programmatic you know how it will behave every time you trigger it. Unless the workflow has steps that depend on external conditions, it's pretty much deterministic, which makes it easy to understand. We could go on and explore more differences between MCP and programmatic workflows. But how do they compare from the perspective of a developer? Which system offers the best developer experience? Which one is the easiest to integrate with? Let's find out.
Since one of the goals of MCP is to standardize the communication between AI applications and APIs, it's natural that it uses schema-driven data. All communication uses JSON-RPC, meaning that all requests and responses adhere to existing schemas. One advantage of this approach is that AI knows what data to expect and can easily incorporate it into its context. However, existing APIs that don't follow JSON-RPC need to be adapted to work with MCP. Or, alternatively, developers need to create adapters that understand JSON-RPC and also the architectural style of existing APIs. Programmatic workflow systems don't follow this kind of standardization. Every interaction with a different API needs to be configured. The advantage is that there's great flexibility in how data can flow between workflow nodes. However, and because of that, inputs and outputs need to be fully configured for every API you want to integrate with.
Which type of system is easier to integrate with? From a developer’s perspective, MCP introduces a unified development pattern, reducing the need for repetitive boilerplate code and enabling faster onboarding through consistent schemas and clear contracts. With MCP, you can build connectors once and reuse them across multiple AI applications, significantly reducing maintenance. MCP's built-in schemas ensure data consistency and help catch errors early, while the availability of SDKs in languages like TypeScript and Python provides a smoother experience for building both clients and servers. On the other hand, traditional programmatic workflows offer unmatched flexibility and immediate control, if you're familiar with REST. While this approach makes it easy to create custom workflows, it comes at a cost. As integrations scale, maintaining fragmented codebases becomes a challenge, leading to higher complexity and potential inconsistencies. While programmatic workflows look perfect for quick implementations, they often struggle with scalability and maintainability, making MCP an attractive alternative for large-scale AI-driven platforms that require a more structured, reusable approach to tool integration.
And that's the point I wanted to get at. At first glance, the very rigid standardized MCP schema-driven approach looks like a turn-down. However, it's precisely this rigidity that makes integrations easier to maintain in the long run. Compare that with a workflow where you need to maintain the connection with several REST APIs on a regular basis. If you're like me and you've been working mostly with REST you'll probably want to spend more time studying JSON-RPC in the near future.