What Is MCP (Model Context Protocol) and Why It Matters

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external tools and data. Anthropic introduced it in November 2024 and published it as an open specification with official SDKs. Since then it has been adopted across many AI clients and developer tools, and thousands of MCP servers have been published by companies and the open-source community.

A common analogy is “USB-C for AI applications”: one connector shape, many devices. It is a useful image, but the details matter, so this article explains what MCP actually specifies.

The problem MCP solves

Before MCP, connecting a model to your issue tracker, database, or file system meant writing a custom integration for each AI application. If you had M applications and N systems, you were looking at something close to M x N integrations, each with its own conventions for describing tools and passing results.

MCP turns that into M + N. Each AI application implements the client side of the protocol once. Each external system gets an MCP server once. Any compliant client can then use any compliant server.

Architecture: hosts, clients, and servers

MCP defines three roles:

• Host: the AI application the user interacts with, such as a desktop chat app, an IDE, or a command-line coding assistant. The host manages the model, the user interface, and security decisions.
• Client: a connector inside the host that maintains a one-to-one connection with a single server. A host that talks to five servers runs five client connections.
• Server: a program that exposes capabilities, such as tools or data, over the protocol. A server can run locally as a subprocess or remotely as a web service.

Messages are encoded as JSON-RPC 2.0. A connection starts with an initialization handshake where client and server exchange protocol versions and declare which capabilities they support. After that, either side can send requests and notifications according to what was negotiated.

What servers expose: tools, resources, prompts

MCP servers can offer three main kinds of capability:

Primitive	Controlled by	What it is	Example
Tools	The model	Functions the model can call, with a name, description, and JSON Schema for inputs	create_issue, run_query, search_files
Resources	The application	Data identified by URIs that the host can read and add to context	A file, a database schema, a log
Prompts	The user	Reusable prompt templates, often surfaced as slash commands	“Review this pull request”

Tools get most of the attention because they are what make agents act. A client lists available tools with tools/list and calls one with tools/call. A simplified call looks like this:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": { "query": "login timeout", "state": "open" }
  }
}

The server responds with content, typically text and sometimes images or structured data, that the host passes back to the model.

What clients can offer servers

The protocol is not one-directional. Clients can also expose capabilities to servers, including:

• Sampling: a server asks the host’s model to generate a completion, so the server can use language-model reasoning without holding its own API key. The host stays in control and can require user approval.
• Roots: the client tells the server which directories or URIs it is allowed to operate within.
• Elicitation: a server asks the user, through the host, for additional information in the middle of a task.

Support for these varies by client, which is one reason compatibility notes matter when choosing servers.

Transports: local and remote

The specification defines two standard transports:

• stdio: the host launches the server as a local subprocess and exchanges messages over standard input and output. This is the most common setup for developer tools and anything that touches your local files.
• Streamable HTTP: the server runs as an independent HTTP service. Clients send messages with HTTP POST, and the server can stream responses using Server-Sent Events. This replaced the earlier “HTTP with SSE” transport in the March 2025 specification revision, though some servers and clients still support the older style for compatibility.

For remote servers, the specification includes an authorization framework based on OAuth 2.1, so a user can grant a client scoped access to a hosted service rather than pasting a long-lived API key into a config file.

Why MCP matters

Portability. You can switch AI clients without rebuilding your integrations. A team using one assistant in the IDE and another in a desktop app can point both at the same servers.

An ecosystem effect. Because a server works with many clients, it is worth building good ones. Many SaaS vendors now publish official MCP servers for their products, alongside community servers for almost every popular tool.

Separation of concerns. The server author knows the API; the host author knows the user interface and safety model. MCP lets each focus on their part.

Better agents. An AI agent is limited by the tools it can reach. MCP makes the toolbox bigger and more consistent.

What MCP does not solve

It is important to be clear about limits:

• Trust. MCP standardizes the connection, not the quality or safety of a server. A malicious or careless server can expose data or mislead the model.
• Prompt injection. Tool results are text that flows into the model’s context. If a tool returns content from an untrusted source, such as a web page or an email, that content can contain instructions aimed at the model. The protocol cannot stop this on its own; hosts and users need guardrails. Our agent security checklist covers practical defenses.
• Permissions design. The protocol gives hosts the hooks to ask for approval, but how strictly a host enforces approvals is a product decision.
• Discovery and curation. There is no single authoritative answer to “which server should I use for X?” Official registries and community lists exist, but quality and maintenance vary.

MCP vs function calling vs plugins

Model providers’ function calling (or tool use) APIs let you describe tools to a model inside a single application. MCP sits one layer above: it defines how those tool descriptions and calls travel between an application and separate server processes. Most hosts translate MCP tools into the function-calling format of whatever model they use.

Earlier plugin systems were tied to one product. MCP is a protocol that any product can implement.

Getting started

If you use an AI coding assistant or desktop app, there is a good chance it already supports MCP. Our step-by-step guide on how to install and use an MCP server walks through the process with notes on how configuration differs between clients.

And if you are trying to work out which servers are worth installing, that is exactly what AgentZone is for: a curated directory organized by category, with setup notes and client compatibility. It is launching soon.