The M×N integration problem and protocol necessity
Scenario
You've built an AI assistant that uses Claude to query your database, search Jira, and read Notion. Now your boss wants to swap Claude for GPT-4o. Suddenly, you have to rewrite all three tool integrations from scratch because OpenAI's tool format is slightly different than Anthropic's.
Given a choice between setting up a Vector Database or an MCP Server to store and query semantic embeddings directly, what should a developer choose?
Mental model
MCP is like USB for AI models: instead of building a custom plug for every single device, you build one standard port.
Before MCP, connecting 3 models to 3 tools meant writing 9 custom API integrations. Every model had its own way of describing tools, and every API had its own format. MCP creates a standard protocol in the middle. Tools just speak MCP. Models just speak MCP. Instead of an M×N web of custom scripts, you get an M+N standard architecture. Most importantly, MCP standardises *discovery*: the model can ask the tool 'what can you do?' at runtime.
Deep dive
The M×N integration problem happens when you try to scale AI architectures. If you have M models (Claude, GPT-4, Llama) and N data sources (Jira, GitHub, Slack), connecting them directly requires writing `M * N` custom API integrations. Every time you add a new model or a new tool, the integration code multiplies.
Direct API connections scale terribly, creating an M×N web of custom integration scripts.
A standard API connection is just a dumb pipe: you hardcode the exact endpoint, pass the exact JSON structure it expects, and parse the exact response. The Model Context Protocol (MCP) isn't just a different pipe; it's a standard *transport protocol* (like HTTP or USB) specifically designed for context.
MCP replaces custom API scripts with a universal, standardized transport layer.
Why standardise tool *discovery* instead of just execution? In a standard REST API, the developer hardcodes the tool's schema into the LLM prompt. With MCP, the host application dynamically asks the server 'what tools do you have?' and automatically translates them into the format the specific LLM needs. You write the tool once, and any MCP-compliant model can discover and use it instantly.
Standardizing discovery allows tools to be written once and instantly used by any MCP-compliant model.
Because MCP was initially demoed with Claude Desktop reading local codebases, many assume it's just for local files. But MCP is a universal transport: it works over local `stdio` for desktop apps, but also over Streamable HTTP for remote enterprise databases. It's a protocol for *all* context, not just local files.
MCP connects LLMs to local files via stdio AND remote databases via HTTP.
Crucially, MCP is purely a transport protocol. It standardises the connection to data, but it does NOT generate embeddings, orchestrate retrieval, or replace Vector Databases. You can run RAG over an MCP connection, but MCP is just the wire the data travels over.
MCP is the transport wire; it doesn't replace RAG or Vector Databases.
Code examples
The M×N nightmare: Custom integrations per model
# 1. Anthropic to GitHub
claude_github = {'name': 'search_repo', 'description': '...', 'input_schema': {...}}
# 2. OpenAI to GitHub
openai_github = {'type': 'function', 'function': {'name': 'search_repo', ...}}
# 3. Anthropic to Jira
claude_jira = {'name': 'get_ticket', 'description': '...', 'input_schema': {...}}
# 4. OpenAI to Jira
openai_jira = {'type': 'function', 'function': {'name': 'get_ticket', ...}}
# ... 9 unique scripts for 3 models and 3 tools.Without a protocol, you must manually translate the tool's expected schema into the specific JSON format demanded by every single LLM provider. (API shape verified against Anthropic/OpenAI docs)
The M+N solution: Standardized MCP connections
{
'mcpServers': {
'github-server': {
'command': 'npx',
'args': ['-y', '@modelcontextprotocol/server-github']
},
'jira-server': {
'command': 'npx',
'args': ['-y', '@modelcontextprotocol/server-jira']
}
}
}With MCP, the host environment configures standard connections to the tool servers. The host automatically handles discovering the tools and translating their schemas into the exact format the active LLM requires. You write 0 custom API wrappers.
Common mistakes
- Confusing MCP with RAG frameworks: Developers often assume MCP is an alternative to RAG used for retrieving documents and storing embeddings. Reality: MCP is just a transport protocol standardizing the connection. RAG is an architectural pattern that can operate over an MCP connection, but MCP itself doesn't generate embeddings or store vectors.
- Assuming MCP is only for local files: Because early demos featured Claude Desktop reading local files, many believe MCP only works over local `stdio`. Reality: MCP is a universal protocol that supports remote enterprise integrations via Streamable HTTP, connecting cloud LLMs to remote databases.
Glossary
- M×N integration problem
- The architectural nightmare where connecting M different AI models to N different tools requires writing M times N custom integration scripts.
- Model Context Protocol (MCP)
- An open standard transport protocol that standardises how AI applications securely connect to and discover external data sources and tools.
- tool discovery
- The ability for a system to programmatically ask an endpoint 'what capabilities do you have?' rather than hardcoding those capabilities in advance.
Recall questions
- What is the M×N integration problem in AI applications?
- Why standardize tool discovery rather than just execution?
- A developer needs to connect a cloud-hosted LLM to a remote Salesforce database and rules out MCP because they believe it only works over local stdio. What are they misunderstanding?
- Given a choice between setting up a Vector Database or an MCP Server to store and query semantic embeddings directly, what should a developer choose and why?
Questions & answers
What is MCP and why was it created?
Model Context Protocol (MCP) is an open standard that standardizes how AI models connect to external data sources and tools. It was created to solve the M×N integration problem, replacing custom, fragile API wrappers with a universal transport protocol that allows tools to be written once and instantly discovered and used by any compliant model.
Approach: Define MCP as a standard transport protocol. Highlight the transition from an M×N custom integration architecture to an M+N standardized architecture. Mention tool discovery.
How does MCP differ from a regular REST API?
A regular REST API is a custom pipe where the developer must hardcode the endpoint, manually map the data schema into the LLM's prompt, and handle the specific JSON execution format. MCP is a standardized protocol with built-in discovery (the system queries the server for its capabilities at runtime) and standardized JSON-RPC execution, eliminating custom prompt mapping.
Approach: Contrast hardcoded API integrations with dynamic discovery. Emphasize that MCP handles the translation of capabilities to the LLM automatically.
Continue learning
Previous: Function / Tool Calling