How We'll Connect 500 Tools by 2027: The Open Connector Roadmap

By Maxime Champoux

The average mid-market company uses 130 SaaS applications. Each one holds a slice of the business: customer data in the CRM, invoices in the accounting tool, contracts in the document manager, conversations in the helpdesk. The connections between these tools are still built the way they were in 2015. Custom integrations, point-to-point, maintained by hand. It doesn't scale. It never did.

We have 120+ MCP connectors live today. The target is 500 by 2027. This isn't a marketing number. It's an engineering bet, and I want to explain exactly how we plan to get there, what's genuinely hard about it, and why the math works.

The problem with building connectors one at a time

Traditional integration platforms build each connector as a standalone project. A team reads the API docs, writes the mapping logic, handles authentication, tests edge cases, and ships it. That cycle takes two to six weeks per connector, depending on the API's complexity and documentation quality.

At that pace, reaching 500 connectors would require roughly 15 engineer-years of dedicated work. The economics don't hold. The long tail of business tools means most connectors serve a small number of users. You can't justify six weeks of work for a connector that serves twelve customers.

This is why most integration platforms plateau around 200-300 connectors and then slow down. The marginal cost of each new connector stays constant while the marginal value decreases. It's a losing curve.

An engine, not a team

We built something called the Dynamic Connector Registry. The core idea: most modern SaaS tools publish an OpenAPI specification describing their API endpoints, data models, and authentication methods. The DCR reads that spec and auto-generates a working MCP server.

Today, about 70% of OpenAPI specs convert cleanly into functional connectors without manual intervention. The other 30% need human attention, usually because of non-standard authentication flows, undocumented rate limits, or data models that don't map well to MCP's protocol structure.

That 70% conversion rate changes the math entirely. Instead of six weeks per connector, we're looking at hours. An engineer reviews the auto-generated output, tests the critical paths, and publishes. The cost per connector dropped by roughly 90%.

But I want to be honest about what "70% convert cleanly" actually means. It means the happy path works. CRUD operations on standard resources, basic filtering, pagination. It does not mean every edge case is covered. Some APIs have deeply nested object models that require custom serialization. Others use webhook-based flows that don't fit into a request-response pattern. Authentication alone is a category of problems: OAuth 2.0 with PKCE, API keys with custom header schemes, mutual TLS, SAML-based tokens. Each flavor adds work.

Three lanes to 500

The roadmap runs three parallel tracks.

Lane one: design partner connectors. Built by our team, prioritized by what our design partners actually need. When a customer says "I need my AI assistant to read data from Exact Online" or "I want to reconcile invoices from Mollie," that goes to the top of the queue. These connectors get the most testing, the most polish. Roughly 80-100 will come from this lane.

Lane two: community connectors. Later this year, we're publishing the DCR as a development tool. Third-party developers, consultants, agencies, and internal teams at larger companies will be able to generate and publish their own connectors. We handle the registry, the distribution, the quality baseline. They bring the domain expertise. If someone builds accounting software in Norway, they know their own API better than we ever will. This lane could contribute 150-200 connectors by 2027.

Lane three: automated discovery. Public API registries like APIs.guru, SwaggerHub, and RapidAPI catalog thousands of OpenAPI specifications. We're building a crawler that discovers new specs, runs them through the DCR, and flags the ones that convert cleanly for human review. This is the long tail: the tools no one specifically requested but that someone, somewhere, will need. Another 150-200 connectors from this lane.

Combined: 80-100 from our team, 150-200 from community, 150-200 from automated discovery. That's the path.

What's genuinely hard

I don't want to pretend this is a solved problem.

Auth is a mess. Every API authenticates differently. Even APIs that claim to support OAuth 2.0 implement it with enough variation that each one needs testing. Some require client credentials in the body, others in the header. Some refresh tokens expire after 30 days, others after 24 hours, some never. We've built an auth abstraction layer, but it doesn't eliminate the work. It makes it more predictable.

Documentation quality varies wildly. The DCR is only as good as the OpenAPI spec it ingests. Some companies publish specs that are incomplete, outdated, or simply wrong. Fields marked as optional that are actually required. Endpoints listed in the spec that return 404. Response schemas that don't match the actual response. We've added a validation layer that catches the most common issues, but garbage in still produces garbage out.

Maintenance at scale. Building 500 connectors is one thing. Keeping them running is another. APIs change. Endpoints get deprecated. Rate limits shift. A connector that worked last month might break today because the vendor updated their API without bumping the version. We need automated health checks, regression testing, and a fast path to fix broken connectors. This infrastructure is as important as the connectors themselves.

Data mapping edge cases. MCP defines a standard way to expose tools and resources. But not every API concept maps cleanly to that model. Batch operations, streaming responses, long-running async jobs, file uploads with multipart forms: each requires special handling the auto-converter can't always infer from a spec alone.

Why connector count is the wrong metric (and the right one)

Five hundred is a useful milestone for tracking progress and setting engineering targets. But the number that actually matters is coverage: the percentage of tools our customers use that we can connect to.

Right now, when we onboard a new design partner, we can typically connect 60-70% of their tool stack on day one. The remaining 30-40% requires building new connectors or customizing existing ones. The goal is to flip that: 90% coverage on day one, with the last 10% handled within a week.

If we hit 500 connectors and still only cover 60% of customer tool stacks, we picked the wrong 500. The number only matters if it maps to real usage. That's why the design partner lane comes first. We're not optimizing for the largest catalog. We're optimizing for the broadest coverage of tools our customers actually rely on. Community and automated discovery extend that coverage into the long tail, but the core is driven by demand.

This distinction matters for a deeper reason. When an AI agent uses a connector, it needs structured, reliable data every time. There's no human in the loop to catch a malformed response. A Zapier integration can afford to be 95% reliable because a person reviews the output. An MCP connector serving an autonomous agent needs to be 99.9% reliable or the entire workflow breaks. Quality gates on every connector aren't optional. They're the foundation.

The network effects case

The Model Context Protocol is becoming the standard way AI models interact with external tools. Anthropic published it, and the ecosystem adopted it faster than most open standards gain traction. The reason is timing: every company building AI agents needs a way to connect those agents to business data, and MCP provides a clean interface for that.

The companies that build the widest connector coverage early will hold a structural advantage. When an AI agent needs to access a tool, it looks for an MCP server. If that server exists in your registry, the agent uses your infrastructure. If it doesn't, the agent looks elsewhere. Connector coverage becomes a distribution channel.

This mirrors what happened with Zapier in the no-code era. Zapier didn't win because any single integration was technically superior. They won because they had more integrations than anyone else, which attracted more users, which attracted more integration partners. Breadth created a flywheel.

The same dynamic applies here, with one important difference: opening the DCR to community developers doesn't just add connectors. It creates a contributor ecosystem with its own momentum. Every external developer who builds a connector makes the registry more valuable for every user. Every new user makes building a connector more worthwhile for developers. That loop, once it starts, compounds.

There's a second-order effect worth noting. As the connector count grows, the data flowing through those connectors generates signal about how businesses actually use their tools together. Which combinations appear most often. Which workflows cross three or four systems. That usage data informs what to build next, creating an information advantage that's hard to replicate from the outside. The registry becomes smarter with every connection made through it.

Where this is going

The end state is straightforward: every business tool accessible through one protocol. One standard for authentication, data access, and action execution. No more custom integrations, no more point-to-point connections, no more integration tax.

The 120+ connectors live today are a starting point. The DCR gives us the engine to scale. The community gives us reach into tools we'd never prioritize on our own. Automated discovery fills the gaps.

Five hundred connectors by 2027 is a function of the conversion rate, community adoption, and the discovery pipeline. The math works. The engineering is underway. The hard parts are real but bounded.

At Well, we're building this because our customers need their AI to work with every tool they already use. That's the bar, and that's what we're shipping toward.