What Is MCP? The Model Context Protocol Explained

Language models are only as useful as the information and tools they can reach. Out of the box, a model cannot read your calendar, query your database or create an issue in your project tracker. The Model Context Protocol (MCP) is the open standard that has become the common way to give AI applications that access.

The problem MCP solves

Before MCP, every AI application had to build its own integration with every service: one connector for Slack in app A, a different one in app B, and so on. With many apps and many services, that is a lot of duplicated, inconsistent work.

MCP defines one shared language. A service implements an MCP server once, and any MCP-compatible application can use it. The official docs compare it to a USB-C port for AI applications: one standard plug instead of a drawer of different cables.

A short history

Anthropic released MCP as an open-source protocol in November 2024. It was adopted quickly by other AI companies and developer tools. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI, so the protocol now has neutral governance. Its maintainers continue to decide its technical direction with community input.

How it works: hosts, clients and servers

MCP has three participants:

• Host: the AI application you use — for example Claude, ChatGPT, Visual Studio Code or Cursor.
• Client: a component inside the host that keeps a connection to one server. A host creates one client per server it connects to.
• Server: a program that provides context and capabilities — a GitHub server, a filesystem server, a database server.

Servers can be local, running on your computer and talking to the host through standard input and output (stdio), or remote, running on the internet and reached over Streamable HTTP, usually with OAuth sign-in.

What a server can offer

Servers expose three core building blocks, called primitives:

• Tools: actions the model can call, such as “create issue”, “search files” or “run query”. Each tool has a name, a description and a schema for its inputs.
• Resources: data the application can read for context, such as a file’s contents or a database schema.
• Prompts: reusable templates for common interactions.

Servers can also ask the user for input when needed — for example to confirm an action — through a feature called elicitation.

When you chat, the host collects the tools from all connected servers and makes them available to the model. When the model decides a tool would help, it requests it; the host calls the server and returns the result, and the conversation continues. Underneath, messages use the JSON-RPC 2.0 format.

What changed in the 2026-07-28 specification

MCP evolves through dated specification versions. The 2026-07-28 revision, the current one when this guide was written, made notable changes:

• Stateless by design. The old initialisation handshake and protocol sessions were removed. Every request now carries its protocol version and capabilities, and servers advertise what they support through a new server/discover request. This makes remote servers easier to scale.
• Multi round-trip requests. When a server needs more information to finish a request (such as user input), it returns an “input required” result and the client retries with the answer.
• Subscriptions. Change notifications, such as “the tool list changed”, now flow through a single opt-in stream.
• Deprecations. Roots, Sampling (servers asking the client’s model for completions) and Logging are deprecated, with a minimum twelve-month window before removal.
• Extensions. Optional features live outside the core, such as Tasks for long-running jobs and MCP Apps for interactive interfaces rendered inside a conversation.

You do not need to know these details to use connectors, but they explain why some servers and clients behave differently depending on the versions they support.

MCP, function calling and skills

These three ideas are related and often confused:

• Function calling is the model capability: the model can request that a tool be run.
• MCP is the standard way to package and share tools and data so many apps can use them.
• Skills are packaged instructions that teach an assistant how to do a task in a particular way. Connectors give access to apps and data; skills teach the method. They are often used together.

Security: what to watch out for

An MCP server acts with the permissions you give it, so treat installing one like installing software:

• Use servers from trusted publishers: official ones from the service provider, or well-maintained open-source projects.
• Grant the least access needed, such as read-only tokens where possible.
• Be careful with servers that fetch outside content (web pages, emails, issues): that content can carry prompt injection attempts.
• Keep approval prompts on for actions that write, send or delete.
• Review the connectors you have enabled from time to time and remove those you no longer use.

Ready to try it? Follow our step-by-step guide to installing an MCP server.