MCPs Business Case

Let’s start with a question: "What is the ROI of a USB cable?"

It sounds strange, right? You don’t buy a USB cable for the return on investment. You buy it because without it, your portable hard drive is a paperweight. It’s infrastructure and a standard.

Yet, this is exactly how the industry is currently debating the Model Context Protocol (MCP). The conversation is fixated on the technical specification — the “what.” We hear that it is a standard interface for connecting AI models to data, or “USB-C for LLMs.” While true, that definition is strategically limited.

When you buy a car, you don’t buy it because it has four wheels and seats. That’s the output of the manufacturing process. You buy a car because you want to run a taxi service, or fix your logistics, or just get to work faster. You buy it for the outcome.

To find the real business case for MCP, we must look past the technical plumbing and examine the economic lever. Why are pragmatic engineering organizations like Block and Stripe investing here? It is not merely engineering hygiene. It is an attempt to solve two expensive enterprise problems: productivity at the edge and integration at the core.

Dimension 1 - The Interface Revolution

The most immediate value of MCP is the transformation of the end user interface.

Consider the case of Block (Square). They developed an internal platform (called “Goose”) using MCP to connect fragmented tools — Jira, GitHub, Snowflake, and HR systems — into a single conversational interface. They report that engineering teams save 50–75% of their time on common tasks such as triage and code migration.

This efficiency does not come from AI inventing new processes. It comes from removing the friction of context-switching between dashboard silos.

The Shift of the Gatekeeper
To understand the staying power of this, consider the history of digital interfaces:

• In the 90s, the Browser and Search Engines were gatekeepers to value.
• In the 2010s, the App Stores were the gatekeepers.
• Today, the Chat Window is becoming the new entry point.

MCP is the plugin standard that allows that Chat Window to execute actions beyond simple text generation. Pure Chat Windows are very low bandwidth UIs, but this is also changing. New developments like MCP UI (where the chat returns interactive widgets) suggest a return to applet-like functionality, but with higher intelligence.

Because chat agents are here to stay, this dimension justifies the investments — you can build products or even entire companies around it.

Importantly, Dimension 1 stands fully on its own. Organizations can deploy personal productivity agents without creating any system-to-system integrations or adopting a composable architecture. Governance is also manageable because these agents can rely on “identity mirroring” — inheriting the user’s own IAM permissions. This makes Dimension 1 the lowest-risk and fastest-adopted perspective on MCP.

Dimension 2 - The Integration Bypass

The second dimension addresses a legacy problem that has plagued enterprises for decades: Integration Debt.

Siloed data and rigid API contracts often paralyze cross-functional automation. Fifteen years ago, the industry attempted to solve this with Robotic Process Automation (RPA). The premise was to bypass IT bottlenecks by automating the User Interface.

RPA worked for a time, but it was structurally brittle. It relied on screen coordinates and DOM elements. When the UI changed, the automation broke, leading to escalating maintenance costs that eroded ROI.

MCP functions as a structural evolution of RPA.

It shares the same aggressive integration strategy — bypassing the need for complex middleware projects — but replaces the method. Instead of automating Pixels (which are fragile), MCP automates Capabilities (APIs and UI functions).

It’s important to clarify that MCP is not “agentic” by default. MCP is simply an interface layer — it exposes capabilities. Whether you attach a deterministic script, a conversational assistant, or a fully autonomous agent on top of those capabilities is a separate architectural choice. In this article, I focus specifically on agentic MCP systems because they highlight the governance issues most organizations will face.

Again, this perspective exists independently. Some organizations will adopt Dimension 2 to address a single high-value operational bottleneck — without ever deploying personal assistants or investing in composable agent architectures.

Leveraging Technical Structure to Bypass Coordination
We are seeing a trend where IT departments use MCP — much like internal API Gateways — to streamline the politics of integration. By requiring departments to expose standard MCP servers, organizations bypass the need for bespoke, point-to-point integration projects.

Data supports this. OneReach reports that using this approach cuts integration time by roughly 25%. It does not fix the underlying architectural legacy, but it provides a universal adapter that allows automation teams to move significantly faster.

The Strategic Trade-off
This shift from “brittle” to “probabilistic” requires a new approach to risk management — one where governance moves away from auditing outputs and instead focuses on auditing capabilities. It is important to emphasize that this challenge comes from the agentic layer, not from MCP itself. MCP only exposes capabilities; it is not inherently agentic. But once those capabilities are used by an autonomous agent, traditional governance models break down. And this is where most enterprises struggle: the technology is ready, but their governance frameworks have not yet evolved to manage probabilistic behavior.

Dimension 3 - Composable Architecture

The third dimension is often misunderstood as a “Marketplace for Digital Coworkers.” In practice, the real value is technical composability, and that is not unique to agentic use cases.

In a fragmented organization, multiple teams often attempt to build AI agents for their specific verticals simultaneously. If they all build from scratch, the result is fragmentation, fatigue, and inconsistent security.

MCP promotes Composable Architectures. Organizations can organize components in layers:

• Interface Layer: how users interact with the agent
• Cognitive Layer: how the agent thinks and acts
• Capability Layer: what the agent is able to do

Instead of building a monolithic “Supply Chain Agent,” teams compose it from these certified parts. This solves the “Empty Factory” problem. It turns the creation of agents from a bespoke art project into a standardized assembly line, leveraging the same governance patterns IT already uses for APIs.

Important: Dimension 3 is not about enabling infinite agent configurations. In reality, most organizations only need 5–10 recurring agent compositions. The purpose of a composable architecture is not to build more agents — it is to build them in a way that is maintainable, governable, and secure once the number of agents grows. It is the strategic choice you make when you believe that the Total Cost of Ownership (TCO) of maintaining dozens of bespoke agents will exceed the upfront investment in a standardized agent factory.

A useful way to understand Dimension 3 is through its internal evolution. Once an organization chooses to pursue composability, it naturally progresses through three stages:

• Code Blueprints — teams clone source code templates; drift is high; governance is weak.
• Boxed Agents — central teams maintain standard “ready to deploy” compositions; updates and governance improve; performance is tuned per instance, but the underlying code remains the same.
• Modular Composable Architecture — teams assemble agents from standardized MCP modules; governance applies to modules, not agents; scale becomes sustainable.