What Is MCP? The Model Context Protocol, Explained Simply

MCP in one paragraph

A language model on its own can only produce text from what it learned in training and what is in the current prompt. To check today's calendar, query your company database or open a file, it needs a way to reach outside. Before MCP, every AI app built those bridges itself: one plugin format for ChatGPT, another for each IDE assistant, another for each agent framework. The Model Context Protocol replaces that with a single specification. A tool author writes one MCP server; any MCP-compatible application can use it. The usual analogy is USB-C: one connector, many devices.

The specification is public at modelcontextprotocol.io, and the original announcement is on Anthropic's site. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation, hosted by the Linux Foundation, so it is no longer controlled by a single vendor.

How MCP works: host, client, server

Piece	What it is	Examples
Host	The AI application the user actually talks to	Claude Desktop, an IDE assistant, Open WebUI, LM Studio
Client	The connector inside the host; one client per server connection	Built into the host, invisible to the user
Server	A program that exposes capabilities in MCP format	Filesystem, GitHub, Postgres, a web-search wrapper, your own internal API

Messages between client and server are JSON-RPC 2.0. When the host starts, each client asks its server what it offers. The server answers with a list of capabilities, each with a name, a plain-language description and a JSON schema for its inputs. The host hands those descriptions to the model. When the model decides a tool would help, it emits a structured call; the client forwards it to the server, the server runs it, and the result goes back into the conversation.

The key point: the model never executes anything. It only writes a request. The host decides whether to run it, usually after asking the user.

What an MCP server can offer

Primitive	Controlled by	Purpose	Example
Tools	The model	Actions with side effects or live lookups	create_issue, run_query, search_web
Resources	The application	Read-only data to load into context	A file, a database schema, a wiki page
Prompts	The user	Reusable prompt templates	"Review this pull request" with arguments

In practice, tools are what most servers ship and what most people mean by "MCP." The protocol also defines features in the other direction, such as sampling, where a server asks the host's model to generate text, and elicitation, where it asks the user for missing input.

Local or remote: the two transports

• stdio: the host launches the server as a local subprocess and talks to it over standard input and output. Nothing touches the network. This is how most desktop setups work, and it is the natural fit for a private, local stack.
• Streamable HTTP: the server runs as a web service, possibly on another machine, with standard authentication. This replaced the earlier HTTP+SSE transport in the 2025 revisions of the spec.

MCP vs function calling vs a plain API

These three get confused constantly, because they stack on top of each other.

	What it is	Who defines it
REST API	How a service exposes its functions to programs	Each service, differently
Function calling	A model's trained ability to output a structured call instead of prose	Each model vendor, similar but not identical formats
MCP	A standard way to discover, describe and invoke tools across apps	One open specification

MCP does not replace function calling; it depends on it. The model still needs to be good at emitting tool calls. MCP standardizes everything around that moment: how tools are listed, described, authorized and executed. An MCP server is very often a thin wrapper around an existing REST API.

MCP with a local model: what it really costs

MCP is model-agnostic. With a host that supports it and a local model trained for tool use, the whole loop runs on your machine. Two constraints matter far more locally than in the cloud.

1. Tool descriptions eat context, and context eats VRAM

Every connected tool injects its name, description and JSON schema into the prompt, on every turn. A typical tool definition runs 100 to 300 tokens; popular servers expose 10 to 30 tools. Connect a handful of servers and you have spent thousands of tokens before the user types anything. On a cloud model that is a line on the bill. On your GPU it is KV-cache memory taken from a fixed VRAM budget.

Setup	Tool-definition tokens (est.)	KV cache on Qwen 3 8B	KV cache on Qwen 3 32B
1 server, 8 tools	≈ 1,600	≈ 0.2 GB	≈ 0.4 GB
3 servers, 30 tools	≈ 6,000	≈ 0.9 GB	≈ 1.6 GB
6 servers, 80 tools	≈ 16,000	≈ 2.4 GB	≈ 4.2 GB

Estimates. Token counts assume 200 tokens per tool. KV cache computed from the published architectures at FP16: Qwen 3 8B has 36 layers and 8 KV heads of dimension 128, i.e. 0.15 MB per token; Qwen 3 32B has 64 layers with the same head layout, i.e. 0.26 MB per token. The derivation is in what is a token in AI.

On a 16 GB card running a 13 GB model, 2.4 GB of tool descriptions is the difference between working and out-of-memory. The practical rule for local setups: connect only the servers the current task needs, and prefer servers with a few well-described tools over ones that expose their whole API. Context costs in general are covered in context window vs VRAM cost.

2. Small models choose tools less reliably

Picking the right tool out of thirty and filling its schema correctly is a skill that scales with model size and training. Models under roughly 8B parameters often call the wrong tool or invent arguments. For which local models handle this well and on what hardware, see our ranking of the best local LLMs for agents and tool use. For the actual wiring, follow Ollama + MCP or Claude Desktop with a local LLM via MCP.

Security: the part most tutorials skip

An MCP server is code running with your permissions, fed by text a model produced. Three risks are worth understanding before installing anything:

• Prompt injection. If a tool returns content from the outside world (a web page, an email, an issue comment), that content can contain instructions aimed at the model. A model that can both read untrusted text and take actions is a target.
• Tool poisoning. A malicious server can hide instructions inside its own tool descriptions, which the model reads and the user usually never sees.
• Over-broad permissions. A filesystem server pointed at your home directory gives the model your home directory.

The defenses are unglamorous: install servers from sources you trust (the reference implementations live at github.com/modelcontextprotocol/servers), scope each one as narrowly as possible, keep the confirmation prompt enabled for anything that writes or sends, and avoid combining private data access with untrusted input in the same session.

Do you need MCP?

Your situation	Verdict
You chat with a model and paste in what it needs	No. MCP adds moving parts you will not use.
You want your assistant to read local files, query a database or search the web	Yes. This is the standard way to do it in 2026.
You build an internal tool and want it usable from any AI app	Yes. Write one MCP server instead of one integration per app.
You run a small local model on 8 GB of VRAM	Carefully. One or two lean servers at most.

For a working example, the BestLLMfor catalog is itself available through an open-source MCP server and a public API (CC BY 4.0): an assistant connected to it can answer "what fits on a 16 GB card" from live data rather than from memory.