The M×N Problem of AI Integrations

Capsule description

Before understanding what MCP is, you need to feel the problem it solves. In this capsule you're going to discover why the current model of AI integrations is unsustainable: every AI tool needs custom integrations with every service, creating a combinatorial explosion that doesn't scale. If you have 5 AI hosts and 10 services, you need 50 different integrations — each with its own API, authentication, and maintenance.

This isn't a theoretical problem. It's what development teams live today: every time a new AI host appears (Claude Code, Cursor, Windsurf, Copilot) or a new service needs to connect, the workload multiplies. Understanding this problem is the first step to appreciating the solution.

What is the M×N problem?

The physical-world analogy

Imagine you're an international traveler in 2012. Every country has its own electrical plug:

🇺🇸 United States  → Type A (two flat pins)
🇬🇧 United Kingdom → Type G (three rectangular pins)
🇪🇺 Europe         → Type C (two round pins)
🇦🇺 Australia      → Type I (two diagonal pins)
🇯🇵 Japan          → Modified Type A

If you have 5 devices and travel to 4 countries, you need specific adapters for each combination. The number of adapters grows as M × N: M devices × N plug types.

That is exactly what happens today with AI integrations.

The problem in AI: every host × every service

Today there are multiple AI hosts (tools that use language models):

AI Hosts (M):
├── Claude Code (Anthropic)
├── Cursor (IDE with AI)
├── Windsurf (Codeium)
├── GitHub Copilot
└── Continue.dev

And multiple services that developers need to connect:

External services (N):
├── GitHub (repositories, PRs, issues)
├── Slack (messages, channels)
├── PostgreSQL (database)
├── Jira (project management)
├── Google Drive (documents)
├── Docker (containers)
├── AWS (cloud services)
├── Sentry (error tracking)
├── Linear (project management)
└── Notion (knowledge base)

Without a standard protocol: M × N integrations

                    GitHub  Slack  PostgreSQL  Jira  Google Drive
Claude Code           ✗       ✗       ✗        ✗        ✗
Cursor                ✗       ✗       ✗        ✗        ✗
Windsurf              ✗       ✗       ✗        ✗        ✗
GitHub Copilot        ✗       ✗       ✗        ✗        ✗
Continue.dev          ✗       ✗       ✗        ✗        ✗

Total: 5 hosts × 5 services = 25 custom integrations

Each ✗ is an integration that someone has to:

• Write — custom code for that specific pair (host + service)
• Maintain — update it when the service's API changes
• Test — verify it works with each version of the host
• Document — usage guides for each combination

Why M×N doesn't scale

The real cost

Imagine each integration requires:

• 40 hours of initial development
• 8 hours monthly of maintenance
• 1 dedicated developer per every 3 integrations

With 5 hosts and 10 services:

Total integrations: 5 × 10 = 50
Initial development: 50 × 40 hrs = 2,000 hours
Monthly maintenance: 50 × 8 hrs = 400 hours/month
Developers needed: 50 / 3 ≈ 17 developers

Now add 1 new AI host to the market:

New integrations: 1 × 10 = 10 more
Additional development: 10 × 40 = 400 hours
New monthly total: 60 × 8 = 480 hours/month

And if 1 new popular service appears:

New integrations: 5 × 1 = 5 more (one per host)

The problem grows multiplicatively. Each new host or service doesn't add — it multiplies.

Visualizing the growth: how M×N explodes

To make the difference visceral, let's see how the number of integrations grows as hosts and services are added:

Hosts  Services     M×N          M+N        Savings
─────  ─────────  ─────────    ─────────   ──────
  2        3          6            5          17%
  3        5         15            8          47%
  5       10         50           15          70%
  8       20        160           28          83%
 10       50        500           60          88%
 15      100      1,500          115          92%
 30      150      4,500          180          96%

The pattern is clear: with few hosts and services the difference is minor, but as the ecosystem grows, the difference becomes astronomical. With 30 hosts and 150 services (a conservative projection for 2027), the M×N model requires 25 times more implementations than M+N.

M×N vs M+N growth:

M×N (quadratic):
■
■ ■
■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
→ Explodes with each new host or service

M+N (linear):
■
■ ■
■ ■ ■
■ ■ ■ ■
■ ■ ■ ■ ■
→ Grows in a controlled and predictable way

The key point: today the ecosystem of AI hosts has ~10-15 serious players. If the history of technology is any guide (and it is), that number will multiply. Without a standard protocol, the cost of integrations will grow unsustainably. With a protocol, growth is linear and manageable.

Concrete example: your development team

Your team uses:

• Claude Code for development
• Cursor for quick editing
• GitHub Copilot for autocompletion

And needs to connect with:

• GitHub (repos and PRs)
• PostgreSQL (project database)
• Slack (communication)

Without a standard, your team needs 9 integrations — 3 AI hosts × 3 services. Each works differently, has its own configuration, and breaks independently.

Claude Code ←→ GitHub     (custom integration A)
Claude Code ←→ PostgreSQL (custom integration B)
Claude Code ←→ Slack      (custom integration C)
Cursor      ←→ GitHub     (custom integration D) ← Different from A
Cursor      ←→ PostgreSQL (custom integration E) ← Different from B
Cursor      ←→ Slack      (custom integration F) ← Different from C
Copilot     ←→ GitHub     (custom integration G) ← Different from A and D
Copilot     ←→ PostgreSQL (custom integration H) ← Different from B and E
Copilot     ←→ Slack      (custom integration I) ← Different from C and F

9 different integrations. Each written, maintained, and documented separately. And if you add a fourth service (Jira), you need 3 more integrations.

The problem from each perspective

The AI host provider's perspective

If you're Anthropic (Claude Code), Cursor, or any AI host:

"For my tool to be useful, I need to integrate with every
service that developers use. But every service has its
own API, authentication, and quirks.

GitHub uses OAuth + REST API.
Slack uses Bot Tokens + WebSocket.
PostgreSQL uses connection strings + SQL.
Jira uses API keys + REST API v3.

Each integration is a project in itself."

Result: AI hosts only integrate with the most popular services. Niche services get left out.

The service provider's perspective

If you're GitHub, Slack, or any service:

"For developers to use my service from AI tools,
I need to create integrations for every AI tool.

One for Claude Code.
One for Cursor.
One for Windsurf.
One for each new AI host that appears.

And each one is different because each host has its own way
of handling extensions."

Result: Services only invest in integrations with the most popular AI hosts.

The developer's perspective (you)

"I want to use my database from Claude Code. But there's no
official integration. I'd have to:

1. Read the Claude Code extensions documentation
2. Understand how to expose tools
3. Write code that connects to my database
4. Handle authentication, errors, permissions
5. Maintain everything when Claude Code updates

And if tomorrow I want the same in Cursor, I start from scratch."

Result: Developers settle for copy-pasting text between tools.

Concrete scenarios you live today

The problem isn't abstract. These are scenarios that happen daily on development teams:

Scenario 1: Fragmented debugging

You're debugging a production error. You need to:

1. See the logs in Datadog
2. Query the database for the affected user's state
3. Review the commit that introduced the change in GitHub
4. Search whether anyone reported the issue in Slack

Without integrations, you do this manually — copying and pasting between 4 browser tabs while your AI assistant can only see the local code. With integrations, you'd tell Claude Code "investigate the 500 error for user X" and it would have access to all the context.

Scenario 2: Painful onboarding

A new developer joins the team. They need to understand:

• The system architecture (documented in Notion)
• The active tickets (in Linear)
• The database structure (in PostgreSQL)
• The team's code patterns (in GitHub)

Without integrations, the new developer spends days navigating between tools. With integrations in their AI coding assistant, they could ask "which are the main services and how do they communicate?" and get an answer with real project context.

Scenario 3: Manual deploy

Every Friday you deploy. The process includes:

1. Verifying that all tests pass (CI/CD)
2. Reviewing pending PRs (GitHub)
3. Notifying the team (Slack)
4. Deploying (AWS/Vercel)
5. Verifying that everything works (monitoring)

Imagine telling Claude Code: "Prepare the Friday deploy" and having it review tests, PRs, notify the team, and deploy — all through MCP servers connected to each service. That's possible when you have a standard protocol.

The historical pattern: this has happened before

This problem isn't new. The technology industry has gone through this cycle multiple times: a fragmented ecosystem grows until the pain is unsustainable, and then a standard emerges to unify it.

USB before USB-C

Year 2010 — The connector chaos:
├── Apple    → Lightning (iPhones)
│              MagSafe (MacBooks)
│              30-pin (old iPads)
├── Samsung  → Micro-USB (Android phones)
│              Micro-USB 3.0 (tablets)
├── Nokia    → Proprietary DC-4 connector
├── Sony     → Proprietary connector
├── Laptops  → Barrel jack (different per brand and model)
└── Cameras  → Mini-USB (yet another variant)

Result: A drawer full of different cables.
Every trip meant carrying 5+ cables.
Lending a charger was impossible.

Year 2024 — After USB-C:
├── Apple    → USB-C (iPhones, MacBooks, iPads)
├── Samsung  → USB-C (phones, tablets)
├── Everyone → USB-C (laptops, cameras, headphones, Switch)

Result: One cable works with everything.
One charger for all devices.
Sharing cables is trivial.

The standard unified the ecosystem. Before USB-C, the European Union had to legislate to force a common standard — that's how serious the problem was. The pressure came from frustrated users, regulators, and the industry itself recognizing that fragmentation was unsustainable.

APIs before REST

Year 2000 — The API chaos:
├── SOAP (complex XML, huge WSDLs, strict typing)
│   └── Each integration required generating code stubs
├── XML-RPC (simpler than SOAP, but different)
│   └── Incompatible with SOAP despite using XML
├── CORBA (Common Object Request Broker Architecture)
│   └── Complex, heavy, hard to debug
├── COM/DCOM (Component Object Model, Windows only)
│   └── Microsoft proprietary, platform-lock
└── Proprietary protocols (each company invented its own)

Result: Each integration between systems was a research
project of weeks. Developers spent more time
learning the protocol than implementing the logic.

Year 2010+ — After REST:
├── REST (HTTP + JSON, predictable endpoints)
│   └── GET /users, POST /users, PUT /users/:id
│   └── Any developer knows how to use it in minutes
│   └── Every language has an HTTP client
│   └── Tools like Postman make testing trivial

Result: Integrating with a new service takes hours, not weeks.
Documentation is consistent. Tools are shared.

REST didn't solve every problem (GraphQL emerged later for more complex cases), but it dramatically reduced the barrier to entry for integrations. A developer can consume a new REST API in minutes, not days.

Data before JSON

Year 2005 — The format chaos:
├── XML (verbose, complex, hard to parse)
│   └── <user><name>John</name><age>30</age></user>
│   └── Required DTDs, schemas, namespaces
├── CSV (no structure, no types, ambiguous)
│   └── John,30 — what is each field?
├── Proprietary formats (each company had its own)
│   └── Binaries incompatible between systems
└── Protocol Buffers (efficient but only used by Google)
    └── Required schema compilation

Result: Parsing data was half the work of any
integration. Each format had its own libraries and quirks.

Year 2015+ — After JSON:
├── JSON (simple, readable, universal)
│   └── {"name": "John", "age": 30}
│   └── Native support in every language
│   └── JavaScript parses it automatically
│   └── Abundant visualization tools

Result: Data exchange became trivial.
Nobody thinks about "which format to use" — it's JSON by default.

The common pattern

In each case, a standard solved the problem:

• USB-C replaced dozens of connectors → one cable for everything
• REST simplified APIs → one predictable pattern for everything
• JSON became the universal format → one format for everything

MCP is that moment for AI integrations. The fragmentation problem already exists. The pain is already real. And MCP is the standard that's emerging to solve it — with the advantage of arriving at a moment where the industry already knows the pattern and adopts it faster.

The key difference with MCP vs the earlier standards: MCP didn't need regulation (like USB-C with the EU) or years of a standards war (like REST vs SOAP). Anthropic released it as open source from day one, and organic adoption was almost immediate. That says a lot about how obvious the problem was.

Comparison: Custom Integrations vs Standard Protocol

With 5 hosts and 10 services:

• M×N = 50 integrations
• M+N = 15 implementations (5 clients + 10 servers)

Savings: 70% less code. And the difference grows with each new host or service.

Conceptual troubleshooting

"Isn't REST enough?"

REST APIs standardize how services expose data. But they don't standardize how an AI host discovers, connects to, and uses those services. REST tells you "speak HTTP," but it doesn't tell you "this is how an AI tool discovers what your service can do, with which permissions, and how to invoke functions."

MCP goes one level up: it standardizes the interface between AI hosts and services, including capability discovery, permissions, and interaction types. Your MCP server can use REST internally, but the way the AI host discovers and uses it is standard.

"Why not use plugins like ChatGPT?"

ChatGPT plugins solved part of the problem, but they're proprietary to OpenAI. They only work in ChatGPT. If tomorrow your team switches from ChatGPT to Claude Code, all the integrations are lost. MCP is an open protocol that works in any AI host that implements it — Claude Code, Cursor, Windsurf, and any future host. Your MCP servers are portable.

"Is the M×N problem really that serious?"

Today there are ~10 serious AI hosts and hundreds of services. The problem is already real. But think 2-3 years out: there will be 50+ AI hosts and thousands of services. Without a standard, the fragmentation will be unsustainable. Early adopters of MCP will be prepared; the rest will start from scratch.

"Couldn't AI hosts just improve their integrations?"

They could, but that doesn't solve the problem — it moves it. Each AI host that improves its integrations only improves its own. Developers are still stuck with integrations that only work in one host. The problem is structural, not one of implementation quality. Only a standard protocol solves the problem structurally.

"And if MCP doesn't win? Am I betting on the wrong horse?"

It's a valid question, but look at the signals: MCP has adoption from every major AI host except OpenAI (which has its own proprietary approach). Anthropic created it but it's open source. The historical pattern is clear — open protocols eventually win over proprietary ones (HTTP vs proprietary protocols, JSON vs proprietary formats, USB-C vs proprietary connectors). Even if MCP evolves significantly, the concepts you learn are transferable.

Exercises

Exercise 1: Calculate the M×N cost (Easy)

Your company uses 3 AI hosts (Claude Code, Cursor, Copilot) and needs to connect with 7 services (GitHub, Slack, PostgreSQL, Jira, AWS S3, Redis, Elasticsearch).

Calculate:

1. How many custom integrations are needed with the M×N model?
2. How many implementations are needed with a standard protocol (M+N)?
3. What is the percentage savings?

Exercise 2: Identify integrations in your day-to-day (Medium)

List 3 AI tools you use or know and 5 services you'd like them to integrate with. Draw the M×N matrix and calculate how many integrations would be needed.

              GitHub  Notion  PostgreSQL  Vercel  Figma
Claude Code     ✗       ✗        ✗         ✗       ✗
Cursor          ✗       ✗        ✗         ✗       ✗
ChatGPT         ✗       ✗        ✗         ✗       ✗

Exercise 3: Analyze the vendor's perspective (Medium)

You're the CTO of a startup building a new AI coding assistant. Your tool needs to integrate with the 10 most popular services among developers.

1. How many integrations do you need to build with the M×N model?
2. How much time would you estimate (40 hrs per integration)?
3. How does it change if you adopt MCP?

Exercise 4: Predict the scale of the problem (Hard)

In 2024 there are ~10 serious AI hosts and ~50 services that developers commonly use. Estimate that in 2027 there will be 30 AI hosts and 150 services.

1. Calculate the total M×N integrations in 2024 and 2027
2. Calculate the total with M+N in 2024 and 2027
3. What is the difference in growth?

Exercise 5: Map the real cost in your team (Medium)

Imagine your team has 2 AI hosts and 4 services they need to integrate. Calculate:

1. Total M×N integrations
2. If each integration takes 40 hours of development and 8 hours/month of maintenance, how many initial development hours and how many monthly maintenance hours?
3. If they add a third AI host, how many additional development hours and monthly maintenance are added with M×N?
4. How much would be added with M+N?

Exercise 6: Debate — when is M+N NOT worth it? (Hard)

The M+N model (standard protocol) isn't always better. Think of at least 2 scenarios where custom integrations (M×N) could be the better option. Justify each one.

Summary

In this capsule you learned:

• The M×N problem: every AI host needs custom integrations with every service, creating a combinatorial explosion
• It doesn't scale: adding a host requires N new integrations; adding a service requires M new integrations
• The problem is real: it affects AI host vendors, service providers, and developers in their day-to-day
• Visualizing the growth: M×N grows quadratically, M+N grows linearly — the difference amplifies with scale
• It's happened before: USB-C solved the connector problem; REST solved the API problem; JSON solved the data-format problem
• A standard protocol reduces M×N to M+N — a savings that grows exponentially with scale
• With 5 hosts and 10 services: from 50 integrations to 15 implementations (70% less)
• There are scenarios where M×N is valid (critical performance, a single trivial integration), but they're the exception

Next capsule: MCP: The USB-C of AI — how the Model Context Protocol solves exactly this problem with an open and standard protocol.

Additional resources

1. Model Context Protocol — Specification - Full technical specification
2. The USB-C Standard Explained - Real analogy: how USB-C unified connectors
3. Why Open Protocols Win - Joel Spolsky on why open standards dominate
4. REST API Design - How REST solved the M×N problem of APIs
5. MCP: Connecting AI to Everything (Anthropic) - Anthropic's official vision
6. The Integration Problem in Enterprise AI - Analysis of the problem at enterprise scale