What MCP is

MCP is an open standard for plugging tools and data into AI applications, in the way a USB port lets any device work with any computer. Start with the roles and the three things a server can offer.

Model Context Protocol

Also called MCP

What: An open protocol that defines how AI applications discover and use external tools, data and prompt templates, using JSON-RPC 2.0 messages over a transport.
Why: Write an integration once as an MCP server and it works in any MCP-capable app (chat apps, IDEs, coding agents) instead of building a custom plugin per app.

Watch out

Treating MCP as a model feature. It is plumbing between applications and services; the model only sees the tools and context the host passes on.

The M times N problem

What: Without a standard, M AI applications and N services need M times N custom integrations. With MCP, each app implements a client once and each service a server once.
Why: It explains why the protocol spread: service owners and app builders can each do their half independently.
Example: A company exposes its ticketing system as one MCP server; the same server then works in the team’s IDE assistant, its chat app and its internal agent.

Host

What: The AI application the user interacts with, such as a desktop chat app, an IDE or an agent. It runs the model, manages clients and decides what the model may see and do.
Why: The host enforces consent: it shows which tools exist, asks before running them and controls what data leaves the machine.

Client

What: The connector inside the host that talks to exactly one server. A host with five servers configured runs five clients.
Why: One client per server keeps servers isolated from each other: a server never sees another server’s data or the full conversation unless the host shares it.

Server

What: A program that exposes tools, resources and prompts over MCP. It can run locally as a subprocess or remotely as an HTTP service.
Why: Servers are where the real integration lives: a database, a SaaS API, a file system, a browser.

Watch out

Building one giant server that wraps every endpoint of an API. Smaller, task-focused servers are easier to secure and for models to use.

Tools, resources and prompts

Also called server primitives

What: Tools are functions the model can call; resources are data the application can read into context; prompts are templates the user picks. Each has list and get or call methods.
Why: They differ in who is in control: tools are model-controlled, resources application-controlled, prompts user-controlled. Pick the primitive that matches.
Example: A Git server might offer a create_branch tool, a repo://README.md resource and a "write release notes" prompt.

Protocol versions and extensions

What: The specification is versioned by date, for example 2025-11-25 and 2026-07-28. Optional extensions (such as Tasks and MCP Apps) add features that both sides must opt into.
Why: Clients and servers agree on a version, so you must know which revision your SDK and host speak when a feature seems missing.

Watch out

Following a tutorial for an older revision without noticing: the 2026-07-28 revision removed the handshake and sessions.

Go deeper