MCP (Model Context Protocol) is an open standard that lets AI applications connect to external tools, data and workflows through one common interface. The official introduction defines it in one line: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems."
In practice, MCP is why you can add a GitHub, Sentry or database connection to Claude Code, Cursor, VS Code or ChatGPT without each app writing its own integration. Someone builds an MCP server for a system once, and every MCP-capable app can use it.
This guide explains where MCP came from, how its architecture works, what servers can expose, and what to watch for on security.
What problem does MCP solve?
Before MCP, every pairing of an AI app and an outside system needed custom glue code. Anthropic's launch post (25 November 2024) described the problem: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale."
MCP replaces that many-to-many mess with a single protocol. The official docs use a hardware analogy: "Think of MCP like a USB-C port for AI applications." A tool vendor writes one MCP server. An app vendor implements one MCP client. Any client can then talk to any server.
The examples on the intro page show the range: agents reading your Google Calendar and Notion, Claude Code building a web app from a Figma design, and enterprise chatbots querying several databases at once.
Who owns MCP?
Anthropic created MCP and released it as an open standard in November 2024. On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The announcement noted that "MCP has been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, and other popular AI products," and that there were "more than 10,000 active public MCP servers" at the time.
The specification, the official SDKs and the reference servers all live under the modelcontextprotocol organization on GitHub.
How does MCP work?
MCP uses a client-server design with three participants. The architecture overview defines them:
- MCP host: "The AI application that coordinates and manages one or multiple MCP clients." Claude Code, Claude Desktop, Cursor and VS Code are hosts.
- MCP client: "A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use." The host creates one client per server.
- MCP server: "A program that provides context to MCP clients."
So if VS Code connects to a Sentry server and a filesystem server, it runs two MCP clients, one for each.
The protocol has two layers:
| Layer | What it defines |
|---|---|
| Data layer | A JSON-RPC 2.0 message format: discovery, tools, resources, prompts, notifications |
| Transport layer | How messages travel: stdio for local servers, Streamable HTTP for remote ones |
Stdio runs the server as a local process and exchanges messages over standard input and output. Streamable HTTP uses HTTP POST, with optional Server-Sent Events for streaming, and supports bearer tokens, API keys and custom headers. The docs say "MCP recommends using OAuth to obtain authentication tokens" for remote servers.
Here is a simplified tool call from the architecture page, with the per-request _meta field left out:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "weather_current",
"arguments": { "location": "San Francisco", "units": "imperial" }
}
}
The server replies with a content array, usually text, which the host passes back to the model.
What changed in the 2026-07-28 revision?
The current specification, version 2026-07-28, made the protocol stateless. According to the architecture page, every request now carries the protocol version and the relevant capabilities in its _meta field, and servers advertise what they support through a mandatory server/discover request. Older servers used a connection-level initialize handshake instead. The official SDKs handle both: the TypeScript tutorial notes that its stdio helper "negotiates the protocol revision with each client."
What can an MCP server expose?
Servers offer three core building blocks. The server concepts page also says who controls each one:
| Primitive | What it is | Who controls it | Example |
|---|---|---|---|
| Tools | Functions the model can call to take actions or fetch data | Model | Search flights, create an issue, run a query |
| Resources | Read-only data for context, addressed by URI | Application | File contents, a database schema, API docs |
| Prompts | Reusable instruction templates with arguments | User | "Plan a vacation", "Summarize my meetings" |
Tools are the part most people mean when they talk about MCP. Each tool has a name, a description and a JSON Schema for its input. The client finds them with tools/list and runs one with tools/call. The docs note that "Tools may require user consent prior to execution," and most hosts show an approval prompt before a tool runs.
Prompts often appear as slash commands. Claude Code, for example, lists each MCP prompt as /servername:promptname (MCP) when you type /. See Claude Code MCP for how that looks.
Clients can expose features back to servers too. Elicitation lets a server ask the user for more information or a confirmation. Sampling (asking the host's model for a completion) and protocol-level logging are deprecated as of version 2026-07-28.
How is MCP related to tool calling?
MCP sits on top of tool calling; it does not replace it. A model provider's tool calling (also called function calling) is how a model asks your app to run a function. MCP standardizes where those functions come from.
The architecture page describes the flow: the host fetches tools from every connected server and combines them "into a unified tool registry that the language model can access." When the model decides to call one, "the AI application intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM." Our guide to tool calling covers the model side of that loop.
The docs are also clear about scope: MCP covers context exchange only and does not dictate how an application uses its model.
How do you use MCP servers?
Most developers meet MCP as users before they build anything. Each host has its own way to add a server:
- Claude Code:
claude mcp addwith a name and a URL or command. The Claude Code docs giveclaude mcp add --transport http notion https://mcp.notion.com/mcpas an example. See Claude Code MCP. - Cursor, Codex and Gemini CLI: each reads its own config file. See Cursor MCP, Codex MCP and Gemini CLI MCP.
- ChatGPT: OpenAI's MCP docs describe adding a remote server through ChatGPT Plugins with "Add custom MCP server," and warn: "We recommend that you do not connect to a custom MCP server unless you know and trust the underlying application."
For a shortlist of servers worth installing, see best MCP servers. To write your own, the MCP SDKs page lists official SDKs; TypeScript, Python, C#, Go, Rust and Ruby are Tier 1. Our step-by-step guide on how to build an MCP server walks through a tested example.
What are the security risks of MCP?
Connecting a server gives an AI app new powers, so treat it like installing software.
The official security best practices list the main risks. For local servers, the first is "Arbitrary code execution. Attackers can execute any command with MCP client privileges." A malicious startup command in a shared config, or a compromised package, runs as you. The guide says clients that offer one-click local installs "MUST implement proper consent mechanisms prior to executing commands."
For remote servers, the guide forbids token passthrough: "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." It also covers OAuth flaws such as confused deputy attacks and server-side request forgery.
Hosts add their own guardrails. The Claude Code MCP docs note that "Claude Code prompts for approval in interactive sessions before using project-scoped servers from .mcp.json files."
A third risk is prompt injection: a tool result, such as an issue body or a web page, can contain instructions aimed at the model. Our guide to prompt injection in coding agents covers defenses.
Practical rules: install servers from sources you trust, grant the narrowest scopes, prefer read-only access where it exists, and keep approval prompts on for tools that write or delete.
How does MCP compare with Agent Skills?
They solve different problems. MCP gives an agent access to a system. A skill is a folder of instructions, a SKILL.md plus optional scripts, that teaches the agent how to do a task. Many setups use both: an MCP server to reach GitHub, and a skill describing how your team triages issues. Skills vs MCP compares them in detail, and Agent Skills explains the format.
The prompts you use to drive MCP tools are worth keeping, too. Kipt stores prompts and Agent Skills as Markdown in a private GitHub repo you own, so a tested "triage these Sentry issues" prompt or a skill that calls your MCP tools is easy to find and reuse.
What should you read next?
Start with how to build an MCP server for a minimal working example in TypeScript or Python. Then read what is tool calling to see how the model decides when to call the tools your server exposes.