What Is the Model Context Protocol (MCP)?

Before the Model Context Protocol, every AI model needed its own custom integration for every tool. Claude had one way to talk to Postgres. GPT-4 had another. Cursor had another. If you built a database connector, you rewrote it for each platform. That’s the NM problem: N models times M tools equals NM integrations to build and maintain.

MCP fixes that. It’s an open protocol that standardizes how AI models connect to external tools and data sources. One integration works with any MCP-compatible model. The math becomes N+M instead of N*M. You build N servers (one per tool or data source) and M hosts (one per AI application). Each server works with every host. Each host works with every server. No custom adapters in between.

The USB-C Analogy

Think of it like USB before USB-C. Every device had its own cable. Phones, laptops, monitors, peripherals: each combination required a different connector. USB-C gave everyone a standard. Build a device with a USB-C port, and it works with any USB-C cable and any USB-C host.

MCP does the same for AI. Before MCP, every model-tool integration was custom. You built a Slack integration for Claude, then rebuilt it for ChatGPT, then again for Cursor. Same logic, different glue code every time. MCP is the standard port. Build an MCP server that exposes your tools or data, and any MCP-compatible host (Claude, ChatGPT, Cursor, Gemini, Copilot) can connect to it. One integration, many models.

The protocol is transport-agnostic. Servers can run locally over stdio (useful for development and desktop apps) or over HTTP (for remote and production deployments). The same server implementation works in both modes. You choose the transport based on where your tools run and how your host connects.

A Brief History

Anthropic announced the Model Context Protocol on November 25, 2024. They released the specification, SDKs in TypeScript and Python, and pre-built servers for Google Drive, Slack, GitHub, Postgres, and others. The goal was vendor-neutral from the start: MCP was designed to work with any AI model, not just Claude.

In December 2025, Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation, a new directed fund for agentic AI standards. The move formalized MCP as a neutral, community-driven project, similar to Kubernetes or PyTorch. The foundation was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, and others. Today, MCP is adopted by OpenAI, Google DeepMind, Microsoft, and integrated into ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code.

How MCP Is Structured

MCP uses a client-server architecture with three roles:

The Host is the AI application the user interacts with. Claude Desktop, Cursor, ChatGPT, or any other MCP-compatible app. The host runs the LLM and orchestrates the conversation.

The Client manages connections to MCP servers. It discovers available servers, maintains connections, and routes requests between the host and the servers. In many setups, the host application embeds the client.

The Server exposes tools and data. A Postgres MCP server lets the model query your database. A Slack MCP server lets it read channels and send messages. A file system server exposes directories. Servers run as separate processes and communicate over stdio or HTTP. You can run multiple servers at once, and the client aggregates them for the host. A single Claude session might have Postgres, GitHub, and a custom internal API all available as tools, each from a different server.

The key insight: the model never talks to servers directly. The host sends tool definitions and context to the model. The model returns tool calls. The host (via the client) executes those calls against the appropriate server and feeds results back. The model stays in the loop; execution stays in your infrastructure. This separation keeps the model sandboxed. It can request actions, but your code decides whether to execute them, with full control over validation, logging, and rate limiting.

The Three Primitives

MCP defines three primitives that servers can expose:

Tools are functions the model can call. Query a database, call an API, send a message, run a search. The model sees tool names and parameter schemas, decides when to call them, and returns structured arguments. Your code executes the call and returns the result. Tools answer: what can the model do? A Postgres server might expose query_database(sql: string) and list_tables(). A GitHub server might expose create_issue(repo, title, body) and search_code(query). The model chooses which tool to call based on the task.

Resources are read-only data objects. Database schemas, document contents, configuration files, anything the model needs as context. Resources are loaded by the client when relevant and injected into the model’s context. They answer: what does the model need to know? Unlike tools, resources are typically pulled in proactively. The client might load a schema resource before the model runs a query so it knows the table structure. Resources reduce the need for back-and-forth: give the model the right context upfront, and it makes better tool choices on the first try.

Prompts are reusable interaction templates. A server can expose parameterized prompts that guide the user or the model. “Summarize this document” with a document parameter. “Generate a PR description” with a diff parameter. Prompts answer: how can we structure common interactions? They’re useful when you want to standardize how users or applications invoke certain workflows across different hosts.

Most MCP servers focus on tools and resources. Prompts are less common but useful for standardizing workflows across applications.

Why It Matters for Developers

If you’re building AI applications, MCP reduces integration work. Write one MCP server for your internal API, and it works with Claude, ChatGPT, Cursor, and any other MCP host. No per-model glue code. No maintaining three versions of the same connector.

The ecosystem has grown fast. There are hundreds of public MCP servers for databases (Postgres, MySQL, SQLite), APIs (GitHub, Slack, Google Drive), file systems, and domain-specific tools. Many are open source. You can run them locally, extend them, or use them as reference implementations for your own servers.

For AI agents, MCP is the plumbing. Agents need tools to take action. Before MCP, every agent framework and every model had its own tool format. MCP gives agents a standard way to discover and invoke tools. The agent loop (think, act, observe, repeat) stays the same. The tool layer becomes interoperable. You can swap the underlying model or host without rewriting your tool integrations, as long as both speak MCP.

The Current Ecosystem

As of late 2025, MCP has achieved broad adoption. The SDK sees tens of millions of monthly downloads. There are thousands of public MCP servers covering databases, APIs, file systems, and domain-specific tools. Major AI applications (ChatGPT, Claude, Cursor, Gemini, Copilot) support MCP natively. Cloud providers including AWS, Google Cloud, and Microsoft Azure offer MCP-related infrastructure for production deployments.

The official MCP repository and community registries list servers for Postgres, MySQL, SQLite, GitHub, Slack, Google Drive, Notion, Puppeteer, and many more. If you’re starting a new AI project, check whether an MCP server already exists for your data sources. For common integrations, you can often plug in an existing server and focus on your application logic instead of building connectors from scratch. When no server exists, the MCP SDK (TypeScript or Python) gives you a clear pattern to implement one. The specification is open, and the protocol is designed to be extended without breaking existing clients.

When to Care About MCP

MCP matters most when you’re:

• Building tools or data sources that multiple AI applications should access
• Integrating AI into existing systems (databases, APIs, internal tools)
• Developing agents that need consistent tool access across different models
• Evaluating which AI applications to adopt (MCP support means easier tool integration)

If you’re only using a single model through a single API and not exposing tools, MCP might not affect you yet. But as agent use grows and tool integration becomes standard, MCP is the layer that makes it all connect. The protocol is still evolving, but the core primitives (tools, resources, prompts) and the client-server split are stable. Investing in MCP now means your integrations will work with an expanding set of hosts without rework.

Understanding MCP is part of building AI systems that work across models and platforms. Get Insanely Good at AI covers agent architectures, tool use, and how to design systems that leverage standards like MCP for production-ready AI applications.