What Is MCP (Model Context Protocol)? A Plain-English Guide

For two years, AI assistants had a frustrating limitation: they could talk brilliantly but couldn’t do much. Ask one about your calendar, your codebase, or your company’s database and it would shrug — it had no safe, standard way to reach them. Every connection was a bespoke, one-off integration. MCP is the standard that fixed that, and it’s quietly become one of the most important pieces of plumbing in modern AI. Here’s what it actually is.

The short answer

MCP (Model Context Protocol) is an open standard — introduced by Anthropic in late 2024 and now adopted across the industry — that lets an AI assistant connect to external tools, data, and services through one common interface. Instead of building a custom integration for every app, you build to MCP once and it works everywhere. The usual analogy: MCP is a USB-C port for AI — one plug, many devices.

Why MCP exists: the M×N problem

Before MCP, connecting M AI applications to N tools meant building (and maintaining) roughly M × N separate integrations — ChatGPT-to-GitHub, Claude-to-GitHub, Cursor-to-Slack, and so on, each one custom. That doesn’t scale.

A shared protocol turns that into an M + N problem: each AI app implements MCP once, each tool exposes an MCP server once, and they all interoperate. That’s the same move that made USB, HTTP, and the Language Server Protocol so powerful — agree on one interface and the combinatorial mess disappears.

How MCP works: hosts, clients, and servers

MCP has three roles, and keeping them straight is most of understanding it. (Descope explainer)

• Host — the AI application you actually use (Claude Desktop, an IDE assistant, a chat app). The host contains the model and the UI, but it delegates the protocol to clients.
• Client — a connector living inside the host. The host runs one client per server, and the client speaks MCP.
• Server — a small program that exposes a specific capability (your files, a GitHub account, a database). One host can run many clients at once, aggregating every server’s capabilities into a single toolbox for the model.

Under the hood it’s JSON-RPC 2.0 — a plain, well-understood message format — so there’s nothing exotic about the wire protocol.

The three things a server can expose

An MCP server offers up to three kinds of capability — and the distinction matters for safety:

Primitive	What it is	Example	Risk
Tools	Functions the AI can call to act	“create issue”, “send email”, “run query”	Highest — tools take actions
Resources	Read-only data pulled in as context	a file, a database record, a log	Lower — but can carry injected text
Prompts	Reusable templates a person selects	“Summarize this PR”, “Draft a reply”	Low — user-initiated

Tools are the exciting part (they let the AI do things) and the dangerous part (they let the AI do things). We’ll come back to that.

Local vs remote

Servers connect over one of two standard transports:

• stdio — the host launches the server as a local child process and talks to it over standard input/output. Great for a server on your own machine; naturally isolated to one client.
• Streamable HTTP — the remote option: a single HTTP endpoint, with streaming responses, usually protected by OAuth 2.1. This replaced the older HTTP+SSE transport, now deprecated. (transport details)

Where MCP stands in 2026

MCP has moved from novelty to infrastructure fast. The current specification revision is 2026-07-28, a significant rewrite toward a stateless, enterprise-friendly core (it drops the old session-handshake mechanism), with 2025-11-25 as the previous stable version. (MCP spec, 2026-07-28)

An official MCP Registry — a directory of available servers — launched in preview in September 2025 and, by late October 2026, listed on the order of tens of thousands of active servers (one tracker reported ~47,000). (MCP adoption stats) Adoption of the newest wire revision is slower than the headline numbers suggest, though — real-world servers upgrade at their own pace, so expect a mix of versions for a while.

A concrete example

Say you want your AI assistant to help triage GitHub issues. With MCP:

1. You add a GitHub MCP server to your host and authorize it (via OAuth for a remote one).
2. The server advertises tools (“list issues”, “comment”, “label”) and resources (the text of an issue).
3. You ask: “Summarize the open bugs and label the stale ones.” The model calls the server’s tools through its client, reads the issues as resources, and acts — all through the same standard interface it would use for a Slack server, a database server, or a filesystem server.

Swap GitHub for any other service and nothing about the mechanism changes. That uniformity is the whole point — and it’s why MCP pairs naturally with prompt-heavy workflows like the ones in our AI prompt generators and our take on ChatGPT vs Claude for prompting.

Connecting an existing server: two real examples

Adding a server means telling your host where to find it — and the how depends on whether it’s a local or remote server, the exact split from earlier.

A local server (stdio): Blender

blender-mcp lets an AI drive Blender — modelling, materials, whole scenes — and is one of the most-used community servers. It runs on your machine, so you point the host at a command to launch.

1. Install uv (it provides the uvx launcher that runs the server).
2. In Claude Desktop, open Settings → Developer → Edit Config and add:

{
  "mcpServers": {
    "blender": {
      "command": "uvx",
      "args": ["mcp-for-blender"]
    }
  }
}

Every line earns its place: "blender" is the name you’ll see in the host; command is the executable to launch; args are passed to it (here, the package uvx fetches and runs).

3. Install the project’s Blender add-on, enable it in Blender (Edit → Preferences → Add-ons), and start it from the BlenderMCP tab in the 3D viewport’s sidebar (press N). Blender must be running for the connection to work.
4. Fully quit and relaunch Claude Desktop — servers load only at startup.

The package was renamed from blender-mcp to mcp-for-blender; the old uvx blender-mcp still runs, so existing configs don’t need changing. The config file lives at %APPDATA%\Claude\claude_desktop_config.json on Windows and ~/Library/Application Support/Claude/claude_desktop_config.json on macOS — and a single JSON typo silently disables all your servers, so validate it before restarting.

A remote server (HTTP + OAuth): Canva

Canva runs an official, hosted MCP server, so there’s nothing to install — you connect to a URL and sign in with OAuth. The endpoint is https://mcp.canva.com/mcp.

• In Claude Desktop / claude.ai: Settings → Connectors → Add custom connector, paste the URL, and complete the Canva sign-in.
• In Claude Code: claude mcp add --transport http canva https://mcp.canva.com/mcp

After the OAuth handshake, Canva’s tools (create designs, autofill templates, export) show up in your host — no local process, and access is scoped to what you approve at sign-in. That’s the whole difference: local servers are a command; remote servers are a URL plus OAuth.

Build your own MCP server in ~12 lines

Writing a server is deliberately small. Here’s a complete one using the official Python SDK, exposing a single tool:

# weather_server.py
from mcp.server.fastmcp import FastMCP

# 1. Name the server — this is how a host identifies it.
mcp = FastMCP("weather")

# 2. Any decorated function becomes a tool the AI can call.
#    The type hints and docstring ARE the interface the model
#    reads to decide when and how to use it — write them clearly.
@mcp.tool()
def get_forecast(city: str) -> str:
    """Get a short weather forecast for a city."""
    # Replace this stub with a real API call.
    return f"{city}: 21°C and sunny."

# 3. Run over stdio so a host can launch it as a child process.
if __name__ == "__main__":
    mcp.run()

Then install the SDK and wire it up:

pip install "mcp[cli]"          # the official SDK + CLI
mcp dev weather_server.py       # test it in the MCP Inspector
mcp install weather_server.py   # register it with Claude Desktop

That’s the whole shape of a server: name it, decorate functions as tools, and run it. Add @mcp.resource(...) for read-only data and @mcp.prompt(...) for templates and you’ve covered all three primitives.

Before you ship it: the moment a tool does something real — touches a database, calls an API, writes files — the security practices below stop being optional. A tool is code the AI can trigger on its own.

The security part you should actually read

MCP is a connectivity standard, so the protocol itself isn’t where the danger lives — the servers you connect and the permissions you grant are. A few real risk patterns, and how the industry defends against them: (Pillar Security · Checkmarx)

• Tool poisoning. A tool’s description is read by the model — so hidden instructions buried in that metadata can hijack the AI’s behavior. Review tool descriptions, and re-review them when a server updates.
• Injection through tool results. A web page or document returned by a tool can carry instructions aimed at the model. Treat all tool output as untrusted input, never as commands — the same rule we apply everywhere.
• Malicious or vulnerable server packages. An MCP server is a dependency like any other, so it’s exposed to the exact software supply-chain risks we’ve covered — trojanized packages, command-injection CVEs, abandoned maintainers.
• Over-broad permissions. A server handed sweeping credentials can do sweeping damage. Use least-privilege tokens.

The practical defenses are boring and effective: connect only trusted servers, pin their versions, grant least-privilege access, require human approval for destructive or outbound actions (enforced in code, not in the prompt), and log tool calls. The 2026 spec tightened authorization, but it does not — and cannot — eliminate tool poisoning or prompt injection on its own.

What it means for you

• If you just use AI assistants: you don’t need to implement anything, but treat “connect this server?” like installing an app and “allow this action?” like a permission prompt. Only connect sources you trust; read the approval dialogs.
• If you build with AI: MCP is the way to give your assistant real capabilities without one-off glue code. Build to the standard, start with read-only resources, add tools deliberately, and bake in the security practices above from day one.

Takeaways

• MCP = a universal adapter for AI — one open standard so assistants can use external tools and data instead of a custom integration per app.
• Three roles (host, client, server) and three primitives (tools, resources, prompts); tools take actions and carry the most risk.
• It’s now real infrastructure: a stateless 2026 spec and an official registry with tens of thousands of servers — though version adoption lags the hype.
• It’s approachable: connecting a server is a few lines of config (local) or a URL + OAuth (remote); building one is ~a dozen lines of Python.
• Security lives in the servers you trust and the permissions you grant, not the protocol — so allowlist, pin, least-privilege, and keep a human in the loop for risky actions.