MCP Is the USB-C of Business Software, and We're Building the Hub
Open the cable drawer in any office and you'll find it — a tangle of USB-A, Mini-USB, Lightning, Micro-USB, and whatever proprietary connector the last hardware vendor decided the world needed. Each cable solved a problem. Together, they created a new one.
The business software stack looks exactly the same. Stripe has an API. QuickBooks has an API. Slack has an API. Salesforce has an API. Each connector solves a problem. Together, they've created an integration landscape so tangled that the average mid-market company spends $500,000 per year just maintaining the connections between its tools.
Then Anthropic released the Model Context Protocol, and something shifted.
What MCP Actually Changes
MCP is a standard protocol that lets AI models talk to external tools and data sources. One interface, many connections. Like USB-C for software.
Before MCP, every integration was bespoke. Want your AI to read your CRM? Build a custom connector. Want it to check your bank balance? Another connector. Want it to search your documents? Another one. Each connector had its own authentication flow, its own data format, its own error handling.
MCP replaces that with a single protocol. A tool that speaks MCP can connect to any AI model that speaks MCP. The promise is the same as USB-C: one cable, every device.
But here's the catch.
The Lesson USB-C Already Taught Us
USB-C was ratified in 2014. It took nearly a decade for it to become genuinely universal. Apple held onto Lightning until 2023. Many devices shipped USB-C ports that only supported USB 2.0 speeds. The standard existed; the ecosystem lagged behind.
Why? Because a standard without infrastructure is just a document. USB-C needed chipmakers, cable manufacturers, and device OEMs to tool up their factories. The spec was necessary. It wasn't sufficient.
MCP could easily suffer the same fate. The protocol is elegant. The spec is clean. But if every company has to build and maintain its own MCP server, we've just renamed the problem. Instead of "integration engineering," we'd call it "MCP server engineering." Different label, same drawer full of cables.
The real question isn't whether MCP is a good standard. It is. The real question is: who builds the hub?
The Hub-vs-Spoke Dynamics
Think about what USB-C actually needed to succeed at scale. It wasn't just the spec — it was the entire ecosystem of chipmakers, cable manufacturers, and device OEMs who tooled up their factories. The invisible infrastructure.
In the MCP world, the equivalent is a Meta-MCP layer — a single hub that aggregates many MCP servers behind one interface. A company that connects to one hub gets access to every tool the hub supports. A model that connects to one hub can reach every data source behind it.
This is how network effects compound in infrastructure. Each new connector added to the hub makes it more valuable for every existing user. Each new user makes it more worthwhile to add connectors.
The hub owner also captures something more subtle: data gravity. When all your integrations route through one point, that point accumulates operational context. It knows which tools you actually use, how your data flows between systems, and where the bottlenecks are.
The Honest Complexity
I want to be direct about something that most infrastructure pitches gloss over: building the hub is extraordinarily hard.
It's not a technical problem in the way people think. Wrapping an API in MCP is straightforward. The hard part is maintaining 200+ connectors against APIs that change without warning, handling authentication across a maze of OAuth flows and API key schemes, managing rate limits that differ by provider, and gracefully degrading when a third-party service goes down at 2 AM on a Saturday.
I know because I've lived it. At Qonto, we maintained maybe 30 integrations. Each one had a dedicated engineer who knew its quirks. When Stripe changed their webhook format, we found out at 3 AM. Multiply that by 200+ and you start to understand why most companies don't even try.
The unsexy truth about infrastructure is that the moat isn't in the architecture diagram. It's in the operational grind of keeping everything running, every day, across hundreds of external dependencies that you don't control.
What the Hub Actually Looks Like
A true Meta-MCP hub needs three capabilities that go beyond basic protocol compliance.
First, a Dynamic Connector Registry. You can't hand-code 500 integrations. You need a system that can ingest an OpenAPI spec or REST API documentation and automatically generate an MCP-compliant server. This converts the integration problem from an engineering task to a configuration task.
Second, smart routing. When a model asks for "last quarter's revenue data," the hub needs to know whether that request should go to your ERP, your accounting system, or your data warehouse. This isn't just pattern matching — it's understanding the topology of your business tools.
Third, bidirectional data exposure. The hub shouldn't just connect AI models to tools. It should expose your business data as an MCP server, so any AI can query your financial stack through one standardized interface. This is the difference between a one-way adapter and a two-way bridge.
The Infrastructure Play No One Is Talking About
Most of the conversation around MCP focuses on developers — how to build MCP servers, which SDKs to use, how to test compliance. That's the equivalent of debating USB-C pin configurations while ignoring the fact that someone needs to build the charging stations.
The real prize isn't the protocol layer. It's the operational layer — the company that makes MCP adoption effortless for businesses that don't have protocol engineers on staff.
This is a pattern we've seen before. Stripe didn't invent online payments. They made them easy. Twilio didn't invent SMS APIs. They made them easy. The value wasn't in the standard — it was in collapsing the implementation complexity so that anyone could use it.
The MCP hub is the same play. The standard exists. The tooling doesn't — at least, not at the scale businesses need.
Where This Goes
I'll show my hand. At Well, we've built a Meta-MCP Proxy that currently connects to 120+ tools through a single interface, with a Dynamic Connector Registry targeting 500+. We expose business data as an MCP server, making your entire financial stack accessible to any AI model through one protocol.
We're building the hub because we've lived the alternative, and the alternative is a drawer full of cables that costs millions to maintain and still doesn't work properly.
The USB-C moment for business software isn't coming. It's here. The question is whether your company will be the one tangled in cables or the one that plugged in once and moved on.
— Maxime Champoux, co-founder and CEO of Well

Maxime Champoux
CEO & co-founder, Well
Maxime is the CEO and co-founder of Well. He built Well to rebuild finance around AI-native data, not spreadsheets.
LinkedInReady to automate your financial workflows?


