MCP — Model Context Protocol

Status: 🟩 COMPLETE (🟦 LIVING — the ecosystem grows weekly) Last updated: 2026-06-19 Plain-English tagline: A standard way for any AI agent to use any tool. Like USB-C for AI. Build one MCP server for your service; every major LLM client can use it.

In plain English

Before MCP existed, every AI assistant that wanted to connect to an external service (Slack, GitHub, your database, Figma) needed a custom integration. The team building ChatGPT had to write their own Slack connector. The team building Cursor had to write their own. Anthropic had to write their own. Every new service multiplied the work.

Model Context Protocol (MCP) changes that. It defines a standard format for “tools an AI can use.” If you build an MCP server for your service, any MCP client can use it — Claude Desktop, Claude Code, Cursor, ChatGPT, the OpenAI Agents SDK, and many more all speak MCP natively in 2026.

The analogy from Anthropic: MCP is “USB-C for AI.” Before USB-C, every device had a different connector — proprietary, painful, locked in. After USB-C, one cable works with everything. MCP is the same idea for AI tool integration.

Introduced by Anthropic in November 2024 and now (since December 2025) governed by the Linux Foundation, MCP is genuinely cross-vendor — supported by Anthropic, OpenAI, and Google DeepMind. Over 500 public MCP servers exist; over 15,000 GitHub repos use the mcp-server topic.

Why it matters

Three reasons:

For users (you), MCP is why “add this service to my AI” usually just works in 2026. You install an MCP server for the service, point your client at it, and the AI can suddenly do everything that service exposes — without any vendor having built a custom integration.
For developers, MCP collapses N×M integration work into N+M. If 10 AI clients each want to integrate with 100 services, that’s 1000 custom integrations without MCP. With MCP, it’s 100 servers + 10 clients = 110 total. Vastly less work.
It’s an open standard, not Anthropic-controlled. Linux Foundation governance means OpenAI, Google, Amazon, and others contribute. This is the strongest signal that MCP is the long-term answer to tool integration.

The architecture

MCP has three roles:

┌────────────────┐    MCP protocol   ┌──────────────────┐
│  MCP client    │ ◀───────────────▶ │  MCP server      │
│  (the LLM /    │                   │  (your tools)    │
│  agent that    │                   │                  │
│  wants tools)  │                   │  Connects to:    │
│                │                   │  - Your DB       │
│  e.g. Claude   │                   │  - Slack         │
│  Code, ChatGPT │                   │  - GitHub        │
└────────────────┘                   │  - Filesystem    │
                                     │  - Anything      │
                                     └──────────────────┘

Role	What it is
MCP server	A program that exposes tools (and optionally resources and prompts) to AI clients. You write one per service.
MCP client	The AI application that consumes MCP servers. You install clients; they connect to servers.
MCP protocol	The JSON-RPC-based wire format the two speak. Defined publicly; SDKs exist for Python, TypeScript, and others.

A single client can connect to many servers simultaneously. Claude Code in your setup is already a client of many MCP servers (computer-use, claude-preview, claude-in-chrome, ccd-session-mgmt, Canva, scheduled-tasks, others).

A single server can serve many clients. The same Slack MCP server works for Claude, ChatGPT, Cursor, etc.

What an MCP server actually exposes

Three categories:

Tools (the most common)

Functions the AI can call. Same shape as tool use — name, description, input schema.

slack_send_message
  description: "Send a message to a Slack channel"
  input: { channel: string, text: string }

slack_list_channels
  description: "List all channels in the connected workspace"
  input: {}

Resources

Read-only data the AI can fetch — files, database rows, documentation. The AI requests a resource by URI.

postgres://db/tables  → the list of tables
postgres://db/tables/users/schema  → the users table schema

Prompts

Pre-written prompt templates the user can invoke by slash command. Useful for “run this canned analysis” workflows.

A concrete example: the Slack MCP server

Imagine a Slack MCP server. It exposes:

Tools:

slack_list_channels — list channels in the workspace
slack_send_message — send a message
slack_search_messages — search history
slack_get_user — look up a user

Resources:

slack://workspace/info — workspace metadata
slack://users/{id} — a specific user’s profile

You install the server with one command (e.g. claude mcp add slack). Claude Code now sees these tools and can be asked things like:

“What did Sarah say about the deploy yesterday?” → Claude calls slack_search_messages
“Tell #eng we’re shipping the dashboard at noon.” → Claude calls slack_send_message (probably after asking you to confirm)

You didn’t write any of this. Anthropic, the Slack team, or a community contributor built the MCP server once; you and everyone else benefit.

Real MCP servers worth knowing about

A small sample from the 500+ available:

Domain	Server	What it gives the AI
Files	Filesystem	Read/write files in a sandboxed root
Git	Git, GitHub	Branch operations, PRs, issues, code search
Databases	Postgres, MySQL, SQLite	Query, schema introspection
Communication	Slack, Gmail, Discord	Send messages, read history
Knowledge	Notion, Linear, Confluence	Search, create pages, update tickets
Design	Figma, Canva	Read designs, generate variants
Browsing	Chrome (Claude_in_Chrome), Playwright	Drive a real browser
Calendar	Google Calendar, Outlook	Schedule, find conflicts
Storage	Google Drive, Dropbox, S3	Read/write objects
Productivity	Jira, Trello, Asana	Manage tasks
Infrastructure	Docker, Kubernetes, AWS	Deploy, scale, inspect
Computer control	computer-use	Take screenshots, click, type

Plus thousands more for niche services. The pattern: if a service has an API, somebody has probably written an MCP server for it.

How you actually use MCP (as a user)

In Claude Code, the steps are typically:

# 1. Install a server (often via npm or a marketplace)
claude mcp add @modelcontextprotocol/server-github
 
# 2. Configure credentials (API keys, OAuth, etc.)
# Usually via environment variables or an init flow
 
# 3. Use it — the tools become available in your next session

After installation, the GitHub tools just appear in Claude’s available tools. You can ask “list my open PRs” or “comment on PR #123” and Claude routes the call to the MCP server, which uses your GitHub credentials, which talks to GitHub’s API.

The same approach works in Claude Desktop, Cursor, and other clients. Each has a slightly different UI for managing servers, but the concept is the same.

How you write an MCP server (as a developer)

If a service doesn’t have an MCP server yet — or you want to expose your own service to AI agents — writing one is straightforward. SDKs exist for:

TypeScript (the most popular)
Python
Rust, Go, Kotlin and others

A minimal TypeScript server:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
 
const server = new Server({ name: "my-service", version: "1.0.0" });
 
server.setRequestHandler("tools/list", async () => ({
  tools: [{
    name: "get_data",
    description: "Get data from my service",
    inputSchema: { type: "object", properties: { id: { type: "string" } } }
  }]
}));
 
server.setRequestHandler("tools/call", async (request) => {
  if (request.params.name === "get_data") {
    const data = await fetchFromMyService(request.params.arguments.id);
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
});
 
await server.connect();

That’s a working MCP server. Users install it in their client, and now any compliant agent can call get_data.

Anthropic’s mcp-builder skill (you have it!) helps generate these — invoke /anthropic-skills:mcp-builder and Claude will scaffold a server for you.

MCP transports — how client and server actually communicate

Two main transports:

stdio (standard input/output) — the client launches the server as a subprocess and communicates over stdin/stdout. Simple, local, secure. Most desktop clients use this for local servers.
HTTP/SSE — the server runs as a remote service; the client talks to it over HTTP with Server-Sent Events for streaming. Used for cloud-hosted MCP servers.

You usually don’t have to think about this — the client and server agree on the transport at startup.

What changed in 2026

MCP started in late 2024. By June 2026:

Linux Foundation governance (December 2025) — neutral home, multi-vendor steering
Cross-vendor support — Anthropic, OpenAI, Google DeepMind, Amazon all support MCP natively
500+ public servers, with the number doubling roughly every 6 months
Authorization improvements — better handling of OAuth flows for servers that need them
Streaming responses — tools can stream results, not just return at the end
Improved discoverability — registries like mcp.io and mcp-registry make finding servers easier
Enterprise features — policy controls, audit logs, scoped permissions

The 2026 roadmap focuses on transport scalability, agent-to-agent communication (not just client-server), governance maturation, and enterprise readiness.

Common gotchas

MCP doesn’t make a service “AI-ready” on its own. The server still needs API access to the underlying service. You need credentials, rate limits, error handling.
Quality of MCP servers varies wildly. Official servers (from Anthropic or the service vendor) tend to be solid. Community servers vary — some are excellent, some are toys. Read the source for sensitive use cases.
Permission scope matters. A GitHub MCP server with full repo access is more dangerous than one with read-only access. Configure the OAuth scope deliberately.
Local vs hosted. Local (stdio) servers run on your machine with your credentials. Hosted servers run elsewhere — make sure you trust the host.
MCP isn’t the same as plain “tool use.” Tool use is the model feature. MCP is the standard for distributing tools across clients. You can use tool use without MCP; you can’t really use MCP without tool use under the hood.
Tool descriptions still matter. MCP doesn’t fix bad tool descriptions; it just standardizes the wrapper. Server authors need to write good descriptions.
Versioning matters. MCP is still evolving; protocol versions can drift between client and server. Mature servers handle compatibility; immature ones may break.
MCP servers can be slow. Some take seconds to start (especially when they auth on launch). Some have slow tool calls if the underlying API is slow. Time your agent loops accordingly.

Tech & AI, Explained

Explorer

mcp