The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. Anthropic introduced it in November 2024, and it is now hosted by the Agentic AI Foundation under the Linux Foundation. An MCP server exposes tools, resources and prompts; any MCP client, such as Claude, ChatGPT, Cursor, VS Code or a coding agent, can use them without custom integration code. You write a connector once, and every compatible app can call it.
This explainer covers what MCP is, how its parts fit together, what changed in the current spec, where the security risks are and how to try a server in five minutes. Everything was checked against the official MCP documentation and the 2026-07-28 specification on October 24, 2026, and the first run below was done on our own machine that day.
What is MCP, in one paragraph?
Before MCP, every AI app needed its own plugin format, so a company that wanted its database or ticket system inside Claude, an IDE and an internal agent wrote three integrations. MCP replaces that with one protocol. The official docs compare it to a USB-C port for AI applications: a standard plug between the model side and the systems it needs. The name says what it carries. Model is the AI application, context is the data and actions you give it, and protocol is the agreed message format, which is JSON-RPC 2.0. When people ask for the "MCP server full form", the answer is Model Context Protocol server: a program that speaks this protocol and offers capabilities to AI apps.
The Model Context Protocol tool page on drydock tracks the project itself. This guide is the explainer.
Hosts, clients, servers and transports
MCP has three roles, per the architecture overview:
- Host: the AI application the user works in, such as Claude Code or Claude Desktop. It owns the model and decides what the model may do.
- Client: a connector inside the host. The host creates one MCP client for each server it connects to.
- Server: a program that offers tools, data or prompts. It can be a local process on your laptop or a remote service on the internet.
Messages travel over a transport. The spec defines two standard ones:
- stdio: the host starts the server as a child process and talks to it over standard input and output. This is how most local servers run, and a local stdio server usually serves a single client.
- Streamable HTTP: the server runs as a web service, and clients send each message as an HTTP POST. Remote and shared servers use this. The older HTTP plus SSE transport is formally deprecated.
The protocol semantics are the same on both transports, so a server can usually offer either one.
Tools, resources and prompts
A server can offer three kinds of things:
- Tools are functions the model can call: search tickets, run a query, open a browser page. Each tool has a name, a description and a JSON Schema for its inputs. Tools are the part most people mean when they say MCP.
- Resources are data the app can read: a file, a database row, a document, each identified by a URI. The host decides when to attach them to the conversation.
- Prompts are reusable templates a user can pick, such as "review this pull request", often with arguments.
Clients can offer features back to servers too. The main one in the current spec is elicitation, where a server asks the user for missing information mid task, such as a confirmation or a choice. Two older client features, Roots and Sampling, plus protocol level Logging, were deprecated in the 2026-07-28 revision. They still work during a deprecation window of at least twelve months, but new servers should not depend on them.
Testing the three primitives
We pointed the official Inspector at the reference "everything" server on October 24. It listed 17 tools, a set of static document resources with demo:// URIs and 4 prompts, and a call to its get-sum tool with 2 and 3 returned "The sum of 2 and 3 is 5." That is the whole loop: discover, then call.
What changed in the 2026-07-28 spec
The current revision, dated July 28, 2026, made MCP stateless, per the official changelog:
- No more initialize handshake or protocol sessions. Every request carries its own protocol version and client capabilities.
- A new
server/discovercall lets a client ask a server which versions and capabilities it supports. - Server to client requests were replaced by a multi round trip pattern: a server that needs more input returns an "input required" result, and the client retries with the answers.
- Long running tasks moved out of the core into an official Tasks extension, next to extensions such as MCP Apps (interactive UI inside a conversation).
For most server authors the practical effect is simpler hosting: any instance behind a load balancer can answer any request. Tutorials written before July 2026 often show the handshake and session headers, which is why some sample code breaks on new SDKs. Our MCP server in Python guide uses the current SDK.
Which apps support MCP
The official intro lists Claude and ChatGPT among AI assistants and VS Code, Cursor and MCPJam among developer tools, and the list keeps growing. In practice, MCP support is now standard in:
- Coding agents and IDEs: Claude Code, Cursor, GitHub Copilot in VS Code and the Copilot CLI, OpenAI Codex and Gemini CLI. Our GitHub Copilot MCP guide shows where each Copilot surface reads its config.
- Agent frameworks: the OpenAI Agents SDK, LangChain (through MCP adapters), Google ADK and the Vercel AI SDK can all load MCP tools.
- Products that ship their own servers: GitHub, Weaviate and Qdrant are examples, and Microsoft's Playwright MCP gives agents browser control. Microsoft also ships servers for Power BI; see our Power BI MCP server guide.
The official MCP Registry lists published servers with their package or remote URL, which is a better starting point than random lists.
How MCP compares with an API and with A2A
MCP does not replace your REST API. Most MCP servers are thin wrappers around an existing API that add discovery and model friendly descriptions. Our MCP server vs API guide covers when the wrapper is worth it. MCP also is not an agent to agent protocol: it connects an agent to tools, while A2A connects agents to other agents. See MCP vs A2A. And when an agent needs dozens of tools, Code Mode lets it call them from code instead of one by one.
Security risks to know
MCP makes it easy to give a model real power, so the risks are real too. The spec itself says tools represent arbitrary code execution and that tool descriptions and annotations should be treated as untrusted unless they come from a trusted server. The main risks, drawing on the official security best practices:
- Prompt injection through tools. A tool description, a web page or a file returned by a tool can contain instructions aimed at the model. Treat every tool result as untrusted input.
- Malicious or compromised local servers. A stdio server runs on your machine with your permissions. Install servers only from sources you trust, pin versions, and prefer sandboxes for anything that runs code.
- Token passthrough and confused deputy problems. A remote server must not accept tokens that were not issued for it, or forward a user's token to another service. If you run a server, follow the spec's authorization rules.
- Overly broad scopes. Give each server the smallest permissions it needs: one folder, a read only database user, a token without admin rights.
- Server side request forgery. A server that fetches URLs can be pointed at internal addresses unless you block them.
The host is your last line of defense. The spec says hosts must get the user's consent before invoking a tool, and coding agents implement that as approval prompts. Keep approval on for anything that writes, sends or spends, even when auto approval is offered.
How to try an MCP server in five minutes
You need Node.js. The current Inspector (2.12.0) requires Node.js 22.19 or newer; we used Node.js 24.
- List what a server offers, with no AI app involved:
npx -y @modelcontextprotocol/[email protected] --cli \
npx -y @modelcontextprotocol/[email protected] --method tools/list
- Call a tool the way a model would:
npx -y @modelcontextprotocol/[email protected] --cli \
npx -y @modelcontextprotocol/[email protected] \
--method tools/call --tool-name get-sum --tool-arg a=2 --tool-arg b=3
- Add a real server to your coding agent. In Claude Code, for example,
claude mcp add notes -- npx -y @modelcontextprotocol/server-filesystem /path/to/notesgives the agent read and write access to one folder only.
For every client's config format and the common errors, read how to run an MCP server locally. To write your own, go to how to build an MCP server in Python.
FAQ
Who created MCP?
Anthropic announced and open sourced the Model Context Protocol on November 25, 2024. In December 2025 it became a founding project of the Agentic AI Foundation, a Linux Foundation project whose founding contributors included Anthropic, Block and OpenAI.
Is MCP only for Claude?
No. ChatGPT, Cursor, VS Code with GitHub Copilot, Codex, Gemini CLI and many agent frameworks support it. A server written once works with any compliant client.
What is the difference between MCP and an API?
An API is the service itself. MCP is a standard way to describe and call capabilities so an AI app can discover them at run time. Most MCP servers wrap an existing API.
Are MCP servers safe?
Only as safe as their source and permissions. A local server runs with your user's rights, and any tool output can carry prompt injection. Use trusted servers, pin versions, limit scopes and keep tool approvals on for actions that change things.
How do I run an MCP server locally?
Most local servers start with one command such as npx or uvx, and your client launches them over stdio. Test with the MCP Inspector first, then add the server to your client's config. Our local setup guide has the exact steps for each client.
What does MCP stand for?
Model Context Protocol. An "MCP server" is a program that offers tools, resources or prompts over that protocol, and an "MCP client" is the connector inside an AI app that talks to it.



