MCP Overview
What MCP standardises and what it does not: why a fixed plug turns apps x tools into apps + tools, how it sits beside function calling, REST, CLI plus Skills, A2A and RAG, when not to use it, the five dated revisions up to the stateless 2026-07-28 spec, and what it deprecated.
Last updated
After this section you can
- Explain what MCP standardizes and why one shared plug turns apps × systems into apps + systems
- Choose between MCP, plain functions, REST, CLI plus Skills and A2A, and say when a separate MCP server is not worth it
- Name the current revision, 2026-07-28, and tell opt-in extensions from deprecated features
MCP Overview: One Plug, Many Tools
What MCP standardizes, how it sits beside function calling, REST, CLI plus Skills and A2A, when a separate server is not worth it, and what changed in 2026-07-28.
MCP (the Model Context Protocol) is an open protocol that connects an AI application to tools and data through one standard interface, like a USB-C port for AI applications. The application, called the host, holds the model and runs one client per server. The model never speaks MCP: a client does, run by your app or, with the Messages API connector, by Anthropic’s API. This course teaches revision 2026-07-28.
Adapter: code that makes one app work with one system; you build and maintain it. Each host still opens one client per server (MCP Architecture).
Why a shared plug: N × M becomes N + M
Take 4 AI apps that should reach 47 systems (illustrative numbers). Without a standard, each app needs its own adapter to each system. With MCP, each app adds a client once and each system adds a server once.
“N × M” is community shorthand, not a spec term, and N counts apps (hosts such as Claude, ChatGPT, VS Code or Cursor), not models. With one app and servers you write, the saving is gone; MCP buys one place for auth, policy and audit, reuse by other apps, and tools that survive a model swap. The spec credits the Language Server Protocol, which did this for programming-language support in editors.
Where MCP sits among its neighbors
Six options sit beside MCP. They join different pairs, so most stack.
| Option | Joins · pick when |
|---|---|
| Function calling format set by each model API | model ↔ your app Always: it is how a model asks for any tool |
| Plain functions your own code (Inside a Tool Call) | your app ↔ its own functions One app, a few tools, nothing to guard |
| REST / OpenAPI HTTP; described by OpenAPI | any program ↔ an HTTP service The caller is a program; MCP can wrap it for AI apps |
| CLI plus Skills a shell plus Skills: folders of instructions (SKILL.md) the agent reads | an agent ↔ commands in its shell The tool is already a command and the agent has a shell |
| MCP open spec, Linux Foundation | an AI app ↔ a tool server, vertical A second app, a host you do not control, a secret, a policy or a model swap |
| A2A Agent2Agent, Linux Foundation | one agent ↔ another agent, horizontal The other agent belongs to someone else |
| RAG a pattern, not a standard | a model ↔ your documents The knowledge outgrows the prompt |
Function calling and MCP are two hops of one call: the model asks for a tool, then your app runs it, directly or through a server. The Agent SDK’s Custom Tools use MCP too, as a server inside your own process (Custom Tools). A retriever can sit behind a tool (How LLMs Actually Call Tools weighs tools against retrieval; Building MCP Servers builds one).
When a separate MCP server is not worth it
Four axes decide it, the same four as in MCP servers vs direct tool implementations.
- Reuse: only this app.
- Secret: the key sits in your process.
- Policy: nothing to enforce.
- Model swap: re-wire a few functions.
- Reuse: a second app or team, a host you do not control, or a vendor’s server.
- Secret: the key stays in the server; no app holds it.
- Policy: rate limits, tenant scoping and audit in one place.
- Model swap: the server stays as is; it never knows which model calls.
Rule of thumb: for one app and servers you write, a separate server pays off when a second app, a secret, a policy or a model swap shows up. A host you do not control, or a vendor’s ready-made server, makes it the way in.
The price of a separate server: a process or network hop on every call, a service to run and secure, and, by default, the server’s whole tool menu in the model’s context on every request (sizes: Tool Surface Design). Levers: tool search and allowlists (MCP with Claude), a smaller menu (MCP Discovery), one front door (Many Servers). Skills, subagents or servers? A decision tree.
One spec, five revisions, one foundation
A revision’s date is the last day a breaking change landed, not its release date: the first revision (2024-11-05) is older than the launch (2024-11-25).
- 2024-11-05the first spec: tools, resources and prompts over stdio (local) or HTTP+SSE (remote), with an initialize handshake (a setup exchange before any tool call)
- 2025-03-26authorization based on the OAuth 2.1 draft; Streamable HTTP replaces HTTP+SSE
- 2025-06-18structured tool results; servers as OAuth resource servers; elicitation (a server asks the user)
- 2025-11-25Client ID Metadata Documents (simpler client registration); experimental Tasks
- 2026-07-28stateless: no handshake, no sessions (every request carries its own version and capabilities); opt-in extensions; a deprecation policy
Anthropic open-sourced MCP on 2024-11-25 and donated it on 2025-12-09 to the Agentic AI Foundation, a Linux Foundation fund. Anthropic’s donation post counted 10,000+ active public servers and 97M+ monthly Python and TypeScript SDK downloads; the 2026-07-28 release post says close to half a billion a month across the Tier 1 SDKs (the project’s top support level). Scopes differ, so do not compute a growth rate.
Two eras are live at once: peers on the handshake revisions (up to 2025-11-25) and on 2026-07-28. An SDK speaks one era or both, so check before pairing a client with a server (MCP Transport shows the probe).
What to build on, what to avoid
Opt-in extensions. Each stays off until client and server both declare it under extensions; official ids start with io.modelcontextprotocol/.
| Extension | What it adds |
|---|---|
Taskstasks | polling for long-running work see State Without Sessions |
MCP Appsui | interactive UI inline in the chat see State Without Sessions |
Skills over MCPskills | skills discovered and read through a server not covered in this course |
Enterprise-Managed Authorizationenterprise-managed-authorization | company-wide access control through the enterprise identity provider see Many Servers |
OAuth client credentialsoauth-client-credentials | machine-to-machine login, no user see Many Servers |
Deprecated. Roots, Sampling, Logging and Dynamic Client Registration were deprecated in 2026-07-28; the earliest removal is the first revision released on or after 2027-07-28 (a 12-month floor, 90 days for an active security risk). HTTP+SSE has a shorter clock and can be removed from the next revision: migrate now. They all keep working; new code should not adopt them.
| Feature | Use instead |
|---|---|
| Roots tells a server which folders to use | tool arguments, resource URIs or server config see MCP Architecture |
| Sampling a server asks the host’s model for help; its includeContext values, deprecated since 2025-11-25, go with it | the server calls a model provider’s API itself; omit includeContext or use nonesee MCP Architecture |
| Logging a server sends log messages to the client | stderr on stdio, OpenTelemetry elsewhere see MCP in Production |
| Dynamic Client Registration (DCR) a client registers itself on the fly | Client ID Metadata Documents see MCP Authorization |
| HTTP+SSE transport the original remote transport, deprecated since 2025-03-26 | Streamable HTTP see MCP Transport |
- “The model speaks MCP.” Your app does (Inside a Tool Call).
- “MCP replaces function calling.” They stack (step 2).
- “Sessions and an initialize call come first.” Not in 2026-07-28 (MCP Architecture, MCP Transport).
- “A third-party server is trusted.” Its descriptions and results are input you did not write (MCP Security).
- “The Messages API connector does resources and prompts.” Tool calls only (MCP with Claude).
“MCP versus function calling, REST and CLI plus Skills: when would you not use it?” Say: MCP is one plug between AI apps and tools; function calling is how the model asks, MCP is how your app runs the tool, so they stack. Against REST it adds one method set for every server, a tool list written for a model, and an optional, HTTP-only way to authorize a stranger. Skip a separate server for one app you build with a few tools, no secret and no policy, or when the agent has a shell and the tool is a command. The trap: “MCP replaces function calling”, “MCP is just REST”.
A teammate wants a new server to borrow the host’s model through Sampling, so it needs no API key. What do you tell them?
Sampling is deprecated (2026-07-28). It works, but removal is possible from the first revision released on or after 2027-07-28 (sooner only for an active security risk); new code should not adopt it. The server calls a model provider’s API itself and holds its own key.
Three internal tools, one app, no credentials, nothing to enforce: behind a separate MCP server?
No: a process hop and a service to run buy nothing. A second app, a host you do not control, a secret, a policy or a model swap would change that.
A post says every client must send initialize first. Which revisions is that true of, and what is the rule now?
The handshake revisions, 2024-11-05 to 2025-11-25. A session ID existed only if an HTTP server chose to issue one. In 2026-07-28 each request carries its own protocol version and capabilities, so there is no initialize and no Mcp-Session-Id.
- One plug turns 12 adapters into 7 for 3 apps and 4 systems, and 188 into 51 for 4 and 47; one app with servers you write saves nothing.
- MCP sits beside function calling: the model asks, your app runs the tool.
- A separate server pays off on a second app, a secret, a policy or a model swap, or when the host is not yours or a vendor already ships the server.
- 2026-07-28 is current (stateless, opt-in extensions); deprecated features keep working but are not for new code.