MCP Isn’t the USB-C for AI. It’s More Interesting.
Why the most popular explanation of the Model Context Protocol is practical, but misses the most important part.
MCP is surprisingly often explained as “USB-C for AI.” I understand why. The metaphor takes ten seconds to grasp: instead of building a separate connection for every AI system and every tool, we agree on a common interface. But I’ve come to believe that this explanation makes MCP seem smaller than it is. Because a USB-C port primarily standardizes how two devices are connected. MCP, by contrast, could help determine how software becomes usable by machines in the future.
At first, that sounds like a small semantic difference, but to me, it is the far more interesting idea. If we look at MCP only as an integration standard, we quickly end up talking about developer experience, SDKs, and the question of how many MCP servers a provider already supports. If, on the other hand, we look at it as a new interaction layer between AI and software, we arrive at very different questions: Which capabilities of a product should agents understand? Which of them should they be allowed to execute? What information do they need to do so? And what happens to traditional user interfaces when a growing share of work no longer even begins through that interface?
The USB-C metaphor is correct. But only halfway.
Technically, the metaphor certainly has merit. The Model Context Protocol describes an open standard through which LLM applications can incorporate external data and capabilities. MCP servers can provide Resources, Prompts, and Tools, among other things; communication is based on JSON-RPC. The architecture distinguishes between Host, Client, and Server, creating a common model for integrations that would otherwise have to be built individually. [modelconte...rotocol.io], [modelconte...rotocol.io]
That is valuable because integrations have always been a fairly thankless part of software development. Anyone who has connected enough SaaS products knows the pattern: understand OAuth, read API documentation, discover strange edge cases, translate data models, account for rate limits, and then hope that the other side does not change its API at exactly the moment when you actually wanted to build something else. If a common standard can unify part of this work, then first and foremost, that is simply good infrastructure.
But that still does not explain why MCP is so interesting.
Because the fundamental shift happens one level above. Traditional integrations are usually built for a predefined workflow: System A sends specific data to System B when event C occurs. With agentic software, the starting point is different. A model interprets an intent, decides which tool seems appropriate within the capabilities available to it, and can then use that tool. MCP therefore does not merely standardize a connection between systems. It increasingly standardizes a language for describing which capabilities software makes available to an AI system in the first place. [modelconte...rotocol.io]
That is a significantly bigger idea than “finally less integration code.”
We Still Build Software as If a Human Necessarily Sits in Front of It
Almost every SaaS product reveals within the first few seconds who we have historically built software for. There is navigation, a dashboard, buttons, forms, tables, tooltips, and somewhere a CTA whose wording was probably debated for longer than anyone would like to admit. All of these elements solve a real problem: a human has to understand what the product can do and how to get it to do something.
An agent has this problem in a different form. It does not need a nicer button. It needs a reliable description of a capability, the corresponding inputs, and clear boundaries around what is allowed to happen. The current MCP specification represents exactly these kinds of capabilities through Tools, among other things, and context through Resources. At the same time, the architecture provides security boundaries: Hosts coordinate connections and permissions, while individual Clients each communicate with one Server. [modelconte...rotocol.io], [modelconte...rotocol.io]
This creates something alongside the human user interface that, in simplified terms, can be thought of as an Agent Interface.
And this is exactly where things become interesting for product teams. The question is no longer merely: “Do we have an API?” An existing API is often a fairly honest reflection of a product’s internal architecture. It knows projects, users, events, and objects because the database and application code know these things. But ideally, an agent does not think first in terms of our backend architecture, but in terms of the user’s intent.
Take a fictional CRM. From a developer’s perspective, five well-documented API calls might be perfectly logical for researching a contact, assigning the contact to their company, retrieving activities, creating a note, and then triggering a follow-up process. From an agentic perspective, however, the actually relevant capability might simply be: Prepare the next sensible follow-up for this account. Suddenly, it is no longer just about making existing endpoints available. You have to decide which product capability should be exposed as an understandable and safe unit.
That is Product Design.
Having an API Is Therefore a Long Way from Being Agent-Ready
I consider this one of the more interesting consequences of MCP because the first reaction of many software companies will probably be predictable: “No problem, we already have an API.”
Technically, that may be true. Strategically, it answers the same kind of wrong question as “But we have a website” used to when someone wanted to talk about SEO. Of course you need the website. But its mere existence does not answer whether Google can properly discover, understand, and categorize its content.
It could be similar with agents. What matters will not only be whether a machine can theoretically call an endpoint. What matters will be whether it reliably understands when, why, and with what consequences it should use a capability. As agents move closer from retrieving information to taking real actions, permissions, consent, and security boundaries also become increasingly important. The MCP architecture explicitly assigns the Host responsibilities around Permissions, Security Policies, and user authorization, and isolates Servers from one another. [modelconte...rotocol.io]
Incidentally, this is the point where MCP becomes particularly interesting to me: the best agentic interfaces may not necessarily be those with the most Tools. They could be those that have broken their product down most clearly into meaningful, bounded, and understandable capabilities.
For Product Teams, there is an uncomfortably good test hidden in this. If we have difficulty explaining precisely to an agent which capability our product offers, under what conditions it makes sense, and what result it produces, perhaps the problem is not with the agent at all. Perhaps we ourselves have not yet abstracted our product cleanly enough.
MCP Could Also Change Distribution
This is where the topic directly touches what we are already thinking about when it comes to AI Visibility. The first phase of the internet taught companies to build good digital experiences for humans. Search then created an additional requirement: content had to become discoverable and interpretable by search engines. Generative AI is shifting the question once again, because companies now have to figure out whether models even know their brand, their products, and their expertise and mention them in an appropriate context.
Agents add another layer to this.
At that point, being found is not necessarily enough. At some point, even being correctly understood and recommended may no longer be enough. If the user delegates a task to an agent, the software that gains an advantage is the software that can not only be described, but can actually be used in that context.
I would therefore think of this development in three stages: Search Visibility describes whether machines can find my offering. AI Visibility describes whether models understand what my offering is relevant for. Finally, Agent Availability describes whether an agent can access the capabilities of my product and act with them within meaningful boundaries.
That does not mean that MCP will automatically become the standard for every one of these interactions. Standards evolve, compete with one another, and change, and the MCP specification is also being developed further. The version from July 28, 2026, for example, describes optional Extensions alongside the core protocol, as well as a Capability model through which supported functions can be negotiated.
The strategic bet therefore does not even have to be “MCP wins.” The more interesting bet is this: software is increasingly getting a second user alongside the human.
And that user is a machine.
That’s Why I Wouldn’t Start With an MCP Server
If I wanted to prepare a SaaS product for this development today, I would not start by creating a ticket titled “Implement MCP.” In the worst case, that produces yet another technically correct interface that looks good on a list and that hardly anyone can use meaningfully. Instead, I would do a much more mundane product exercise.
I would write down the five or ten most important tasks that a user performs with the product. Then, for each task, I would ask: Would a user delegate this task, either fully or partially, to an agent? If so, the next step would be to determine what data the agent needs, which actions it is allowed to perform, when human consent is required, and what an unambiguous outcome looks like.
Only then comes the technical question.
Maybe the answer is MCP. Maybe the task first requires a better API. Maybe you realize that the workflow contains so many human decisions that an agentic integration currently offers no added value at all. That, too, would be a good outcome, because not every product gets better simply because you put an agent into it.
Sources
Model Context Protocol Specification, Version vom 28. Juli 2026: MCP-Grundmodell, Resources, Prompts, Tools und Extensions. [modelconte...rotocol.io]
Model Context Protocol Architecture: Host-Client-Server-Architektur, Security Boundaries und Verantwortlichkeiten des Hosts. [modelconte...rotocol.io]
Model Context Protocol Overview: Base Protocol, JSON-RPC und Capability-Modell. [modelconte...rotocol.io]