What MCP Actually Is

The protocol behind AI agents, checked against the spec published this week

Word	What it means
MCP	Model Context Protocol. An agreement about how an AI application asks the outside world for help. It is a set of rules written down, not a program you install.
Protocol	A set of rules everybody agrees to follow. Not software. The rules that say a web page starts with https, or that a status code of 200 means success, are protocols too.
LLM	Large language model, the thing behind ChatGPT, Claude and Gemini. On its own it can only produce text. It cannot open a file or send an email.
Host	The application you actually sit in front of. A chat app, or a code editor. It is in charge, and it is the thing that asks your permission.
Client	The piece inside the host that speaks MCP. There is one client for each server it connects to. You never see it.
Server	The thing offering capabilities, such as access to your files or a database. It can be a small program on your own machine or a service on the internet.
Tool	A function the model can ask to run. Read a file, run a query, send a message. The model chooses these.
Resource	Data the model can read, with an address attached. The application chooses these.
Prompt	A saved template the person picks from a menu. Confusingly this does not mean the sentence you type into a chat box. The human chooses these.

What MCP actually is

A large language model can write you an essay about sending an email. It cannot send the email. It has no hands. It produces text and stops. Everything interesting an AI assistant appears to do, reading your files, running a query, opening a pull request, is done by ordinary code sitting next to the model. MCP is the agreement about how the model and that code talk to each other.

Before this agreement existed, every application had to be taught every tool separately. Ten applications and ten tools meant a hundred separate pieces of glue, each one written and maintained by hand. One shared agreement turns that into ten plus ten.

MCP is not a program. You do not install MCP. You install, or write, a server that follows the MCP rules. It is like a USB C port, and the comparison is a good one. A USB C port is not a device. It is an agreement about the shape of the plug, so any device and any laptop can meet in the middle.
It was invented at Anthropic, and given away. MCP was released in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation. It is no longer any single company’s protocol, which is a large part of why it is safe to build on.
It moves fast, and that is the catch. There have been five versions in twenty months. Most explanations you will find online describe the first one. This guide checks every claim against the newest.
The model never takes anything. It asks. The host application decides whether to allow it, and normally asks you first. This is the single most reassuring fact about MCP and the one most often left out.

The three things a server can offer

A server can offer three kinds of thing.

Label	What it is telling you
Tools	Functions the model can ask to run. Read a file, run a query, send a message. The model picks these, based on the description you wrote next to each one. If a tool is not on the list, the model has no way to call it.
Resources	Data the model can read, each with an address, rather like a file path or a web address. The application attaches these as context. A resource is there to be read, not to do anything.
Prompts	Saved templates that a person picks from a menu. A server connected to your bug tracker might offer one called summarise this week. The human chooses it deliberately.

The quickest way to tell them apart is to ask who is choosing. If the model chooses it, it is a tool. If the application attaches it, it is a resource. If a person picks it from a menu, it is a prompt. Get that one question right and the rest of MCP falls into place.

Host, client and server, and who is in charge

Three words get used constantly and beginners mix them up almost every time. They are worth thirty seconds each. The important part is not the naming, it is the chain of permission that the naming describes.

The model never reaches out and takes anything. It asks. The host decides whether to allow it, and usually asks you first. That is why an MCP connection is safer than handing an application your password, and it is also why a badly built host is dangerous: the host is the thing holding the permission.

The two questions that decide everything

Almost every practical decision in MCP comes down to two questions. The first sorts out what you are building. The second sorts out where it runs.

The second question. If the server runs on your own machine it talks over standard input and output, the same pipes any command line program already uses. If it runs somewhere on the internet it talks over ordinary web requests. There used to be a third option, and it was removed in March 2025.

Step 1. Start at the source, not at a blog post

Where this is: modelcontextprotocol.io, the official home page

Do this

1. Open any web browser.

2. Type modelcontextprotocol.io into the address bar and press Enter.

3. Read the first heading and the paragraph under it.

4. Look along the top row of links: Documentation, Specification, Extensions, Registry, SEPs, Community.

What you should see

The heading asks the question this guide is answering. What is the Model Context Protocol. Starting here matters, because this site is the thing that defines MCP. Everything else, including this guide, is somebody’s summary of it.
The site describes MCP as a USB C port for AI applications. That is the official comparison, not one invented for this course. It is doing real work: a port is not a device, it is an agreement about the shape of the plug.
There is a version selector near the top. It reads Version 2026-07-28 (latest). Remember that this control exists. It is how you check whether anything you are reading is current.

Why this matters

There is an enormous amount of MCP writing online and a great deal of it is now wrong, not because the authors were careless but because the protocol changed underneath them. Getting into the habit of starting here costs nothing and saves you from learning things that stopped being true a year ago.

Step 2. Versions are dates, and there are five of them

Where this is: Specification, then Versioning

Do this

1. From the home page, click Specification in the top row.

2. In the left hand menu, look under Base Protocol and click Versioning and Compatibility.

3. Read the Revisions section.

4. Note the three states a revision can be in: Draft, Current and Final.

What you should see

MCP versions are dates, not numbers. There is no version 2.1. There is 2025-06-18. The date marks the last time something changed that could break older code, which is a genuinely sensible way to name versions.
Count them. There are five. The first was 2024-11-05. Then 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28. That last one was published on 28 July 2026, the day before this guide was built.
The page mentions a deprecated features registry. That is new, and it is a sign of a protocol growing up. We open it later in this guide.

Why this matters

This single page is the reason this guide exists. A very popular explainer video about MCP was published on 18 March 2025. It was accurate on the day. Eight days later the first big revision landed, and three more followed. Nothing was wrong with that video. It simply describes a version that has since been replaced four times over, and there is no way to know that unless you check this page.

Worth knowing

At the time of writing, this page still names 2025-11-25 as the current version while linking to 2026-07-28 pages throughout, because the newest revision was published the day before. The GitHub releases page, which we open at the end, is the faster place to see the truth.

Step 3. Who is who, and who is in charge

Where this is: Documentation, then About MCP, then Architecture

Do this

1. Click Documentation in the top row.

2. In the left hand menu, find the heading About MCP.

3. Under it, click Architecture. It is the first item.

4. Scroll down to the section headed Participants.

What you should see

The host is the application you sit in front of. A chat app, or a code editor. It holds the conversation and it holds the permissions.
The client is inside the host, and there is one per connection. This is the part beginners miss. Client does not mean the app. It means the small piece of the app that speaks to one particular server.
The server offers capabilities. Access to your files, a database, a ticketing system. It can be a small program on your own machine or a service somewhere on the internet.

Why this matters

Once you can place these three words correctly, the security model explains itself. The model can only ask. The client carries the request. The host decides. You are asked. Every argument about whether MCP is safe is really an argument about how well a particular host does its job at that third step.

Step 4. Tools are just functions

Where this is: Specification, then Server Features, then Tools

Do this

1. Click Specification in the top row.

2. Check the version selector says 2026-07-28.

3. In the left hand menu, under Server Features, click Tools.

4. Scroll to the section describing tool annotations.

What you should see

A tool is a function with a description attached. That is the whole idea. Ordinary code that takes input and returns output. There is nothing intelligent inside a tool.
The description is the part that matters. It is what the model reads when it decides which tool to call. A vague description is the single most common reason an AI assistant picks the wrong tool.
Look for the annotations. A tool can be marked read only, or destructive, or idempotent, which means running it twice does the same as running it once. These were added in the March 2025 revision.

Step 5. Resources are data with an address

Where this is: Specification, then Server Features, then Resources

Do this

1. Stay in the Specification section.

2. In the left hand menu, under Server Features, click Resources.

3. Look at the example URIs near the top of the page.

What you should see

Every resource has a URI. A URI is just an address. It might look like a file path, or like a web address. The shape tells the application where the thing lives.
Resources are read, not run. If a tool is a verb, a resource is a noun. Nothing happens as a consequence of reading one.
The application decides which resources to attach. Not the model. This is the difference that catches people out.

Why this matters

When you build your first server you will have to decide whether something should be a tool or a resource, and the honest answer is that it is usually obvious once you ask whether you are offering an action or offering information. Offering information as a tool works, but it hands the model a decision it did not need to make.

Step 6. Prompts are menu items, not chat messages

Where this is: Specification, then Server Features, then Prompts

Do this

1. Stay in the Specification section.

2. In the left hand menu, under Server Features, click Prompts.

3. Read the opening sentence carefully. It contains the phrase user controlled.

What you should see

A prompt here is a template the server offers. It is not the sentence you type into a chat box. This is easily the most confusing piece of naming in all of MCP.
The specification calls them user controlled. That phrase is the whole point. A person picks a prompt deliberately, usually from a menu or a slash command.
Prompts can take arguments. So a template called summarise this week can ask which project you mean before it runs.

Why this matters

Hold the three side by side and the design becomes clear. Tools are model controlled. Resources are application controlled. Prompts are user controlled. Three kinds of thing, three different people or programs doing the choosing. If you can say that sentence in an interview you will sound like somebody who has actually read the specification, because most people have not.

Step 7. How the two of them actually talk

Where this is: Specification, then Base Protocol, then Transports, then Streamable HTTP

Do this

1. In the left hand menu, under Base Protocol, click Transports.

2. Click Streamable HTTP.

3. Scroll to the section about the protocol version header.

What you should see

There are two transports and only two. Standard input and output for a server on your own machine, and Streamable HTTP for a server somewhere on the internet.
Streamable HTTP is ordinary web traffic. The word streamable means the server can keep a channel open and push updates back while it works, which matters for anything slow.
Every request carries its protocol version. It travels in a header. The server accepts or rejects each request on its own.

Step 9. A public list of what is on its way out

Where this is: Specification, then Deprecated Features

What you should see

The three at the top are the ones that matter most: Roots, Sampling and Logging. All three were deprecated on 2026-07-28.

Step 10. Security Best Practices

Where this is: Documentation, then Develop with MCP, then Security, then Security Best Practices

Why this matters

An MCP server is software you are giving permission to act on your behalf. The convenience and the risk are the same fact viewed from two sides. None of this means MCP is unsafe, it means the safety lives in choices you make: which servers you install, who published them, and whether your host actually shows you what it is about to do.

Step 11. Brief on Building an MCP server

Pick your language at the top. There are ten official libraries, and they are ranked in tiers by how completely they track the specification. TypeScript, Python, C sharp and Go are Tier 1. Java and Rust are Tier 2. Swift, Ruby, PHP and Kotlin are Tier 3. The shape of the code is the same in all of them, but the tier tells you how quickly a new revision will reach you.
Find where a tool gets attached. It is usually one function with a name, a description and a list of arguments. That is the whole of it.
Find the last line. Something that tells the server to start listening. There is no clever machinery in between.

Step 12. Read a real one before writing your own

Where this is: github.com/modelcontextprotocol/servers

Do this

1. Go to github.com/modelcontextprotocol/servers.

2. Scroll to the list of folders under src.

3. Open any one of them and read its index file.

4. Find the part where the tools are declared, and compare it to the guide you just read.

What you should see

Each folder is a complete working server. Not a snippet. You can run these.
They are maintained by the same project that writes the specification. So when the specification changes, these change with it. That makes them a much safer thing to copy than a blog post.

Step 13. The app store that got predicted, and then built

Where this is: registry.modelcontextprotocol.io

Do this

1. Go to registry.modelcontextprotocol.io.

2. Click any result and look at who published it and what address it uses.

In early 2025 people were predicting that MCP would need a single place to find servers, an app store rather than a hunt through blog posts. That prediction came true and the registry launched in preview in September 2025. It matters that it is run by the project rather than by a company, because provenance is the thing you should check first when installing a server, and a neutral registry is where provenance lives.

Step 14. It is not one company’s protocol any more

MCP was donated to the Agentic AI Foundation, under the Linux Foundation. Announced on 9 December 2025.

It was co founded by Anthropic, Block and OpenAI. With support from Google, Microsoft, AWS, Cloudflare and Bloomberg. Two of those are direct competitors of the company that invented it.
The announcement gives the scale. Over 97 million SDK downloads a month and 10,000 active servers, with support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.

Step 15. MCP Releases

github.com/modelcontextprotocol/modelcontextprotocol, the Releases page

Do this

1. Go to github.com/modelcontextprotocol/modelcontextprotocol.

2. Click Releases in the right hand column.

3. Read down the list and note the dates.

4. Notice which entries are marked Pre-release, and which are not.

Interview questions

Q1. What is MCP?

It is an agreement about how an AI application asks the outside world for help. It is not software you install, it is a set of rules, in the same way that HTTP is a set of rules. A server follows those rules and offers a list of things it can do. An AI application connects, reads the list, and can call things on that list and nothing else.

Q2. Why did MCP need to exist at all?

Because every AI application had to be taught every tool separately. Ten applications and ten tools meant a hundred pieces of glue, all written and maintained by hand. With one shared agreement it becomes ten plus ten. The official site compares it to a USB C port, and that is a fair comparison, because a port is not a device, it is an agreement about the shape of the plug.

Q3. What are the three things a server can offer, and who chooses each one?

Tools, resources and prompts. Tools are functions the model chooses to call. Resources are data the application attaches. Prompts are templates the person picks from a menu. The specification calls them model controlled, application controlled and user controlled, and that phrasing is the fastest way to keep them straight.

Q4. What is the difference between a host, a client and a server?

The host is the application you sit in front of, like a chat app or an editor. The client is the piece inside the host that speaks the protocol, and there is one client per connection. The server offers the capabilities. The bit that matters is the chain of permission: the model can only ask, the host decides, and the host normally asks the user first.

Q5. Which transports does MCP support?

Two. Standard input and output when the server runs on the same machine, and Streamable HTTP when it is remote. There used to be a third, HTTP with SSE, and it was replaced in March 2025. If you see a tutorial with a separate SSE endpoint and a separate message endpoint, it predates that change.

Q6. What is the biggest recent change to the protocol?

The 2026-07-28 revision made MCP stateless. The initialize handshake is gone and so is the session header. Every request now carries what it needs. The practical effect is that any request can be answered by any copy of the server, so you can run one behind an ordinary load balancer instead of needing sticky routing and a shared session store.

Q7. Is anything in MCP being removed?

Yes, and it is published openly. Roots, sampling and logging were all marked deprecated on 28 July 2026. Each one has a documented migration path, and the policy guarantees a deprecated feature stays for at least twelve months, with the earliest removal date printed in a public register.

Q8. What is sampling, and should I use it?

Sampling was the mechanism that let a server ask the client to run something through a model on its behalf. A lot of older tutorials teach it as one of the main ways to give context. It has been deprecated as of the 2026 revision, and the recommended replacement is to call the model provider directly. Existing code keeps working, but I would not start anything new on it.

Q9. What are the main security risks with MCP?

The specification names several. The confused deputy problem, where a server uses its own broad permissions for a user who does not have them. Token passthrough, where a server accepts a token that was not issued to it, which is now explicitly forbidden. And local server compromise, because a server you download runs with exactly the privileges you have. Underneath all of them is prompt injection: tool descriptions and tool output are untrusted input.

Q10. Who controls MCP?

It was created at Anthropic and released in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, co founded with Block and OpenAI and supported by Google, Microsoft, AWS and others. The maintainers keep technical direction. So it is a neutral standard now rather than one company’s protocol.

Q11. How would you decide whether something should be a tool or a resource?

I would ask whether I am offering an action or offering information. If calling it has a consequence, it is a tool. If it is just data to be read, it is a resource. You can technically expose information as a tool, but then you have handed the model a decision it did not need to make, and you have added a way for it to go wrong.

Q12. How do you know whether what you have read about MCP is still true?

I check the version. MCP versions are dates, and there have been five in twenty months. The releases page on GitHub shows every one with its publication date, and the documentation site has a version selector at the top of every page. Most MCP writing online describes the first version, so checking which revision an article was written against is the first thing I do.