Model Context Protocol (MCP) Explained for Developers

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems — data sources, tools and workflows — through one common interface. Anthropic open-sourced it on November 25, 2024, and it has since become the default integration layer between large language models (LLMs) and everything they need to touch: local files, databases, search engines, even a Figma design that Claude Code turns into a working web app. The protocol's official documentation sums it up as a USB-C (Universal Serial Bus Type-C) port for AI applications: implement the port once, and every compatible device just works.

The problem MCP solves

Before MCP, every AI application integrated every tool bilaterally. A coding assistant that needed GitHub, Postgres and Slack shipped three bespoke integrations; a second assistant needing the same three tools shipped three more. That is the classic M × N integration explosion — and it is why even the most capable models stayed trapped behind information silos and legacy systems.

MCP collapses the problem to M + N:

• MCP server — the program a tool or data provider implements once, exposing its capabilities through the protocol.
• MCP client — the piece an AI application implements once, to discover and use any MCP server.

Any client can then talk to any server. A provider maintains one connector instead of N bespoke ones, and an application supports an entire ecosystem instead of a hand-picked list.

How MCP works

The three primitives

An MCP server can expose three kinds of capabilities:

Transports: JSON-RPC under the hood

Under the hood, the protocol is JSON-RPC 2.0 (JSON Remote Procedure Call), carried over standard input/output (stdio) for local servers or streamable HTTP (Hypertext Transfer Protocol) for remote ones. The transport layer is also where the specification moved fastest: the 2026 revision made the protocol core stateless, which simplifies running remote servers at scale — but session handling written against the original stateful model needs revisiting.

A minimal server with the TypeScript SDK (Software Development Kit) looks like this:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
 
const server = new McpServer({ name: "weather", version: "1.0.0" });
 
server.tool(
  "get_forecast",
  { city: z.string() },
  async ({ city }) => ({
    content: [{ type: "text", text: await fetchForecast(city) }],
  }),
);

What changed between launch and this update

MCP's launch story and its current shape differ in ways that matter if you are building today:

The servers repository slimmed down

The modelcontextprotocol/servers repository on GitHub (roughly 90,000 stars) was long the go-to catalog. It now houses only a small number of reference servers — Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time — maintained by the MCP steering group. The servers most people actually used, from GitHub and PostgreSQL to Slack, Google Drive and Puppeteer, are archived; some found new homes (the Slack server is now maintained by Zencoder, and Brave Search was replaced by an official @brave/brave-search-mcp-server). To find servers today, browse the MCP Registry rather than the repository.

Note the repository's own warning: the reference servers are educational examples that demonstrate SDK usage, not production-ready solutions.

The specification itself moved twice

In 2026 the protocol dropped its stateful session model, and it has since reached a final spec whose client support arrived later. The latest published revision is dated 2026-07-28 — build against that, not against older tutorials.

Why adoption happened so fast

Three things lined up:

• Something to run on day one — the launch shipped with working SDKs and pre-built servers for enterprise systems like Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Block and Apollo integrated early; Zed, Replit, Codeium and Sourcegraph built support into their development tools.
• Genuine openness — MCP was created at Anthropic by David Soria Parra and Justin Spahr-Summers, but it was never locked to one vendor. When OpenAI and Google DeepMind added client support in 2025, MCP stopped being a vendor feature and became infrastructure.
• The agent shift — the timing matched the move from chatbots to agents. An agent is only as useful as the systems it can touch, and MCP made "touching systems" a solved problem. Integrated development environments (IDEs) keep racing to add agent capabilities — VS Code 1.128's multi-chat agent sessions are a recent example.

What to watch out for

MCP moves the integration problem; it does not remove the security problem:

• Least privilege — a server runs with real credentials against real systems. Scope its tokens to the minimum.
• Vet third-party servers — review what a server does before connecting it, and do not treat reference implementations as production-hardened.
• Human confirmation — keep it in front of destructive operations.
• Treat tool output as data — prompt injection through tool results remains an active research area. Whatever a tool returns is untrusted input, not instructions for the model.

What to do next

If you maintain a product that AI assistants should be able to use, shipping an MCP server is now the default way to make that happen:

1. Pick an SDK. Ten are official now — TypeScript, Python, Go, Java, Kotlin, C#, PHP, Ruby, Rust and Swift — and any language that can speak JSON-RPC can implement a server without one.
2. Run a reference server end-to-end. npx -y @modelcontextprotocol/server-memory (TypeScript) or uvx mcp-server-git (Python) starts one; on Windows, wrap npx with cmd /c. Then point a client such as Claude Desktop at it.
3. Target the current spec revision. The stateless transport model is the one clients are converging on; the 2026-07-28 revision is the one to read.
4. List your server on the MCP Registry. The old repository is no longer the discovery surface; the registry is.
5. Wire it into an agent. MCP is how coding agents reach a real repository — which is what separates an assistant that can read your code from one that can only talk about it.