What is Model Context Protocol?

How it works

MCP uses a client-server design. The host is the AI application (Claude Desktop, Claude Code, VS Code, Cursor, ChatGPT and others). For each MCP server it connects to, the host creates an MCP client that keeps a dedicated connection to that server.

Messages are JSON-RPC 2.0. A server can expose three core primitives:

• Tools: functions the model can call, such as "query the database" or "create a ticket".
• Resources: data the application can read, such as file contents or a database schema.
• Prompts: reusable templates, such as a few-shot prompt for using the server's tools.

The client lists what a server offers (tools/list), and when the model decides to use a tool, the host sends tools/call and feeds the result back into the conversation. Two transports are defined: stdio for local servers running on the same machine, and Streamable HTTP for remote servers, where OAuth is recommended for authentication. The specification is versioned by date; the current version is 2026-07-28.

Why it matters

Before MCP, every AI app needed its own integration for every tool, which the official docs compare to the problem USB-C solved for devices. With MCP, a team writes one server for its CRM or internal API and every compatible assistant and agent can use it. That makes MCP the most common way to give an AI agent access to real systems.

The trade-off is security. An MCP server can read data and take actions, so you need to trust the server's code, scope its credentials narrowly, and treat text it returns as untrusted input (prompt injection is a real risk).

Example

A developer adds the official filesystem server to Claude Desktop. The server runs locally over stdio and exposes tools such as reading and writing files inside one allowed folder. When the user asks "summarise the notes in my project folder", the model calls the server's tools, receives the file text and writes the summary, without the developer writing any custom integration code.