MCP: The Flip Side of the USB-C Analogy

Author(s): Peilun Li

Originally published on Towards AI.

The tech industry has widely embraced the analogy of MCP as the “USB-C for AI agents,” and for good reason. As consumers, we can seamlessly connect disparate products and have them communicate without needing to understand their internal implementation. This unlocks undeniable convenience and value.

This consumer-centric view of MCP is now influencing decisions within the enterprise. Companies offering general-purpose agents (like chatbots and coding assistants) are rushing to add MCP support. Inevitably, the question is now bubbling up for teams building more specialized vertical agents:

“My team is building a specialized vertical agent — an AI for a specific domain. We own the agent’s implementation and its internal tools. Should we define these tools as MCPs so they can be reused across the company later?”

The immediate answer might seem like an obvious “why not?” — and that’s precisely what worries me. At this point, I find the USB-C analogy for MCP to be painfully accurate, but from the manufacturer’s perspective, on the flip side. Let’s reframe that question using our USB-C analogy:

“My team is engineering a highly-specialized, next-generation device. Internally, we control all the core components — the CPU, display, storage, etc. Should we connect these components to the motherboard using USB-C, just so they can be potentially reused in other products across the company?”

I hope your engineering sense is screaming “absolutely not!” here. Just as there are excellent reasons for modern devices to have external USB-C ports, there are just as many compelling reasons not to use them for all internal connections. Compared to USB-C, specialized connections on a System-on-Chip (SoC) are vastly more efficient in power, space, and performance, free from protocol and controller overhead.

One might argue there’s a difference: MCP promises reusability, a feature not prioritized by internal hardware buses. To address that, let’s dive deeper into MCP’s reusability claim.

The M-by-N Pitfall

The “M-by-N” value proposition is central to the MCP pitch. The idea is that instead of building M x N unique integrations between M applications and N tools, you introduce a standard protocol. This reduces the complexity to M + N connections. A foundational assumption here is that a single tool can provide direct value to a wide range of applications.

Let’s examine this assumption by categorizing tools:

1. API-level tools: These simply wrap existing APIs. A tool that fetches a website's content, for instance, can be used by chatbots, coding agents, and more. For these, the M-by-N value proposition holds true.
2. Skill-level tools: Moving beyond simple API wrappers, “skill-level” tools are customized for a specific type of task or agent. The excellent “Your API is not an MCP” talk showcases this, giving an example of a skill-level tool for database migration. Such a tool can be heavily optimized for coding agents and would be of little use to a generic-purpose conversational chatbot. Here, the tool is already specialized, and the M-by-N value diminishes.
3. Vertical Agent Tools: Further into the domain of specialized agents, the tools must be even more skill-oriented, often embedding specific product logic for a high-quality experience. Ultimately, for these vertical agents, the tools become just as specialized as the agent itself, leaving little room for reusability.

Consider this hypothetical example from a real estate company. You are working on the Transaction Team, which helps facilitate the down-funnel transaction process after a client (home buyer) wins an offer, including loan applications, inspections, title, insurance, etc. As this process can be complex, your team wants to leverage Gen AI to build a client-facing chatbot to improve user experience. The chatbot has to be equipped with a few tools, to name just one:

Inspection Scheduler: schedule a two-party appointment between a buyer or buyer’s agent, and an inspector with time availability at the winning property. The inspection needs to meet a certain deadline.

You wonder if you can reuse an existing appointment scheduling MCP available in your company. After a brief search, you find the Tour Team has a touring chatbot that includes this MCP tool:

Tour Scheduler: schedule a two-party appointment between a buyer and a buyer’s agent, at a certain on-market home, subject to the time availability of both parties. The buyer may provide a desired timeline, and if the preferred buyer agent does not have time availability and the buyer hasn’t signed an exclusive buyer’s agreement yet, it can recommend an alternative agent with availability for the tour.

You arrange a meeting with the Tour Team to discuss the potential to expand and reuse their Tour Scheduler MCP. After the discussion, you realize it’s not feasible.

Tour Scheduler vs. Inspection Scheduler

• Systems: The Tour Scheduler uses buyer and agent calendars. Yours needs additional access to a separate, third-party inspector calendar system.
• Business Logic: Touring is a “best-effort” activity, whereas an inspection has a hard, contractual deadline, requiring different error handling and escalation logic.
• Roadmap: The Tour Team plans to add multi-home scheduling, a feature irrelevant to your inspection tool that would add unnecessary complexity.

You build a new Inspection Scheduler MCP. Later, your team decides to build another lender-facing chatbot, which requires a new Lender Appraisal Scheduler tool.

Lender Appraisal Scheduler: schedule a two-party appointment between a seller or seller’s agent and an appraiser with time availability at the winning property. The appraisal needs to meet a certain deadline.

It seems similar to your team’s existing Inspection Scheduler MCP, but again, the details get in the way.

Inspection Scheduler vs. Lender Appraisal Scheduler

• Legal & Compliance: Appraiser selection is legally-bound and must be logged in an audit system. Inspector selection is flexible. Mixing these flows in one tool is a compliance risk.
• Implementation Nuance: The logic for when parties are optional (e.g., buyer at inspection vs. seller at appraisal) is subtly different, leading to messy, conditional code if combined.

You end up creating a separate Lender Appraisal Scheduler. Later, you learn the Tour Team also had to create a new Open House Tour Scheduler instead of reusing their original tool. The two teams now have four scheduler MCPs for four seemingly similar use cases. Each MCP is used by only one product.

You realize the M-by-N problem was a red herring. For specialized vertical agents, you don’t have M applications trying to use N tools. You have a single application (M=1) that needs a set of N highly-customized tools.

The challenge isn’t discoverability or reusability; it’s tight, efficient, and reliable integration. In these cases, the answer can be a direct connection — by defining tools as part of the agent’s implementation directly, a simple N-tool integration is all that is needed (instead of MCP’s M+N). Forcing these specialized tools into a generic MCP format is like using a bulky USB-C adapter to connect a CPU directly to a memory chip. It doesn’t solve a problem; it creates overhead.

A Classic Dilemma: Buy vs. Build

You may be wondering: if MCP isn’t the ultimate solution, what is? The answer is both yes and no, because a single, unified solution rarely works for every use case. Specialized scenarios require specialized solutions. This brings our discussion of both USB-C and MCP into the frame of a classic engineering debate: Buy vs. Build.

• MCP and USB-C represent the “Buy” solution. They are straightforward to adopt, cover the majority of needs with minimal friction, and work out-of-the-box for the common 80% of use cases that fit the standard.
• A specialized approach is the “Build” route. This is for when a general solution won’t cut it and you need superior performance, control, or features. This “Build” route requires more investment and clear ROI justification, but it’s precisely where true differentiation and competitive advantage originate.

The Bottom Line

To be clear, the purpose of this post isn’t to diminish the foundational value of MCP. Its power to transform M x N complexity into M + N simplicity holds true in many scenarios, especially for consumer-facing products. Furthermore, the ecosystem of registries and standards that MCPs foster helps democratize AI, contributing to a more dynamic and innovative field.

The goal, however, is to challenge the cargo-cult thinking and blanket assumptions that can arise during any technology hype cycle, such as:

• “MCP will solve every integration problem.”
• “We should apply MCP everywhere we can.”
• “Let’s use MCP because it’s the industry standard.”
• …

Just like USB-C handles a lot of connections but not all, so does MCP. The flip side of the USB-C analogy isn’t a warning to avoid the standard, but a reminder to understand its limits. A USB-C port can unite your devices, but not the heart of your computer. A tool can speak the protocol, but not the language of your specific problem. Innovation begins where the standard ends.

Acknowledgement

Edited and refined with assistance from Gemini and ChatGPT.

Disclaimer

Disclaimer

peilunl.medium.com

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI