Every ML engineer who has shipped a production system knows the feeling: you build a beautiful model, design a clean serving layer, and then spend the next three weeks writing bespoke glue code to connect it to Slack, Google Drive, a Postgres database, and whatever internal tool the business team swears they can't live without.
That glue code — the custom connector — has been the silent tax on every AI project since GPT-3 made "let's just add AI to it" a viable product strategy. You write one connector per data source, per model, per deployment target. The math is brutal: N models × M data sources = N×M integrations to build and maintain.
Model Context Protocol kills that math.
Model A → [connector] → Slack Model A → [connector] → Google Drive Model A → [connector] → Postgres Model B → [connector] → Slack ← duplicate logic Model B → [connector] → Google Drive ← duplicate logic Model B → [connector] → Postgres ← duplicate logic
Model A → [MCP Client] → MCP Server (Slack) Model B → [MCP Client] → MCP Server (Slack) Same server. Zero duplication.
What MCP Actually Is
Anthropic introduced MCP in November 2024. The pitch is simple: a standardized JSON-RPC 2.0 protocol that defines how LLM applications talk to external data sources and tools. Think of it as the USB-C of AI integrations — one interface, every device.
The architecture has two sides. MCP Servers expose data and capabilities — a Google Drive server lets any MCP client search, read, and write files. MCP Clients are the LLM applications that consume those capabilities. Build a server once, and every client can use it. Build a client once, and it can talk to every server.
The protocol borrows heavily from the Language Server Protocol (LSP) that powers every modern IDE. If you've ever wondered how VS Code supports 50+ languages without writing 50 separate parsers — same idea, different domain.
Why It Matters for MLOps
For anyone building production AI systems, MCP changes the infrastructure conversation in three ways:
1. Context becomes portable. Your RAG pipeline, your vector store, your feature store — they can all expose themselves as MCP servers. Any model, any agent, any workflow can pull from them without custom integration code. This is huge for teams running multiple models across different use cases.
2. Agents get real tools. The agentic AI pattern — where models plan and execute multi-step tasks — has been limited by how hard it is to give agents reliable access to external systems. MCP standardizes tool calling, resource access, and prompt templates. An agent built on MCP can discover what tools are available at runtime, not just at build time.
3. Security gets a protocol-level answer. The November 2025 spec update formalized OAuth 2.1 authorization, resource indicators, and server identity verification. This isn't perfect — security researchers have flagged real attack vectors like tool poisoning and cross-server shadowing — but it's a foundation that custom connectors never had.
The Numbers
One year after launch, MCP has 97 million monthly SDK downloads across Python and TypeScript. Over 10,000 active servers. First-class client support in Claude, ChatGPT, Cursor, Gemini, Copilot, and VS Code. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Google, Microsoft, AWS, and others as co-founders.
That last point is the one that matters most. A protocol owned by one company is a product. A protocol governed by a neutral foundation is infrastructure. MCP just became infrastructure.
What I Would Build
If I were starting a new ML project today, here's how I'd think about MCP:
┌─────────────────────────────────────────┐
│ Agent / LLM Application (MCP Client) │
└────────────────┬────────────────────────┘
│ JSON-RPC 2.0
┌────────────┼────────────┐
▼ ▼ ▼
┌────────┐ ┌─────────┐ ┌──────────┐
│ Vector │ │ Feature │ │ Internal │
│ Store │ │ Store │ │ APIs │
│ Server │ │ Server │ │ Server │
└────────┘ └─────────┘ └──────────┘
Each data source gets an MCP server. The agent discovers them at runtime. When I add a new data source — say, a monitoring dashboard — I write one server, and every agent in the system can use it immediately. No redeployment. No connector code. No coordination across teams.
The Honest Caveats
MCP is not magic. The security model is still maturing. Tool poisoning — where a malicious server description manipulates an LLM into executing unintended actions — is a real and unsolved problem. The "S in MCP stands for security" joke exists for a reason.
Discovery and trust are also open questions. With 10,000+ servers, how do you know which ones are safe? The official registry helps, but the ecosystem is still young.
And there's the pragmatic question: if you're building a simple RAG app with one data source and one model, MCP is overhead you don't need. It shines when you have multiple models, multiple data sources, or a team that's tired of maintaining connector code.
Where This Goes
The pattern I'm watching is MCP + agentic workflows. The November 2025 spec added asynchronous operations and server-side agent loops — meaning an MCP server can spawn its own agents internally, coordinate their work, and return results. This turns MCP from a tool-calling protocol into a distributed agent coordination layer.
That's the real endgame. Not just connecting models to data, but connecting agents to agents, with a shared protocol that handles auth, discovery, and context passing.
We've been here before with APIs, with microservices, with LSP. Standardization always wins eventually. MCP is the bet that it wins for AI too.