What Is Model Context Protocol? The Beginner's Guide (Hosts, Clients, Servers, and the N+M Fix)
CodexFuse Team · 2026-11-04T07:17:20.898Z · 15 min read min read
Every AI assistant has the same blind spot: it can reason brilliantly, but by default it knows nothing about your files, your database, or your tools. The Model Context Protocol — MCP for short — is the open standard that fixes this, and this guide explains it from scratch: what the protocol is, the three roles every connection uses, how a request actually flows, and where MCP differs from plain function calling.
MCP is a beginner-friendly topic but a fast-moving one: the specification is versioned in dated revisions, and the newest one — 2026-07-28 — changed the handshake itself. Every fact here is dated and sourced as of 4 November 2026. If you want to see the protocol in a real product afterwards, the Thunder Client MCP Server guide walks through an MCP server inside a familiar API client.
What Is Model Context Protocol, Exactly?
The Model Context Protocol is an open protocol that standardizes how applications provide context to large language models. That is the official one-line definition carried on the protocol's own documentation. The current specification page phrases it slightly more fully: "The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools."
If you searched for "MCP explained" and landed here: that is the entire concept. The analogy the official intro page reaches for is the one everyone repeats: "Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems." One plug shape, any device. One protocol, any model and any tool.
Two things MCP is not: it is not a product you buy, and it is not a hosted platform. It is a set of message shapes, a small lifecycle, and capability rules — published as dated revisions of an open specification. Nothing about the protocol runs on someone else's server unless you choose to put it there.
What Problem Does MCP Solve?
Before MCP, every AI application that wanted to reach a tool had to build its own adapter for it. Connect five AI apps to twenty tools and you have up to one hundred custom integrations to build, test, and maintain — the N×M integration problem. Every vendor did it slightly differently, so a connector written for one assistant could not be reused by another.
MCP replaces the fragmented glue with a single protocol: the tool's author writes one MCP server, and every MCP-compatible AI application can use it. Anthropic's November 2024 announcement put it this way: "MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol." Write the server once; every compliant model and agent can speak to it.
Note the boundary the protocol draws: MCP replaces the bespoke wrapper layer between a model and an API, not the API itself. Your REST and database APIs stay where they are — MCP standardizes how the AI discovers them and calls them.
What Are the Three Roles: Host, Client, and Server?
Every MCP connection has exactly three actors, and naming them correctly is half the protocol. Getting these mixed up is the most common beginner confusion, so here they are precisely as the specification defines them:
- Host. "The host process acts as the container and coordinator." This is the AI application you actually use — Claude Desktop, Cursor, VS Code, or a custom agent. The host creates and manages clients, enforces security policies, and asks for your consent before tools run.
- Client. "Each client is created by the host and maintains an isolated server connection." The client lives inside the host; you never interact with it directly. The specification is explicit about the shape: "A host application creates and manages multiple clients, with each client having a 1:1 relationship with a particular server."
- Server. "Servers provide specialized context and capabilities" and "Expose resources, tools and prompts via MCP primitives." A server "can be local processes or remote services" — it is simply a program that speaks MCP.
The 1:1 client-to-server relationship is the detail that trips people up: one host can talk to many servers, but it opens a separate client for each one. Claude Desktop talking to a filesystem server and a database server is running two clients, not one.
How Does an MCP Request Actually Work?
Here is the full arc of a single tool-using request, in order. This is the "model context protocol how it works" in the order your mental model should store it:
- You prompt the host. You ask your AI app something that needs outside data — "summarize the open issues in my repo."
- Connection and capability exchange. For each server the host is configured to use, its client opens a connection and the two sides exchange capabilities: the server advertises what it offers, the host states what it supports, and they agree on a feature set before any real work happens. (Under the newest 2026-07-28 spec revision the old initialize handshake is gone — connections are stateless — but the capability-advertisement step remains the heart of setup.)
- Discovery. The server sends the client its list of tools, resources, and prompts — each with a name, a description, and an input schema. This list becomes part of what the model sees.
- The model decides. The language model reads your prompt plus the available tool descriptions and decides whether a tool is needed. This is the function-calling step, and it is where MCP hands off to the model's own judgment.
- You consent. "Hosts must obtain explicit user consent before invoking any tool." The host shows you what the model wants to run and waits for approval — the safety valve that keeps agentic tools from acting alone.
- The call goes out as JSON-RPC 2.0. The client sends a structured request to the server over the transport (more on those below).
- The server acts and answers. The server executes against the real system — reading files, querying the database, hitting an API — and returns the result. The model reads it and composes the final answer to you.
Notice what MCP owns in that chain: steps 2, 3, 6, and 7 — discovery, the message format, and the transport. It does not orchestrate multi-step workflows, own retries, or decide how the model reasons. MCP is the plug shape, not the appliance.
What Are Tools, Resources, and Prompts?
Every capability an MCP server exposes falls into one of three primitives. The split is deliberate: each one answers a different question and has a different control model. The specification's control labels are worth learning verbatim:
| Primitive | Control model (spec wording) | What it is | Example |
|---|---|---|---|
| Tools | Model-controlled | Actions the model can discover and invoke automatically — "the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts" | run a database query, search the web, create a file |
| Resources | Application-driven | Data the server exposes for context — "with host applications determining how to incorporate context based on their needs" | a file's contents, a database schema, a document |
| Prompts | User-controlled | Reusable templates "exposed from servers to clients with the intention of the user being able to explicitly select them for use" | a "summarize this code review" template the user picks |
The control models are the memory hook: tools do things (the model drives), resources are readable (the app decides what to attach), prompts are templates (the human picks). When someone asks "mcp tools resources prompts" — this table is the answer.
How Does MCP Talk Over the Wire?
The protocol's wire format is fixed: "The protocol uses JSON-RPC 2.0 messages to establish communication between" hosts, clients, and servers. JSON-RPC 2.0 is just a structured way to send requests and responses as JSON — method name, parameters, and an id to match replies.
On top of that wire format, the spec defines two standard transports:
| Transport | How it works | When it is used |
|---|---|---|
| stdio | The client launches the server as a subprocess and talks over standard input/output | Local servers on your own machine — the common beginner setup |
| Streamable HTTP | The server runs as an HTTP service the client connects to | Remote or shared servers |
An older third transport, HTTP+SSE (Server-Sent Events), was deprecated in the 2025-03-26 revision and reclassified as deprecated again in 2026-07-28 — it survives only through backwards compatibility, so new servers should use Streamable HTTP.
The specification moves in dated revisions rather than a rolling "latest" page, and the changelog reads like a protocol growing up. The five verified revisions:
| Revision | What changed |
|---|---|
| 2024-11-05 | The original release — JSON-RPC 2.0 wire format, stateful connections, client sampling |
| 2025-03-26 | HTTP+SSE transport deprecated; OAuth 2.1 authorization framework added for remote servers |
| 2025-06-18 | Security principles consolidated; referenced by the spec's own security best-practices guidance |
| 2025-11-25 | Architecture, tools, resources, prompts, transports, and authorization pages in their current documented form |
| 2026-07-28 | The stateless revision: the initialize/initialized handshake removed, protocol-level sessions and the Mcp-Session-Id header removed, server/discover added, SSE stream resumability removed |
The practical takeaway: tutorials written before August 2026 may describe a handshake the current spec no longer uses. When you follow an MCP tutorial, check which spec revision it targets — that one date explains most "this doesn't match the docs" confusion.
How Is MCP Different From Function Calling?
This is the comparison every beginner eventually asks for, and one sentence settles it. As the scalably.io explainer puts it: "Function calling is the model deciding when to call a tool. MCP is the standard for how that tool gets delivered to the model in the first place." Or shorter: "function calling is the model deciding to call a tool; MCP is how the tool gets to the model."
| Function calling | MCP | Plain REST API | |
|---|---|---|---|
| What it is | A model API feature: the model outputs structured JSON to invoke predefined functions | An open standard: discovery + message format + transport for tools, resources, prompts | An interface your code calls directly |
| Who defines the tools | You, inline in each API call | The server, advertised once and discovered by any host | You, in code |
| Reusability | Per-application, per-model | Write once — works in Claude, Cursor, VS Code, ChatGPT, custom agents | Per-integration glue code |
| Discovery | None — tools are hardcoded | Servers advertise capabilities; hosts negotiate | None — you read the docs |
They are complements, not competitors: MCP sits on top of function calling as the delivery and discovery layer. Your REST APIs stay too — MCP replaces the custom glue you used to write for every model and every tool, not the APIs themselves.
Is MCP Secure? The Tool-Poisoning Problem
MCP's power — letting a model read tool descriptions and act on them — is also its attack surface, and beginners should learn the defensive posture first. The specification's tool-safety page is blunt: "Tools represent arbitrary code execution and must be treated with appropriate caution. In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server."
The named attack is tool poisoning: a tool's description or schema contains hidden instructions that the model reads with full trust. Security researchers have demonstrated descriptions that tell the model to exfiltrate secrets or misuse other servers' tools — this is why the spec requires hosts to "obtain explicit user consent before invoking any tool" and why "users should understand what each tool does before authorizing its use."
Three rules that follow from the spec, stated once and remembered always:
- Install servers from sources you trust. The official MCP Registry verifies a server's publisher identity — it does not audit the code. A verified publisher badge is not a safety certificate.
- Read before you approve. The consent prompt is the security boundary. Approve tool calls deliberately, especially ones touching credentials, files outside a project, or external services.
- Scope remote servers with OAuth. For HTTP servers, the spec defines authorization on the OAuth 2.1 draft: a protected server acts as an OAuth 2.1 resource server and the client as an OAuth 2.1 client — so remote MCP access rides the same standard your other apps use.
What Is an MCP Server, Concretely?
"An MCP server is a program that implements the Model Context Protocol (MCP) to expose tools, resources, and prompts to MCP clients running inside an AI application or AI agent, communicating over a standard JSON-RPC 2.0 interface." That is the whole concept — a server is just a program that speaks the protocol, running as a local process or a remote service.
The official reference servers ship in the protocol's own repository and show the range: Everything (a test server exercising every feature), Fetch (web content), Filesystem (secure file operations), Git (repository tools), Memory (a knowledge graph), Sequential Thinking (structured reasoning), and Time. The servers named in Anthropic's original announcement — Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer — show the same idea applied to real products. If you are building agents that check live services, the CVE-Now agent guide shows the MCP pattern applied to vulnerability lookups.
For builders, the official SDKs cover ten languages — C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Swift, and TypeScript — and the Linux Foundation's formation announcement put the ecosystem's scale at "more than 10,000 published MCP servers now covering everything from developer tools to Fortune 500 deployments." Discovery happens through the official registry at registry.modelcontextprotocol.io.
Who Runs MCP Now? From Anthropic to the Linux Foundation
MCP was created at Anthropic by David Soria Parra and Justin Spahr-Summers and announced on 25 November 2024 — that is the Anthropic → open-standard origin, stated once. On 9 December 2025 the Linux Foundation announced the formation of the Agentic AI Foundation, with Anthropic's MCP, Block's goose, and OpenAI's AGENTS.md as the three founding contributions. Anthropic's CPO Mike Krieger framed the donation as the way MCP "stays open, neutral, and community-driven as it becomes critical infrastructure for AI."
What that means for you as a beginner: MCP is genuinely vendor-neutral now. Claude Desktop, ChatGPT, Cursor, VS Code, and Windsurf's Cascade all ship MCP client support, so a server you learn to use in one app works in the others. The Claude Code beginner guide is a natural next step if your editor-side interest started here, and if you self-host any of this, the VPS hosting guide covers running your own always-on remote servers.
Sources
- Model Context Protocol, introduction page — official definition, USB-C analogy, host/client/server wording, client support list: https://modelcontextprotocol.io/introduction
- Model Context Protocol, specification (current) — "enables seamless integration" definition, JSON-RPC 2.0 wire format: https://modelcontextprotocol.io/specification
- Anthropic, "Introducing the Model Context Protocol" (25 November 2024) — announcement, N×M problem, pre-built servers, Claude Desktop support, creators: https://www.anthropic.com/news/model-context-protocol
- Linux Foundation press release (9 December 2025) — Agentic AI Foundation formation, founding contributions, 10,000+ servers figure, Krieger quote: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
- MCP specification 2025-11-25, architecture — host/client/server roles, 1:1 client-server relationship: https://modelcontextprotocol.io/specification/2025-11-25/architecture
- MCP specification 2025-11-25, tools — "model-controlled" definition: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- MCP specification 2025-11-25, resources — "application-driven" definition: https://modelcontextprotocol.io/specification/2025-11-25/server/resources
- MCP specification 2025-11-25, prompts — "user-controlled" definition: https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
- MCP specification 2025-11-25, transports — stdio and Streamable HTTP, HTTP+SSE backwards compatibility: https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
- MCP specification 2025-11-25, authorization — OAuth 2.1 draft basis: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- MCP specification 2026-07-28, changelog — stateless revision, initialize handshake removal, session removal: https://modelcontextprotocol.io/specification/2026-07-28/changelog
- MCP specification, tool safety — untrusted tool descriptions, explicit user consent: https://modelcontextprotocol.io/specification/2025-11-25
- modelcontextprotocol/servers README — 10 official SDKs, reference servers, archived servers: https://github.com/modelcontextprotocol/servers
- StackNova, "What Is Model Context Protocol?" — USB-C model, three roles, three primitives: https://www.stacknova.dev/paths/ai/what-is-model-context-protocol
- Apideck, "A Primer on the Model Context Protocol" — N×M integration problem, primitives explainer: https://www.apideck.com/blog/a-primer-on-the-model-context-protocol
- Scalably, "MCP vs Function Calling" — the when-vs-how distinction, verbatim: https://scalably.io/blog/mcp-vs-function-calling
- Scalar, MCP server security guide — tool poisoning definition: https://scalar.com/learn/mcp/mcp-server-security
- Scalekit, vetting third-party MCP servers — registry verifies publisher not code, Invariant Labs findings: https://www.scalekit.com/blog/vet-third-party-mcp-servers
- Agentic AI Foundation docs — official one-line definition: https://agentic-ai.readthedocs.io/en/latest/Standards/agentic-ai-foundation/
Frequently Asked Questions
What does MCP stand for?
MCP stands for Model Context Protocol: an open standard that standardizes how applications provide context to large language models. It was introduced by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025.
Is MCP a product or a platform I sign up for?
Neither. MCP is a protocol — message shapes, a lifecycle, and capability rules published as dated spec revisions. You do not sign up for MCP; you use MCP-compatible apps (hosts like Claude Desktop or Cursor) and connect them to MCP servers, which are programs that speak the protocol.
Do I need MCP if my app already uses function calling?
They solve different halves of the problem. Function calling is the model deciding when to call a tool; MCP is the standard for how that tool gets delivered to the model — discovery, message format, and transport. MCP sits on top of function calling as the delivery layer, so most agent setups use both.
Is MCP only for Claude?
No. Although Anthropic created it, MCP is now vendor-neutral under the Linux Foundation. Claude Desktop, ChatGPT, Cursor, VS Code, and Windsurf's Cascade all support MCP clients, and the official SDKs span ten languages — a server you write once works across all of them.
How can I try an MCP server today?
The fastest path is a host you already use: Claude Desktop supports local MCP servers, and most AI-capable editors now ship an MCP client. Start with a read-only reference server like Filesystem pointed at a test folder, approve each tool call deliberately, and keep the spec's security posture in mind — treat tool descriptions as untrusted unless the server comes from a source you trust.
