Model Context Protocol (MCP)
The MxN integration problem
Before MCP, every AI application that wanted to connect to external tools and data sources — a database, a file system, a project management tool, an internal API — had to write custom integration code for each one. If you had M different AI applications and N different tools, you potentially needed M x N separate integrations, each with its own authentication handling, data formatting, and error handling.
This is the same problem the software industry has solved before: USB standardized how peripherals connect to computers, ODBC standardized how applications connect to databases. Model Context Protocol (MCP), introduced by Anthropic in November 2024 as an open standard, does the equivalent for connecting AI models to tools and data. Instead of M x N custom integrations, you need M clients and N servers, each implementing MCP once — and any MCP-compatible client can talk to any MCP-compatible server.
Note
The client-server architecture
MCP defines three roles. The host is the AI application the user interacts with — a chat interface, an IDE, an agent framework. The host runs one or more MCP clients, each of which maintains a dedicated, stateful connection to a single MCP server. The server exposes capabilities — tools it can execute, data resources it can provide, and prompt templates it can supply — over a standardized interface.
This is a deliberate one-client-to-one-server design: rather than one client juggling many servers directly, each connection is isolated, which keeps security boundaries clean and makes it easy for a host to mix and match capabilities from many independent servers without them interfering with each other. An MCP server might wrap a database, a filesystem, a SaaS API like Slack or GitHub, or a set of internal company tools — the protocol doesn't care what's behind it, only that it speaks MCP.
Tools, resources, and prompts
MCP servers expose three kinds of capabilities to a connected client. Tools are functions the model can call to take action — run a SQL query, create a GitHub issue, send a Slack message — analogous to function calling, but discoverable dynamically from the server rather than hardcoded into the application. Resources are data the server can supply as context — a file's contents, a database schema, a document — that the host can attach to a conversation without the model having to explicitly "call" for it as an action. Prompts are reusable, parameterized prompt templates the server defines, letting a tool provider ship well-tested prompting patterns alongside their tool.
Critically, servers can also declare these capabilities dynamically and notify clients when they change — a server can tell a connected client "I now have three new tools available" without requiring the application to be restarted or reconfigured.
Transports: local and remote
MCP separates the protocol itself (a JSON-RPC 2.0 message format) from how those messages are physically transmitted, called the transport. The two standard transports are stdio — the client launches the server as a local subprocess and communicates over standard input/output, ideal for local tools like filesystem access or a local database — and HTTP with Server-Sent Events (streamable HTTP) — used for remote servers accessed over a network, which supports authentication, multiple simultaneous clients, and hosted deployments.
This flexibility is part of why MCP fits both individual developer setups (a local MCP server running on your laptop connecting Claude Desktop to your filesystem) and enterprise deployments (a centrally hosted MCP server exposing a company's internal APIs to every employee's AI assistant, with proper authentication and access control).
MCP vs. plain function calling
| Aspect | Plain function calling | Model Context Protocol |
|---|---|---|
| Integration effort | Custom code per app per tool (MxN problem) | Implement client/server once, reuse everywhere |
| Tool discovery | Hardcoded into the application at build time | Servers advertise capabilities dynamically at connect time |
| Scope | Actions only (functions the model can call) | Tools, data resources, and prompt templates |
| Portability | Tied to one model provider's function-calling format | Works across any MCP-compatible host or model |
| State/connection | Typically stateless per request | Stateful client-server session, supports live updates |
| Ecosystem effect | Every app reinvents integrations | Shared ecosystem of reusable servers across vendors |
Why it matters for agentic AI
The shift from single-turn chatbots to autonomous, multi-step AI agents made the integration problem far more urgent. An agent that's actually useful — one that can read your codebase, query your database, check your calendar, and update your project tracker in the course of a single task — needs a practical way to connect to dozens of different systems, without every agent framework and every tool vendor needing bespoke integration work with each other.
MCP addresses this by turning tool access into a shared, composable ecosystem: a developer builds an MCP server once for their product (a CRM, a monitoring tool, a design system) and it becomes usable by any MCP-compatible AI application, present or future, without either side needing to know about the other in advance. This is a big part of why MCP adoption accelerated so quickly through 2025 and into 2026 — it converts what used to be one-off integration work into infrastructure that compounds across the whole ecosystem, which is exactly what agentic AI needs to become broadly useful rather than perpetually limited by whatever integrations one vendor happened to build.
Note
What's next
MCP solves how an agent connects to external tools and data. The AI Agents lesson covers what happens on the other side of that connection — how an agent plans, decides which tools to call, and handles multi-step reasoning loops. If you haven't read it yet, that's the natural next step.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.