What Is MCP (Model Context Protocol)? The Complete 2026 Guide

A year ago, wiring an AI assistant into your own tools meant writing glue code by hand — a custom bridge for your database, another for Slack, another for GitHub, each one slightly different and none of them reusable. Today there is a single plug for all of it, and it is spreading through the industry faster than almost any developer standard in recent memory. That plug is called MCP.

If you have heard the term thrown around and quietly nodded along without really knowing what it is, this guide is for you. I am going to start from zero — no assumed knowledge of AI — and take you all the way to building and securing your own MCP integration. Along the way we will use plenty of pictures, tables, and small runnable examples, because MCP is one of those ideas that looks abstract in a sentence and becomes obvious the moment you see it move.

Let’s begin with why everyone is suddenly talking about it.

Why MCP is suddenly everywhere

For most of their short history, chatbots had a frustrating limitation: they could talk about the world but not touch it. Ask one for your latest sales figures and it would apologize, because it had no way to reach your database. The model was brilliant and blind at the same time.

Developers worked around this by building connectors — small pieces of code that fetch data and hand it to the model. That worked, but every connector was bespoke. A team that had wired Claude to their Postgres database could not reuse a single line of that work when they later wanted to wire it to their Jira board, and none of it transferred when they switched from one AI product to another. Everyone was solving the same plumbing problem over and over.

MCP fixes the plumbing. It is an open standard — published rules that anyone can follow — for how an AI application asks an outside system for data or actions. Build one MCP connector for your database and any MCP-compatible AI can use it: Claude today, a different assistant tomorrow, your own homegrown agent next month. Write once, connect anywhere.

That single property is why adoption exploded. The companies that make AI models, the companies that make code editors, and the companies that run enterprise software all had the same incentive to agree on one interface instead of maintaining dozens. When incentives line up like that, a standard spreads quickly — and MCP did.

What is MCP? A plain-English definition

Let’s define it three ways, from simplest to most precise, then compress it into a single sentence you can quote.

The simple version. MCP is a universal adapter that lets AI assistants safely use your tools and read your data. Think of it as the socket an AI plugs into to reach the outside world.

The technical version. The Model Context Protocol is an open protocol that standardizes how applications provide context and capabilities to large language models. It defines a client-host-server architecture in which an AI application (the host) runs one or more clients, and each client keeps a connection to a server that exposes tools, data, and prompt templates. Messages travel as JSON-RPC 2.0 over a transport such as standard input/output or HTTP.

The professional version. MCP is a transport-agnostic, capability-negotiated interface layer between large language model applications and external systems. Servers advertise three primitives — tools (functions the model can call), resources (data the application can read), and prompts (reusable templates the user can invoke) — while clients may offer their own features back to servers. A structured lifecycle handles version negotiation, capability exchange, and secure operation, so any compliant client can talk to any compliant server without either side knowing the other’s internals.

In one sentence: MCP is an open standard that lets any AI application connect to any tool or data source through a single, consistent interface — the way USB-C lets any device connect to any peripheral through one port.

That USB-C comparison is not mine, by the way. Anthropic, the company that created MCP, described it as “a USB-C port for AI applications” in its own documentation, and the analogy stuck because it is genuinely accurate. We will unpack it properly later.

The problem MCP was built to solve

To appreciate why MCP matters, you have to feel the pain it removes. Let’s make the problem concrete.

Imagine you run a company with three AI applications — a customer-support assistant, an internal analytics bot, and a coding helper. You also have four systems you want them to reach: a Postgres database, GitHub, Slack, and Google Drive. If each AI app needs a custom connector for each system, you are on the hook for 3 × 4 = 12 separate integrations. Add a fifth system and you are building three more. Add a fourth AI app and you are building four more. The work grows by multiplication, not addition.

Engineers call this the N×M problem: N applications times M data sources, each pair needing its own hand-built bridge. It is the same mess the software industry has hit many times before, and the fix is always the same shape — insert a shared standard in the middle so each side only has to implement it once.

Here is the difference visually:

BEFORE MCP — every app builds its own bridge to every system (N×M)

  Support Bot ──────┐   ┌────── Postgres
                    ├───┤
  Analytics Bot ────┼───┼────── GitHub
                    ├───┤
  Coding Helper ────┘   └────── Slack, Drive
        (12 custom, non-reusable integrations)


AFTER MCP — everyone speaks one protocol (N + M)

  Support Bot ────┐                 ┌──── Postgres MCP server
  Analytics Bot ──┼──►  MCP  ◄──────┼──── GitHub MCP server
  Coding Helper ──┘  (one standard) └──── Slack / Drive MCP servers
        (each side implements MCP once, then everything interconnects)

Why plain APIs were not enough

A fair question at this point: we already have APIs — web interfaces that let programs talk to each other. Why invent something new?

Because a regular API is designed for a programmer who reads documentation, learns the exact endpoints, and writes precise code. An AI model is a different kind of consumer. It needs to discover what a system can do at runtime, understand each capability in plain language, and decide on its own which one to use for a given request. Traditional APIs do not describe themselves in a way a model can reliably act on, they do not share a common shape across vendors, and they push all the “which endpoint, what parameters, how to handle the response” work back onto whoever is integrating.

MCP adds the missing layer. An MCP server does not just expose functions; it exposes functions with machine-readable descriptions and schemas, so a model can list what is available, read what each thing does, and call it correctly — all through one consistent protocol regardless of who built the server. APIs remain the pipes underneath; MCP is the standard socket bolted on top so AI can use those pipes without a custom manual for each one.

We will compare MCP against APIs, plugins, and function calling in detail later. For now, hold onto the core idea: APIs connect software to software; MCP connects AI models to software in a way models can actually navigate.

A short history of MCP: 2024 to 2026

MCP is young, and it has moved fast. Here is the timeline, with the facts pinned to primary sources.

Date	Milestone
Nov 25, 2024	Anthropic open-sources MCP, created by David Soria Parra and Justin Spahr-Summers. Ships the spec, SDKs, Claude Desktop support, and reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Early adopters named at launch include Block, Apollo, Zed, Replit, Sourcegraph, and Codeium.
Mar 26, 2025	First major spec revision. Adds an OAuth 2.1 authorization framework, replaces the old HTTP+SSE transport with Streamable HTTP, and introduces tool annotations. The same day, OpenAI announces it will support MCP, starting with its Agents SDK.
Apr 9, 2025	Google DeepMind’s Demis Hassabis says Gemini will support MCP, calling it a rapidly emerging open standard for the agentic era.
May 2025	At Microsoft Build, Microsoft and GitHub deepen involvement — joining MCP’s steering committee and building first-class support across Windows, GitHub, Copilot Studio, and Azure AI Foundry. Microsoft co-maintains the official C# SDK.
Jun 18, 2025	Second major spec revision. Reclassifies MCP servers as OAuth Resource Servers, requires Resource Indicators (RFC 8707), and adds structured tool output and elicitation.
Sep 8, 2025	The MCP Registry launches in preview — an open, official catalog for discovering public MCP servers.
Nov 25, 2025	Third major spec revision, 2025-11-25, the current stable version on MCP’s first birthday. Adds icons, OpenID Connect discovery, tool-calling inside sampling, and experimental Tasks for long-running work.
Dec 9, 2025	MCP moves to the Linux Foundation, under the vendor-neutral Agentic AI Foundation, with Anthropic, GitHub, Microsoft, OpenAI, and independent maintainers participating. Governance is now shared, not owned by one company.
Mid-2026	The 2026-07-28 revision enters release-candidate status — the biggest redesign yet, moving the protocol toward a stateless core and adding an official extensions framework.

Two things stand out in that timeline. First, the speed of cross-vendor buy-in: within four months of launch, the three largest players in AI models had all committed. That almost never happens with a new standard, and it happened because MCP solved a problem all of them shared. Second, the move to the Linux Foundation in late 2025 matters more than it might seem — it signals that MCP is now infrastructure, owned by the community rather than by its inventor, which is exactly what you want before betting a company’s architecture on it.

How MCP works, step by step

Let’s watch a single request travel through the system. Suppose you are chatting with an AI assistant and you type: “How many orders did we ship yesterday?”

Here is what happens, stage by stage.

   You                Host (AI app)         MCP Client        MCP Server         Database
    │                      │                    │                 │                  │
    │  "orders shipped     │                    │                 │                  │
    │   yesterday?"        │                    │                 │                  │
    ├─────────────────────►│                    │                 │                  │
    │                      │ 1. ask the model,  │                 │                  │
    │                      │    which sees the   │                 │                  │
    │                      │    available tools  │                 │                  │
    │                      │                    │                 │                  │
    │                      │ 2. model decides:   │                 │                  │
    │                      │    call "query_db"  │                 │                  │
    │                      ├───────────────────►│  3. tools/call  │                  │
    │                      │                    ├────────────────►│  4. run SQL      │
    │                      │                    │                 ├─────────────────►│
    │                      │                    │                 │◄─────────────────┤
    │                      │                    │◄────────────────┤  5. rows return  │
    │                      │◄───────────────────┤  6. tool result │                  │
    │                      │ 7. model writes a   │                 │                  │
    │  "You shipped 428    │    plain-English    │                 │                  │
    │◄─────────────────────┤    answer           │                 │                  │
    │   orders yesterday." │                    │                 │                  │

Walking through it in words:

The host asks the model. The AI application (the “host”) sends your question to the language model, along with a list of tools it discovered from connected MCP servers. Crucially, the model can see that a query_db tool exists and read its description.
The model chooses a tool. Instead of guessing at the answer, the model recognizes it needs live data and decides to call query_db with an appropriate query. It does not run anything itself — it just expresses the intent.
The client sends a request. The host’s MCP client turns that intent into a standard tools/call message and sends it to the right MCP server.
The server does the real work. The MCP server — the only component that actually knows how to talk to your database — runs the query.
The database responds with rows of data, which flow back to the server.
The result returns to the model. The server packages the result and sends it back through the client to the host, which hands it to the model.
The model writes the answer. Now grounded in real data, the model composes a natural-language reply: “You shipped 428 orders yesterday.” You never saw the SQL, the JSON, or the protocol — just the answer.

The elegant part is the division of labor. The model decides what to do. The server knows how to do it. The protocol carries the request between them in a format both sides agree on. No component needs to understand the others’ internals.

The core building blocks

MCP has a small vocabulary. Learn these ten or so terms and the whole protocol clicks into place. I will group them into three buckets: the participants, the things servers expose, and the machinery underneath.

The participants: host, client, server

These three roles are the backbone of MCP, and beginners mix them up constantly, so let’s be precise.

Host — the AI application you actually use: Claude Desktop, an AI-powered code editor, a customer-support agent. The host holds the conversation, talks to the language model, enforces security and user consent, and can manage several clients at once. It is the coordinator.
Client — a connector inside the host. Each client maintains exactly one dedicated connection to one server. If the host connects to three servers, it spins up three clients. The client handles the protocol handshake and shuttles messages back and forth. You rarely think about clients directly; they are the host’s internal wiring.
Server — a standalone program that exposes capabilities over MCP. A GitHub server knows how to talk to GitHub; a database server knows how to run queries. Servers are deliberately simple and focused, and they can run locally on your machine or remotely on the internet.

The relationship is strict: one host, many clients, one server per client.

                    ┌─────────────────────────────┐
                    │   HOST  (the AI application) │
                    │                             │
                    │   ┌────────┐  ┌────────┐    │
                    │   │Client A│  │Client B│    │   ← one client per server
                    │   └───┬────┘  └───┬────┘    │
                    └───────┼───────────┼─────────┘
                            │           │
                     ┌──────▼───┐  ┌────▼─────┐
                     │ Server A │  │ Server B │    ← focused, independent
                     │ (GitHub) │  │(Database)│
                     └──────────┘  └──────────┘

A deliberate design rule: a server can never read your whole conversation or peek into other servers. The host keeps each server boxed in, sharing only what a given task requires. That isolation is a security feature, not an accident, and it is written into the specification.

What servers expose: tools, resources, prompts

A server offers up to three kinds of capability. The distinction between them comes down to who is in control — the model, the application, or the user.

Primitive	Who controls it	What it is	Everyday example
Tools	The model	Functions the AI can call to do something or fetch live data	`send_email`, `query_db`, `create_ticket`
Resources	The application	Read-only data the host can pull in as context	a file’s contents, a database schema, a wiki page
Prompts	The user	Reusable templates a person deliberately invokes	a “/summarize” command, a code-review template

Tools are the stars of the show — they are how an AI acts. Each tool has a name, a description written for the model to read, and a schema describing its inputs (and optionally its outputs). Because tools can trigger real actions, MCP insists there should always be a human able to approve or deny them.

Resources are passive data. Where a tool is a verb, a resource is a noun. The application decides how and when to feed a resource into the model’s context — for instance, attaching the file you have open in your editor.

Prompts are user-triggered shortcuts. Think of the slash-commands in a chat app: a prompt is a pre-written, parameterized message the user chooses on purpose, like a “draft release notes” template that expands into a fully formed instruction.

What clients can offer back: sampling, roots, elicitation

The conversation is not one-way. Clients can expose their own features to servers:

Sampling lets a server ask the host to run a language-model completion on its behalf — useful when a server needs a bit of AI reasoning mid-task but should not hold its own API keys. The host stays in control of which model runs and whether the request is allowed.
Roots let the client tell a server which files or directories it is allowed to operate within — a boundary marker that keeps a filesystem server from wandering outside the project folder.
Elicitation (added in mid-2025) lets a server pause and ask the user for more information through the host — for example, “Which environment should I deploy to?” — instead of failing or guessing.

The machinery: messages, transports, capabilities, lifecycle, sessions

Underneath the primitives sits the plumbing that makes everything reliable.

Messages. Every exchange is a JSON-RPC 2.0 message — a small, well-defined JSON structure. There are three types: requests (which expect a reply and carry an ID), responses (which return a result or an error for a given ID), and notifications (one-way messages that expect no reply, like “the list of tools just changed”).
Transport. The transport is how those messages physically travel. MCP defines two standard ones, covered in the next section: stdio for local servers and Streamable HTTP for remote ones.
Capabilities. When a client and server first connect, they each declare what they support — “I offer tools and resources,” “I can handle sampling.” This capability negotiation means neither side assumes a feature the other lacks, and it lets the protocol grow without breaking older implementations.
Lifecycle. Every connection follows a defined arc: initialize (exchange versions and capabilities) → operate (do the real work) → shut down. We will trace it in the architecture section.
Sessions. A session is one logical run of related exchanges between a client and a server, beginning at initialization. In the current stable protocol, sessions are stateful — the connection remembers context as it goes. (This is one of the things the upcoming 2026 revision changes; more on that later.)

That is the entire cast. Host, client, server; tools, resources, prompts; sampling, roots, elicitation; and the messages, transports, capabilities, lifecycle, and sessions that hold it together. Everything else in MCP is detail hanging off these.

A real-world example: asking an AI about your database

Let’s ground all of that in one complete, realistic scenario and narrate every hop. This is the “user asks → MCP connects → answer comes back” flow spelled out fully.

The setup. You are a product manager using an AI assistant (the host) that has a database MCP server connected. The server sits in front of your company’s read-only analytics database.

Step 1 — You ask a question. In plain English: “What were our top three products by revenue last week?” You do not know SQL and you do not need to.

Step 2 — The host prepares the model’s view. Before answering, the host queries each connected server for its tools using tools/list. The database server reports a tool called run_query with a description (“Run a read-only SQL query against the analytics database”) and an input schema (a single sql string). The host includes that tool definition alongside your question when it calls the model.

Step 3 — The model reasons and picks a tool. The model reads your question, sees the run_query tool, and realizes it can answer with data rather than a guess. It generates the SQL — something like selecting product, summing revenue, grouping, ordering, and limiting to three — and emits a request to call run_query with that SQL as the argument. It does not execute anything; it produces intent.

Step 4 — The human checkpoint. Because tools can touch real systems, a well-built host shows you (or a policy) what is about to run and waits for approval. You glance at the query, see it is a harmless read, and approve. This consent step is core to MCP’s security model, not an optional nicety.

Step 5 — The client sends tools/call. The host’s MCP client wraps the request in a standard JSON-RPC message and sends it to the database server over the transport.

Step 6 — The server executes. The database server — the only piece that holds credentials and knows the connection details — runs the SQL against the database and gets back three rows.

Step 7 — The result travels home. The server formats the rows into a tool result and returns it through the client to the host. Modern MCP can return this both as human-readable text and as structured content (typed JSON), so the model gets clean, machine-parseable data.

Step 8 — The model writes the answer. Now holding real numbers, the model composes: “Last week your top three products by revenue were the Pro Plan ($48,200), the Starter Kit ($31,900), and the Add-on Pack ($22,400).”

Step 9 — You read a sentence, not a spreadsheet. The entire dance — tool discovery, SQL generation, approval, execution, structured result, natural-language synthesis — happened in a second or two, and you saw none of the machinery. That invisibility is the point.

Notice what MCP made possible that a bare chatbot could not: the answer is grounded in live, private data the model was never trained on, fetched safely through a server that owns the credentials, with a human able to veto the action. That combination — live data, safe access, human control — is why MCP is more than a convenience.

MCP explained through six analogies

Different mental models click for different people. Here are six lenses on the same idea. Pick whichever makes it stick.

1. USB-C — the universal port. Before USB-C, every device had its own cable. One standard connector replaced a drawer full of chargers. MCP is that connector for AI: one interface, and any model can plug into any tool. This is the analogy MCP’s own creators use.

2. The restaurant. You (the model) sit at a table and order in plain language. The waiter (the MCP client) carries your order to the kitchen (the server) and brings food back. You never enter the kitchen, never learn the recipes, never touch the stove. You state what you want; the kitchen handles how. A new dish appears on the menu (a new tool) and you can order it immediately, no retraining required.

3. The airport. Planes from hundreds of airlines, built by different manufacturers, all land using the same runways, gates, and control-tower procedures. That shared infrastructure is what makes global travel possible. MCP is the standardized runway-and-tower system for AI: build your server to the spec and any compliant “aircraft” can dock with it.

4. The translator. A model speaks “AI intent.” Your database speaks SQL, GitHub speaks its own API, Slack speaks another. MCP is the simultaneous interpreter in the middle, turning the model’s request into each system’s native language and translating the reply back — so neither side has to learn the other’s tongue.

5. The library with a card catalog. Walk into a good library and you do not wander the stacks hoping to find a book. You consult the catalog, which lists every title with a description and a location. An MCP server is a system with a built-in catalog: it publishes a list of its tools and resources, each described in plain language, so the model can look up exactly what is available before reaching for anything.

6. The postal / delivery system. You do not need to know the roads, sorting centers, or trucks to send a package — you write a standard address and drop it in a box. MCP is the addressing-and-delivery standard for AI requests: the client addresses a message in the agreed format, and the protocol handles routing it to the right server and bringing the response back.

No single analogy is perfect — the restaurant hides the security model, the USB-C image hides the discovery step — but together they cover the shape of the thing: one standard interface, self-describing capabilities, a clear split between deciding and doing.

MCP vs APIs, plugins, and function calling

This is where a lot of confusion lives, so let’s clear it up carefully. MCP does not replace APIs or function calling — it sits at a different layer and often uses them. Here is how the pieces relate.

Approach	What it is	Standardized across vendors?	Self-describing to a model?	Best for
REST API	HTTP endpoints for program-to-program data exchange	No — every API is different	No	Classic software-to-software integration
GraphQL	A query language letting clients request exactly the data they want from one endpoint	No — schema is per-service	Partly (has a schema)	Flexible data fetching for apps
Plugin (e.g. early ChatGPT plugins)	A vendor-specific way to extend one AI product	No — locked to one platform	Yes, within that platform	Extending a single closed product
Function calling	An LLM feature: the model outputs a structured request to call a function you defined	No — you wire each function per app	Yes, per app	Letting one model call tools you coded into your app
MCP	An open protocol for exposing tools, data, and prompts to any AI	Yes — one spec, any vendor	Yes — built-in discovery + schemas	Reusable, portable AI-to-system connections

How function calling and MCP fit together

These two get conflated the most, so let’s separate them cleanly.

Function calling is a capability of the model: given a set of function definitions, the model can respond with “call this function with these arguments.” But you still have to define those functions, write the code behind each one, and re-do that work in every application. Function calling is the model’s ability to express a tool call.

MCP is the standard plumbing that delivers tool definitions to the model and carries the resulting calls to whoever implements them — in a portable, reusable way. In fact, MCP typically uses the model’s function-calling ability under the hood: the tools an MCP server advertises become function definitions the model can call. The difference is reusability. A function you hand-wire lives and dies in one app. An MCP server you build works with every MCP-compatible host, forever.

A crisp way to hold it: function calling is the model raising its hand to use a tool; MCP is the standardized building, wiring, and staff that make the tool available to raise your hand about — across every app at once.

When to use what

Building a quick, single-app feature where the model calls two or three functions you control? Plain function calling is fine — no need for a protocol.
Exposing a capability you want many AI apps (or the public) to reuse, now and in the future? Build an MCP server.
Doing pure software-to-software integration with no AI in the loop? A regular API is the right tool; MCP would be overkill.
Want an AI to reach existing services you do not control? Look for an existing MCP server for that service, or wrap its API in a thin MCP server.

The mental model: APIs connect programs; function calling lets a model ask to run code; MCP standardizes and makes portable the whole business of exposing tools and data to AI. They are layers, not rivals.

The complete architecture

Now let’s zoom out and see the whole system as an architect would, layer by layer. Everything we have covered fits into two layers: a data layer (what the messages mean) and a transport layer (how they travel).

┌──────────────────────────────────────────────────────────────┐
│                        HOST APPLICATION                        │
│   conversation state · model access · consent · security       │
│                                                                │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐          │
│   │  Client 1   │   │  Client 2   │   │  Client 3   │          │
│   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘          │
│          │                 │                 │                 │
│  ┌───────┴─────────────────┴─────────────────┴──────────┐     │
│  │  DATA LAYER  —  JSON-RPC 2.0 messages                 │     │
│  │  lifecycle · capabilities · tools/resources/prompts   │     │
│  │  sampling · roots · elicitation · notifications       │     │
│  └───────────────────────────┬──────────────────────────┘     │
└──────────────────────────────┼────────────────────────────────┘
                               │
  ┌────────────────────────────┴──────────────────────────────┐
  │  TRANSPORT LAYER  —  how bytes move                        │
  │    • stdio     (local: launch server as a subprocess)      │
  │    • Streamable HTTP (remote: POST/GET + optional SSE)     │
  └────────────────────────────┬──────────────────────────────┘
                               │
        ┌──────────────────────┼──────────────────────┐
        ▼                      ▼                      ▼
  ┌───────────┐          ┌───────────┐          ┌───────────┐
  │ Server 1  │          │ Server 2  │          │ Server 3  │
  │  (local)  │          │  (local)  │          │ (remote)  │
  └───────────┘          └───────────┘          └───────────┘

The transport layer: stdio and Streamable HTTP

MCP separates what a message says from how it is delivered, which is why the same server logic can run locally or in the cloud with only a transport swap. Two transports are standard.

stdio (standard input/output) is for local servers. The host launches the server as a subprocess and talks to it through the operating system’s stdin/stdout pipes — the server reads JSON-RPC from its input and writes replies to its output, one message per line. It is fast, requires no network, and is the recommended default for anything running on the same machine. One rule bites beginners: a stdio server must never print stray text to stdout (a rogue print() or console.log() corrupts the message stream) — logs go to stderr instead.

Streamable HTTP is for remote servers reachable over the network. The server exposes a single endpoint (say, https://example.com/mcp) that accepts HTTP POST requests for messages, and can optionally open a Server-Sent Events (SSE) stream to push multiple messages back — useful for streaming partial results or server-initiated requests. This transport, introduced in the March 2025 revision, replaced an older two-endpoint “HTTP+SSE” design that was awkward behind load balancers and proxies. The single-endpoint model plays far nicer with real infrastructure. (SSE itself is not gone — Streamable HTTP still uses it optionally for streaming; what was retired was the old separate-endpoint transport.)

You can also implement custom transports as long as they preserve JSON-RPC framing and the lifecycle — the protocol is deliberately transport-agnostic.

The lifecycle: initialize, operate, shut down

Every connection follows the same three-act structure.

  ── INITIALIZE ───────────────────────────────────────────────
  Client ──► Server :  initialize (my version, my capabilities)
  Server ──► Client :  here's my version + my capabilities
  Client ──► Server :  initialized  (notification: ready to go)

  ── OPERATE ──────────────────────────────────────────────────
  ...  tools/list, tools/call, resources/read, prompts/get  ...
  ...  notifications flow both ways as things change          ...

  ── SHUT DOWN ────────────────────────────────────────────────
  transport closes (stdin closed / HTTP connection ends)

Initialization. The client opens with an initialize request stating the protocol version it wants and the capabilities it offers. The server replies with the version it will use and its own capabilities. The client sends an initialized notification, and the session is live. If the two cannot agree on a version, they part ways cleanly.
Operation. Both sides now exchange the real messages — listing and calling tools, reading resources, fetching prompts — always staying within the capabilities each declared.
Shutdown. There is no ceremonial “goodbye” message; the connection ends via the transport. For stdio, the host closes the subprocess’s input and, if needed, terminates it. For HTTP, the connection simply closes.

Where security lives in the architecture

Security is not a bolt-on layer in MCP; it is distributed across the design. The host enforces user consent and keeps servers isolated from each other and from the full conversation. Remote servers use an OAuth 2.1-based authorization scheme. Local servers take credentials from their environment rather than over the wire. Streamable HTTP servers must validate request origins to prevent a class of browser-based attacks. We will give security its own full section shortly, because it is the part most tutorials skip and most production incidents involve.

That is the whole architecture: a host coordinating clients, a data layer of JSON-RPC primitives, a transport layer that moves the bytes, and focused servers at the edges — with security woven through every seam.

Where MCP is used today

MCP started as a way to wire local tools into a desktop AI app. Two years on, it shows up across the whole software stack. Here is a tour of where it actually lands, grouped by where the value shows up.

Developer tools and IDEs. This is MCP’s home turf. AI-powered editors use MCP servers to reach your files, run git commands, search your codebase, and query documentation. GitHub Copilot supports MCP in agent mode, MCP is generally available in VS Code (configured through a .vscode/mcp.json file), and Cursor, Zed, and Replit all speak it. Claude Desktop was the first host and remains a common way to try servers locally.

AI agents. AI agents — systems that plan and take multi-step actions — need a reliable way to use tools, and MCP has become their default hardware store. Instead of hand-coding each capability, an agentic workflow can pull from a catalog of ready-made servers. Frameworks like LangChain and LlamaIndex can consume MCP servers, and multi-agent systems use them as a shared tool bus.

Data and SaaS connectors. The long tail of MCP is integrations: databases (Postgres, SQLite, and more), GitHub, Slack, Google Drive, email, Notion, Jira, Linear, Stripe, and countless CRMs. Companies like Block, Atlassian, PayPal, Sentry, and Webflow have shipped MCP servers so their products can be driven by any compliant AI.

Here is how those map onto real jobs:

Domain	What an MCP server unlocks
Databases	Ask questions in English; the server runs safe, read-only queries
GitHub / GitLab	Open issues, review pull requests, search code, summarize commits
Slack / email	Draft and send messages, summarize threads, triage an inbox
Google Drive / Notion	Find, read, and summarize documents across a knowledge base
Jira / Linear	Create and update tickets, report on sprint status
CRM (Salesforce, HubSpot)	Look up accounts, log activity, draft follow-ups
Automation platforms	Chain many tools together into repeatable workflows

Enterprise and regulated industries. Because MCP includes an authorization model and keeps servers isolated, larger organizations use it to connect internal AI assistants to sensitive systems under audit and access controls. The patterns show up across healthcare (querying clinical systems while keeping data access controlled), finance (pulling account and market data through governed servers), education (connecting tutoring assistants to course material), and even robotics research, where an MCP server can expose a robot’s sensors and actuators as tools an AI can reason over. In every case the appeal is the same: connect once to a standard, reuse everywhere, and keep control at the host.

The through-line: anywhere an AI needs to reach past its own training data — into your files, your services, your live systems — MCP is becoming the way it reaches.

Build your first MCP server

Enough theory. Let’s build a working server. We will make a tiny “notes” server that can save a note and look notes up — small enough to read in one sitting, real enough to teach the pattern. I will show it in both Python and TypeScript using the current stable SDKs, then connect it to a real AI app and test it.

A quick note on versions: the official SDKs have a stable v1 line and a newer v2 line still in beta as of mid-2026. This tutorial uses the stable v1 APIs — the ones the official quickstart teaches. When v2 lands as stable, the class names shift slightly, but the shape you learn here carries over.

Folder structure

Keep it simple to start:

notes-server/
├── server.py          # (Python version)  — or
├── index.ts           # (TypeScript version)
├── package.json       # TS only
└── README.md

Option A — Python (with FastMCP)

Install. The official Python SDK ships in the mcp package. Python 3.10+ is required; the examples below use the CLI extra so you can test with the Inspector.

# using uv (recommended by the docs)
uv add "mcp[cli]"
# or with pip
pip install "mcp[cli]"

Write the server. FastMCP does the heavy lifting: you write plain functions, decorate them, and the SDK turns your type hints and docstrings into the JSON schemas MCP needs.

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

# 1. Create the server and give it a name.
mcp = FastMCP("Notes")

# A tiny in-memory store. In real life this would be a database or file.
notes: dict[str, str] = {}

# 2. Expose a TOOL — something the model can DO.
@mcp.tool()
def save_note(title: str, body: str) -> str:
    """Save a note under a title so it can be retrieved later."""
    notes[title] = body
    return f"Saved note '{title}'."

# 3. Expose another tool to read a note back.
@mcp.tool()
def get_note(title: str) -> str:
    """Retrieve the body of a previously saved note by its title."""
    return notes.get(title, f"No note found titled '{title}'.")

# 4. Expose a RESOURCE — read-only data the app can pull in as context.
@mcp.resource("notes://all")
def list_notes() -> str:
    """A newline-separated list of all saved note titles."""
    return "\n".join(notes.keys()) or "(no notes yet)"

# 5. Run the server over stdio (the default local transport).
if __name__ == "__main__":
    mcp.run(transport="stdio")

Read that top to bottom and you have the whole pattern. Every @mcp.tool() function becomes a tool the model can call; its parameters (title: str, body: str) become the input schema automatically; its docstring becomes the description the model reads to decide when to use it. The @mcp.resource("notes://all") function becomes a readable resource addressed by a URI. You wrote no JSON schema and no protocol code — the SDK generated all of it from ordinary Python.

Run it:

uv run server.py

Option B — TypeScript

Install. The official TypeScript SDK is one package; zod (a schema library) is a required companion for describing tool inputs.

npm install @modelcontextprotocol/sdk zod

Write the server:

// index.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 1. Create the server.
const server = new McpServer({ name: "notes", version: "1.0.0" });

const notes = new Map<string, string>();

// 2. Register a tool. The Zod schema describes its inputs.
server.registerTool(
  "save_note",
  {
    description: "Save a note under a title so it can be retrieved later.",
    inputSchema: {
      title: z.string().describe("A short, unique title for the note"),
      body: z.string().describe("The note's contents"),
    },
  },
  async ({ title, body }) => {
    notes.set(title, body);
    return { content: [{ type: "text", text: `Saved note '${title}'.` }] };
  },
);

// 3. Register a second tool to read a note back.
server.registerTool(
  "get_note",
  {
    description: "Retrieve a previously saved note by its title.",
    inputSchema: { title: z.string().describe("The note's title") },
  },
  async ({ title }) => {
    const body = notes.get(title) ?? `No note found titled '${title}'.`;
    return { content: [{ type: "text", text: body }] };
  },
);

// 4. Connect over stdio. IMPORTANT: log to stderr, never stdout.
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Notes MCP server running on stdio");
}
main();

Same idea, different language: registerTool takes a name, a config object (description plus a Zod input schema), and an async handler that returns a result. Notice console.error, not console.log — because stdout is the message channel for stdio servers, printing there would corrupt the protocol. That single detail trips up more first-time builders than anything else.

Test it with the MCP Inspector

Before wiring your server into a real AI app, test it in isolation with the official MCP Inspector — a small web tool that connects to your server and lets you click through its tools and resources by hand.

# Point the Inspector at your server:
npx @modelcontextprotocol/inspector uv run server.py       # Python
npx @modelcontextprotocol/inspector node index.js          # TypeScript (after building)

It opens a local web UI where you can see the tool list, fill in arguments, fire a save_note call, and confirm the response — all without a model in the loop. If it works in the Inspector, the server is sound; anything that breaks later is on the host side.

Connect it to Claude Desktop

To use your server in a real AI app, register it in the host’s config. For Claude Desktop, edit claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": ["--directory", "/ABSOLUTE/PATH/TO/notes-server", "run", "server.py"]
    }
  }
}

Use an absolute path, save, and fully restart the app. Your save_note and get_note tools now appear, and you can say “save a note called groceries with milk and eggs” and watch the model call your tool. The same mcpServers block works in Cursor (~/.cursor/mcp.json); VS Code uses a nearly identical format under a servers key in .vscode/mcp.json.

Debugging and deployment

Debugging. When something misbehaves, work outward: (1) reproduce it in the Inspector first — it removes the model as a variable; (2) read the server’s stderr log, where your console.error/stderr messages land; (3) confirm you used an absolute path in the host config; (4) restart the host after any config change, since most hosts read the file only at startup.

Deployment. A stdio server needs no deployment — it runs on the user’s machine as a subprocess. To make a server available remotely to many users, run it as a Streamable HTTP server behind a real URL, add authentication (see the security section), and host it like any web service. Local-first is the right way to learn; remote is how you ship to an organization.

Build your first MCP client

Most people consume MCP through an existing host, but building a client yourself demystifies the whole thing — and you will need it if you are embedding MCP into your own application. Here is a minimal TypeScript client that launches the notes server and calls a tool.

// client.ts
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

// 1. Describe how to start the server. The transport spawns it for you.
const transport = new StdioClientTransport({
  command: "node",
  args: ["index.js"],
});

// 2. Create the client and connect (this runs the initialize handshake).
const client = new Client({ name: "my-client", version: "1.0.0" });
await client.connect(transport);

// 3. Discover what the server offers.
const { tools } = await client.listTools();
console.log("Tools:", tools.map((t) => t.name)); // -> ["save_note", "get_note"]

// 4. Call a tool with arguments.
const saved = await client.callTool({
  name: "save_note",
  arguments: { title: "groceries", body: "milk, eggs, coffee" },
});
console.log(saved.content);

// 5. Read it back.
const got = await client.callTool({
  name: "get_note",
  arguments: { title: "groceries" },
});
console.log(got.content);

Follow the numbered steps and you have traced the client’s entire job: it starts the server, runs the initialize handshake (hidden inside connect), lists the tools, and calls them. In a real application you would sit a language model between steps 3 and 4 — feeding the discovered tools to the model and letting it decide which callTool to make. That is precisely what a host like Claude Desktop does; you have just built the skeleton it hangs a model on. The client also exposes listResources, readResource, listPrompts, and getPrompt for the other primitives.

Common mistakes and how to avoid them

Almost everyone hits the same handful of snags. Here they are with fixes.

Mistake	What happens	Fix
Printing to stdout in a stdio server	A stray `print()` / `console.log()` corrupts the JSON stream; the client sees garbage	Log to stderr only; keep stdout for MCP messages
Relative paths in host config	The host cannot find or launch your server	Always use absolute paths in the config
Not restarting the host	Config or code changes seem to do nothing	Fully restart the host after edits — most read config only at startup
Vague tool descriptions	The model picks the wrong tool or fills in bad arguments	Write descriptions and parameter docs for the model to read — be specific about what each tool does and when to use it
Doing too much in one tool	A giant “do_everything” tool confuses the model	Prefer small, single-purpose tools with clear names
Returning huge blobs	Latency spikes and context bloat	Return concise, structured results; paginate or summarize large data
Skipping the Inspector	You debug the model and the server at once	Test the server alone in the Inspector first
Trusting tool output blindly	A compromised server can inject instructions	Treat server-provided text as untrusted; keep a human in the loop for actions

The theme behind most of these: an MCP server is a user interface for a model. The clearer and more focused each tool is, the better the model uses it. Sloppy descriptions are the single biggest cause of “the AI keeps doing the wrong thing.”

Security: the part you can’t skip

MCP gives an AI real reach into real systems, which means security is not optional garnish — it is the main course. Let’s cover it properly.

MCP’s specification is explicit that the host must keep humans in control. Users should consent to data access, approve tool invocations before they run, and understand what each tool does. A server represents arbitrary code execution, so its tool descriptions should be treated as untrusted unless the server is trusted. Build these consent gates in; do not assume the model will be careful.

Authorization for remote servers (OAuth 2.1)

Local stdio servers take their credentials from the environment — an API key in an environment variable, say. But remote servers reached over HTTP need real authorization, and MCP defines an OAuth 2.1-based scheme for it (introduced in the March 2025 revision and hardened in June 2025). The key ideas:

The MCP server acts as an OAuth Resource Server — it validates access tokens but does not mint them.
The client acts as an OAuth client and must use PKCE, the standard protection against intercepted authorization codes.
Servers publish Protected Resource Metadata (per RFC 9728) pointing clients to the right authorization server.
Clients must send a Resource Indicator (RFC 8707) naming which server a token is for, and servers must validate that the token’s audience is themselves — and must never pass a client’s token through to some downstream API.
Everything runs over HTTPS; bearer tokens go in the Authorization header, never in a URL.

You do not have to memorize the RFC numbers. The point to internalize: tokens are bound to a specific server and never forwarded, which stops a whole family of impersonation attacks.

The risks worth knowing

Risk	What it is	Mitigation
Prompt injection	Malicious text in data the model reads hijacks its behavior	Treat all fetched content as untrusted; require human approval for actions; constrain what tools can do
Tool poisoning (research term, not a spec section)	Hidden instructions buried in a tool’s description trick the model into leaking data	Only install servers you trust; pin and review tool definitions; isolate servers
”Rug-pull” servers (research term)	A server changes a tool’s behavior after you approved it	Verify server sources; watch for tool-definition changes; prefer signed/registry-listed servers
Confused deputy	A proxy is tricked into using its own authority on an attacker’s behalf	Enforce per-client consent; exact redirect-URI matching; validate `state`
Token passthrough	A server forwards your token to another service	Forbidden by spec — servers must reject tokens not issued for them
Over-broad permissions	A server or token can do far more than the task needs	Least-privilege scopes; short-lived tokens; scope elevation only when required
Command injection / local compromise	A malicious local server runs arbitrary code with your privileges	Show the exact launch command before install; sandbox servers; only run trusted code
DNS rebinding	A website tricks your browser into talking to your local server	Streamable HTTP servers must validate the `Origin` header and bind to localhost

A candid caveat on terminology: “tool poisoning” and “rug-pull” come from the security-research community (notably Invariant Labs’ 2025 write-ups), not from the official specification, whose formal security pages focus on the OAuth and transport issues above. I flag that so you cite them correctly — they are real, demonstrated attacks, but they are researcher framing layered on top of the spec’s own guidance rather than clauses within it.

A short security checklist

Only connect servers you trust; treat a random server from the internet like a random executable — because that is what it is.
Keep a human in the loop for anything that writes, sends, deletes, or spends.
Give servers and tokens the least privilege that gets the job done.
Use short-lived, audience-bound tokens for remote servers; keep secrets in environment variables, not in code or URLs.
Validate origins on HTTP servers; bind local servers to localhost.
Log tool calls so you can audit what the AI actually did.

Security in MCP is mostly about not trusting by default: not the server’s descriptions, not the fetched data, not a token’s reach. Design as if any single component could be hostile, and the blast radius of a mistake stays small.

Performance: latency, caching, and scaling

Once a server works, the next questions are how fast and how far it scales. A few practical levers.

Latency. The transport matters. A local stdio server has almost no overhead — it is inter-process communication on the same machine. A remote HTTP server adds network round-trips, so it is more sensitive to distance and connection setup. Beyond transport, the biggest latency cost is usually the work the tool itself does (a slow query, a slow third-party API) and the size of the result the model then has to read. Keep tool responses tight.

Caching. If a resource or tool result rarely changes — a database schema, a config file, a product catalog — cache it rather than fetching every time. The protocol is moving to help here: recent and upcoming revisions add caching metadata (hints like a time-to-live and a cache scope) so servers can tell clients how long a result stays fresh. Until you have that, cache in your server: memoize expensive reads and invalidate on change.

Scaling and concurrency. A stdio server serves one host process; you scale it by running a copy per user, which is trivial. Remote HTTP servers are where scale gets interesting, because you may have thousands of clients hitting one deployment. Today’s stateful sessions can require sticky routing (a client’s requests should return to the instance holding its session). This is exactly the friction the 2026 stateless redesign targets: by moving protocol state out of the connection and into each request, any server instance can handle any request, so you can put a plain load balancer in front and scale horizontally like any stateless web service.

Optimization habits that pay off:

Return structured, minimal results — give the model clean typed data, not a wall of text it has to parse.
Prefer many small tools over one mega-tool; the model calls them more accurately and you cache them independently.
Paginate large lists (tools/list and resource lists support it) rather than dumping everything at once.
Push slow work into background tasks where the protocol supports it (see Tasks, below) so a long job does not block the connection.

Advanced topics and the road ahead

Once the basics are comfortable, here is where MCP gets more powerful — and where it is heading.

Streaming. Over Streamable HTTP, a server can push a sequence of messages back on an SSE stream rather than making the client wait for one big reply. That enables progress updates on long operations and server-initiated requests mid-task.

Tool chaining. Real agents rarely call one tool. They loop: call a tool, read the result, decide the next call, and repeat until the goal is met. MCP is the substrate for that loop — the model chains tools/call after tools/call, and because every server speaks the same protocol, tools from different servers compose freely. A single task might read a file from one server, query a database through another, and open a GitHub issue through a third.

Memory and context. MCP does not itself give a model long-term memory, but it is a common way to provide one: a “memory” server exposes tools to store and recall facts, so the AI can persist information across sessions. Combined with retrieval-augmented generation, MCP servers become the model’s connection to knowledge it was never trained on.

Multi-agent systems. In an agentic architecture with several cooperating models, MCP acts as the shared tool bus every agent draws from — one catalog of capabilities, many agents using it, with the host mediating access.

Long-running work (Tasks). The 2025-11-25 revision added an experimental Tasks feature for durable requests: kick off a long job, get a handle, and poll for the result later instead of holding a connection open. This is how MCP grows beyond quick request-reply into slow, real-world operations.

Server-rendered UIs (MCP Apps). An official extension arriving with the 2026 revision, MCP Apps, lets a server ship an interactive HTML interface rendered in a sandboxed frame inside the host — so a tool can present a real form or dashboard, not just text.

The 2026 stateless redesign. The upcoming 2026-07-28 revision is the largest change since launch. It removes the initialize handshake and the protocol-level session, carrying version and capability info on each request instead, so the protocol becomes stateless and trivially scalable. It also formalizes an extensions framework (features identified by reverse-DNS names, versioned on their own), standardizes on full JSON Schema 2020-12, and adds a feature-lifecycle policy guaranteeing at least twelve months between deprecating a feature and removing it. As part of that cleanup, Roots, Sampling, and Logging are marked deprecated in favor of simpler patterns (pass paths as parameters, call model APIs directly, log to stderr/OpenTelemetry). As of this writing that revision is a release candidate, not yet final — so treat its specifics as forward-looking.

Governance and the roadmap. With MCP now under the Linux Foundation, its direction is set by working groups rather than one company. The published 2026 roadmap prioritizes scalable transports, better agent-to-agent communication, enterprise readiness (audit trails, single sign-on, gateways), and a maturing contributor process. The signal for you: MCP is stabilizing into long-lived infrastructure, which is exactly when it becomes safe to build on.

20 MCP interview questions with answers

A study set for interviews — or a self-test to check your understanding. Answers are concise on purpose.

1. What is MCP in one sentence? An open standard that lets any AI application connect to any tool or data source through one consistent interface.

2. What problem does MCP solve? The N×M integration problem — instead of building a custom connector for every AI-app-and-data-source pair, each side implements MCP once.

3. Name the three participant roles. Host (the AI application), client (a connector inside the host), and server (the program exposing capabilities).

4. What is the relationship between clients and servers? One-to-one: each client maintains exactly one connection to one server; a host runs many clients.

5. What are the three server primitives? Tools (model-controlled actions), resources (application-controlled read-only data), and prompts (user-controlled templates).

6. How do tools, resources, and prompts differ in control? Tools are chosen by the model, resources are supplied by the application, and prompts are invoked by the user.

7. What are sampling, roots, and elicitation? Client features offered to servers: sampling (server asks the host to run a model completion), roots (client tells the server which directories it may use), and elicitation (server asks the user for more input).

8. What message format does MCP use? JSON-RPC 2.0 — requests, responses, and notifications.

9. What transports does MCP define? stdio for local servers and Streamable HTTP for remote ones; custom transports are allowed.

10. What replaced the old HTTP+SSE transport, and when? Streamable HTTP, in the March 2025 (2025-03-26) revision.

11. Walk through a tool call. The host lists tools, the model chooses one, the client sends tools/call, the server executes and returns a result, and the model turns it into an answer — with a human approving the action.

12. How is MCP different from function calling? Function calling is the model expressing a tool call; MCP is the portable, standardized plumbing that delivers tool definitions and carries the calls across any host. MCP often uses function calling underneath.

13. How does MCP differ from a REST API? A REST API is bespoke per service and not self-describing to a model; MCP is one standard, self-describing (with discovery and schemas), and designed for AI consumers.

14. What happens during initialization? The client and server exchange protocol versions and capabilities, then the client sends an initialized notification.

15. What is capability negotiation? At connect time each side declares what it supports, so neither assumes a feature the other lacks and the protocol can evolve safely.

16. How does authorization work for remote servers? OAuth 2.1: the server is a Resource Server validating audience-bound tokens, the client uses PKCE, and tokens are never passed through to downstream services.

17. Why must a stdio server avoid writing to stdout? stdout is the JSON-RPC message channel; stray output corrupts the stream. Logs go to stderr.

18. What is structured tool output? A way for tools to return typed JSON (via an output schema) alongside human-readable text, added in the June 2025 revision.

19. What is the current stable spec version, and what is coming? 2025-11-25 is current; the 2026-07-28 revision (in release candidate) makes the protocol stateless and adds an extensions framework.

20. Who governs MCP now? It moved to the Linux Foundation (Agentic AI Foundation) in December 2025, with shared, vendor-neutral governance.

Frequently asked questions

What does MCP stand for? Model Context Protocol.

Who created MCP? Anthropic, the company behind Claude, open-sourced it on November 25, 2024. It is now stewarded by the Linux Foundation.

Is MCP open source? Yes. The specification, SDKs, and reference servers are open source, and the standard is community-governed.

Is MCP only for Claude? No. It began with Claude but is vendor-neutral. OpenAI, Google, Microsoft, and many tools support it; any compliant host works with any compliant server.

Do I need to know AI to use MCP? To use MCP-enabled apps, no. To build servers, you need ordinary programming skills — no machine-learning background required.

What languages can I build MCP servers in? Official SDKs cover TypeScript, Python, C#, Go, Java, Rust, Kotlin, Swift, Ruby, and PHP, among others.

Is MCP free? The protocol and SDKs are free and open. You pay only for whatever your servers connect to (a database, an API) and for the AI model you use.

How is MCP different from an API? APIs connect software to software and are bespoke per service; MCP is one standard interface, self-describing to models, designed for AI to discover and use tools.

Does MCP replace function calling? No — it complements it. MCP standardizes and makes portable the tools that function calling lets a model invoke.

Is MCP the same as ChatGPT plugins? No. Plugins were tied to one product; MCP is an open standard that works across products.

What is an MCP server, concretely? A small program that exposes tools, data, and prompts over the protocol — for example, a server that runs database queries or manages GitHub issues.

What is an MCP client? The connector inside a host that maintains one connection to one server and shuttles messages.

What is the host? The AI application you use — Claude Desktop, an AI code editor, a custom agent — which manages clients, talks to the model, and enforces consent.

Can MCP servers run in the cloud? Yes. Local servers use stdio; remote servers use Streamable HTTP over a URL, with OAuth-based authorization.

Is MCP secure? It is designed around consent, isolation, and audience-bound tokens, but security depends on how you deploy it. Only connect trusted servers and keep a human in the loop for actions.

Can an MCP server read my whole conversation? No. By design, a server sees only what the host chooses to share and cannot peek into other servers or the full history.

What is Streamable HTTP? The standard remote transport: one endpoint handling HTTP POST for messages plus optional SSE streaming for server-to-client messages.

What happened to the old HTTP+SSE transport? It was replaced by Streamable HTTP in March 2025 and is deprecated, though servers can keep backward compatibility.

What are tools, resources, and prompts again? Tools are actions the model calls, resources are read-only data the app pulls in, and prompts are templates the user invokes.

What is elicitation? A feature letting a server ask the user for more information mid-task, through the host, instead of guessing or failing.

What is sampling in MCP? A feature letting a server ask the host to run a model completion on its behalf, so the server needs no model API key of its own.

What is the MCP Registry? An official, open catalog (launched in preview in September 2025) for discovering publicly available MCP servers.

How many MCP servers exist? The official registry lists on the order of a couple thousand, while third-party directories tracked tens of thousands by early 2026 — counts move fast, so treat any number as a snapshot.

Do LangChain and LlamaIndex support MCP? Yes — both can consume MCP servers, so agents built with them can use MCP tools.

Can I use MCP in VS Code and Cursor? Yes. MCP is generally available in VS Code and supported in Cursor, each with a small JSON config file.

How do I test an MCP server? Use the MCP Inspector (npx @modelcontextprotocol/inspector ...), which connects to your server and lets you exercise its tools by hand.

What is the current version of MCP? The current stable specification is dated 2025-11-25; a 2026-07-28 revision is in release-candidate status.

Is MCP production-ready? Yes — it runs in production across many companies, with stable SDKs and a formal governance process under the Linux Foundation.

What is the difference between MCP and A2A? MCP standardizes how an AI connects to tools and data; agent-to-agent (A2A) approaches focus on how autonomous agents talk to each other. They address different layers and can coexist.

Will learning MCP still be useful in a few years? The fundamentals — hosts, clients, servers, tools, resources, prompts — are stable and community-governed, so the core knowledge is durable even as details evolve.

What is the fastest way to start? Install an SDK, build the tiny notes server above, test it in the Inspector, and connect it to Claude Desktop or VS Code. You will understand MCP better from one hour of building than from a day of reading.

Glossary of MCP terms

MCP (Model Context Protocol) — an open standard for connecting AI applications to external tools and data.
Host — the AI application that runs clients, talks to the model, and enforces consent.
Client — a connector inside the host with a one-to-one connection to a server.
Server — a program that exposes tools, resources, and prompts over MCP.
Tool — a function the model can call to take an action or fetch live data.
Resource — read-only data the application can pull into the model’s context.
Prompt — a reusable, user-invoked message template.
Sampling — a server asking the host to run a model completion for it.
Roots — boundaries (usually directories) the client permits a server to work within.
Elicitation — a server asking the user for more input through the host.
JSON-RPC 2.0 — the lightweight message format MCP uses.
Request / Response / Notification — the three message types (reply expected / reply / one-way).
Transport — how messages travel: stdio (local) or Streamable HTTP (remote).
stdio — the local transport using a subprocess’s standard input and output.
Streamable HTTP — the remote transport using one HTTP endpoint plus optional SSE.
SSE (Server-Sent Events) — a one-way streaming channel from server to client.
Capability negotiation — declaring supported features at connection time.
Lifecycle — the initialize → operate → shut down arc of a connection.
Session — one logical run of related exchanges between a client and server.
Structured output — typed JSON a tool returns alongside human-readable text.
Tasks — an experimental feature for long-running, pollable requests.
MCP Apps — an extension letting servers render interactive UIs in the host.
OAuth 2.1 — the authorization framework for remote MCP servers.
PKCE — a standard protection for OAuth authorization codes.
Resource Indicator — a marker binding a token to the specific server it is for.
MCP Registry — the official catalog of publicly available servers.
MCP Inspector — the official tool for testing servers by hand.
Function calling — a model’s ability to output a structured request to call a function; MCP builds on it.

Key takeaways

MCP is a universal adapter for AI. One open standard lets any compliant AI app connect to any compliant tool or data source — build a connector once, use it everywhere.
It solves the N×M problem. Instead of a custom bridge for every app-and-system pair, each side implements the protocol a single time.
Three roles, three primitives. Host, client, and server; tools, resources, and prompts. Master those six words and the rest follows.
Deciding vs doing. The model decides what to do; the server knows how; the protocol carries the request between them.
Security is consent-first. Isolation, human approval for actions, and audience-bound tokens keep the blast radius small — but only if you deploy carefully and trust your servers.
It is real infrastructure now. Backed by every major AI vendor and governed by the Linux Foundation, MCP is stable enough to build on, with a stateless redesign making it even more scalable.
The best way to learn it is to build it. An hour with the notes server and the Inspector teaches more than any article — including this one.

Sources and further reading

Everything factual in this guide is drawn from primary sources. The most useful starting points:

Official documentation and specification — modelcontextprotocol.io and the current spec at modelcontextprotocol.io/specification/2025-11-25.
The original announcement — Anthropic, “Introducing the Model Context Protocol” (November 25, 2024).
Specification changelogs — the 2025-03-26, 2025-06-18, and 2025-11-25 key-changes pages.
The 2026 revision — the 2026-07-28 release-candidate announcement and the 2026 roadmap.
Governance — GitHub’s writeup, “MCP joins the Linux Foundation” (December 2025).
SDKs and tools — the modelcontextprotocol GitHub org, the server quickstart, and the MCP Inspector.
Security — the spec’s security best practices and authorization pages.

If you want to go deeper on the ideas around MCP, these related explainers help: how large language models actually work, what retrieval-augmented generation is, and the rise of AI agents.

MCP is young, but the shape of it is settled: a shared socket that lets AI reach the real world safely. Learn the six words — host, client, server, tools, resources, prompts — build the little notes server, and you will understand something most of the industry is still catching up to.