MCP stands for Model Context Protocol. It is an open standard that defines how AI applications connect to external tools, data sources and prompt templates through servers.

What does an MCP server do?

It exposes capabilities, mainly tools the model can call, resources the app can read as context and prompts users can pick, so an AI app can use a database, a browser or an API without custom code.

What is the difference between an MCP client and an MCP host?

The host is the AI application the user runs. It creates an MCP client for each server connection. The server is the program that provides the tools and data.

Which apps support MCP?

Many AI coding tools, chat apps and agent frameworks act as MCP clients, including Claude Code and Claude Desktop, plus several IDEs. Check each product's documentation for current support.

Do I need to code to use MCP?

No. You can add existing servers with a command or a settings file. Coding is only needed when you build your own server.

What is MCP? Model Context Protocol explained simply

If you use AI tools for development you have probably seen "MCP" on every product page. Here is what it is, in plain terms, without the hype.

The problem MCP solves#

An AI model on its own can only produce text. To be useful for real work it needs to read your files, query your database, search your tickets and take actions. Before MCP, every AI app built those connections its own way. A GitHub integration for one app did nothing for another.

MCP is a shared plug. A service ships one MCP server. Any AI app with an MCP client can use it.

Write the server once. Every compatible app can use it.

The three roles#

Host: the AI application you use (a coding agent, a desktop chat app, an IDE).
Client: a connector inside the host. It holds one connection per server.
Server: a program that offers capabilities. It can run on your machine or remotely.

What a server can offer#

Primitive	What it is	Who decides to use it	Example
Tools	Actions the model can call	The model	`search_issues`, `run_query`
Resources	Data an app can read as context	The application	A file, a database schema
Prompts	Reusable templates	The user	A "review this diff" command

Tools are the most used. A tool has a name, a description the model reads, and an input schema. See tool use explained for how a model calls one.

How the connection works#

Messages are JSON-RPC 2.0. There are two standard transports:

stdio: the app starts your server as a local subprocess and talks over standard input and output.
Streamable HTTP: the server runs as a web service and the client sends requests to a single endpoint. Used for remote servers.

Newer revisions of the spec are stateless: each request carries the protocol version and the client's capabilities, so there is no long-lived session to manage.

A concrete example#

You ask a coding agent: "Which open bugs mention the login page?" The agent asks the issue-tracker MCP server what tools it has, picks search_issues, calls it with a query, reads the results and answers. You never wrote glue code for that tracker, and the same server works in a different app tomorrow.

What MCP is not#

Not a replacement for APIs. Most servers wrap one. See MCP vs API.
Not a security layer. A server can do whatever its code and credentials allow. Read MCP security.
Not required for tool use. If you own one app and its tools, plain function calling is simpler.
Not RAG. RAG supplies knowledge in the prompt; MCP connects tools and live data. They combine (RAG vs fine-tuning vs MCP).

Try it#

Use one: add an existing server to your coding agent (Claude Code walkthrough, and servers worth installing).
Build one: a working TypeScript server is about twenty lines. The first lesson of the MCP in Depth course builds it and tests it in the Inspector.

Spec and docs: modelcontextprotocol.io.