What Is MCP (Model Context Protocol)? A Developer's Explainer

If you've built more than one AI-powered feature, you already know the pain MCP is trying to fix: every model, every tool, every data source needs its own glue code. Connect an LLM to a calendar API, and you write a connector. Swap the model provider, and you rewrite it. Add a second data source, and you write another one. Multiply that by every tool your app touches and you get a combinatorial mess of one-off integrations.

Model Context Protocol (MCP) is Anthropic's answer to that mess — an open standard, released in November 2024, that defines a consistent way for AI models to talk to external tools, data sources, and services. It's open-source, hosted at github.com/modelcontextprotocol, and it's not locked to Anthropic's own models. Any developer or platform can implement it, on either side.

The mental model people reach for is USB-C: one standard port, many compatible devices. Write an MCP server once, and any MCP-compatible client can use it without custom glue code.

The Four Pieces: Host, Client, Server, Tools

MCP splits responsibility into four roles:

• Host — the application the user actually interacts with. Claude Desktop is a host. Cursor is a host. The host manages the session and coordinates everything else.
• Client — a component inside the host that speaks MCP. A single host can run multiple clients, each wired to a different server.
• Server — a lightweight program exposing specific tools or data. A "Google Calendar MCP server" gives the client the ability to read and create events. A "filesystem MCP server" lets it read and write local files.
• Tools — the actual capabilities a server exposes. A calendar server might expose list_events, create_event, and delete_event as callable tools.

The request flow looks like this:

User message → Host
Host's Client asks the model what to do
Model decides to call a Tool
Client sends the request to the Server
Server executes it and returns a result
Model incorporates the result into its response

Communication happens over JSON-RPC, either via stdio (for local servers) or HTTP/SSE (for remote ones). Configuring a server in a host typically looks something like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    }
  }
}

The model sees the tools that server exposes as part of its available toolset and decides, mid-conversation, whether and when to call them.

MCP vs. the Old Way

Before MCP, integration work looked like this:

	Before MCP	With MCP
Per-tool integration	Custom plugin/API code for each AI + tool pair	Write one MCP server, any MCP host can use it
Switching AI providers	Rewrite integrations	Connections keep working
Protocol	Proprietary (e.g. OpenAI's deprecated plugin schema)	Standardized JSON-RPC
Small teams	Can't afford to support every AI platform	Ship one server, reach every compatible client

Custom GPTs are a related but different idea — they're contained inside the ChatGPT ecosystem and use a proprietary action schema. MCP is explicitly model-agnostic and cross-provider by design.

Why This Matters Beyond the Demo

For non-developers, MCP mostly works invisibly, but it's the plumbing behind an AI assistant that can read your actual email thread and draft a reply, check your real calendar and suggest a time that works, or query a live database instead of you copy-pasting rows into a chat window.

For developers, the more interesting case is coding tools. Editors like Cursor use MCP servers to give the model access to documentation, package registries, and test runners — without you manually pasting context into every prompt. That's part of a broader shift away from manual context-stuffing in prompts and toward models that pull what they need on demand. It also overlaps with how AI agents use tools mid-task — MCP is effectively the standardized tool-calling layer a lot of agent frameworks are converging on.

If you're deciding whether to build a plain API integration or an MCP server for a new tool, a rough rule of thumb: if only one AI product will ever call it, a direct API call is simpler. If you want any MCP-compatible client — present or future — to use it without you writing new glue code, build the MCP server.

FAQ

Is MCP made by OpenAI?
No. MCP was created by Anthropic and released as an open standard in November 2024. It's model-agnostic and not tied to any single AI company.

Do I need to install anything to use MCP?
As an end user, no — if your app (like Claude Desktop) supports MCP, you connect servers through its settings. Developers need to run or build an MCP server.

What's the difference between MCP and a regular API?
A traditional API is a direct integration written between two specific systems. MCP is a protocol that standardizes how AI models discover and call tools, cutting down on custom integration code per pairing.

Does MCP replace Custom GPTs?
No, they solve different problems. Custom GPTs are a no-code way to configure a ChatGPT assistant inside OpenAI's ecosystem. MCP is an open integration standard meant to work across AI providers.

Is MCP secure?
MCP servers run locally or on infrastructure you control, and the protocol specifies how permissions and tool schemas work — but actual security depends on the implementation. Running a server from an untrusted source carries the same risk as running any other third-party software.

Originally published at my-blog.org.