What Is MCP? The Model Context Protocol Explained

MCP (Model Context Protocol) is an open standard that connects AI applications to external systems: files, databases, tools and ready-made workflows. Anthropic introduced it in November 2024. Instead of building a separate interface for every pairing of AI application and tool, both sides speak the same language.

The project documentation itself compares MCP to a USB-C port: one plug that fits many devices. An example: you connect an AI agent to your code through a GitHub server. When you ask “Which pull requests are open?”, it can look for itself instead of guessing. Our MCP server directory shows which servers exist.

1. Why MCP exists

A language model produces text. It only reaches your files, your ticket system or your calendar if the program around it builds that access. In the past, every application needed its own connection for every tool. Anthropic described it this way at launch: every new data source requires its own custom integration.

MCP starts right there. Whoever wants to offer a tool builds a server. Whoever builds an AI application builds a client. Both sides understand each other without knowing each other. At the start, Block and Apollo supported the standard, and Zed, Replit, Codeium and Sourcegraph were working with it. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, which sits under the Linux Foundation. Anthropic lists ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code there among the products that support MCP.

2. How MCP works

2.1 Host, client and server

MCP has three roles:

• Host: the AI application you work with, such as a chatbot or a coding agent.
• Client: a component inside the host that holds the connection to exactly one server. Connect three servers and you get three clients.
• Server: the program that provides capabilities.

The documentation gives an example: Visual Studio Code is the host. When it connects to the Sentry server, it creates a client for it. Add the filesystem server and a second client appears.

2.2 The three server primitives

A server can offer three kinds of capabilities:

• Tools: functions the model can call, such as “create ticket” or “query database”.
• Resources: data that serves as context, such as file contents or a database schema.
• Prompts: reusable templates that structure a conversation.

Tools get most of the attention. Each tool comes with a name, a description and an input format. The model reads exactly this description to decide whether and how to use the tool. That becomes important in section 5.

2.3 Messages and transports

Messages follow JSON-RPC 2.0. It is a plain format in which one side calls a method with parameters and the other answers with a result. There are two ways to transport them:

• stdio: the host starts the server as a program on the same machine and talks to it through standard input and output. It is fast and needs no network.
• Streamable HTTP: the server runs on the network, messages go out by HTTP POST and optionally come back as a stream. One server can serve many clients and protect itself with tokens or OAuth.

The specification uses a date as its version, and the current revision is from 28 July 2026. Every request names the version it speaks. A server that does not know it answers with an error that lists the versions it supports.

3. Example: connecting a ticket system

An invented example: you want your agent to be able to look up support tickets. For that there is a (made-up) MCP server called “tickets”. At startup the client asks it for its tools with tools/list. One entry looks like this:

{
  "name": "search_tickets",
  "title": "Search tickets",
  "description": "Searches support tickets by status and customer.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "status": { "type": "string", "enum": ["open", "closed"] },
      "customer": { "type": "string" }
    },
    "required": ["status"]
  }
}

The agent lists the server in its configuration. In Claude Code, that is a file called .mcp.json in the project folder. The first entry is a local stdio server, the second one runs on the network:

{
  "mcpServers": {
    "tickets": {
      "command": "npx",
      "args": ["-y", "tickets-mcp-server"],
      "env": {
        "TICKETS_API_TOKEN": "${TICKETS_API_TOKEN}"
      }
    },
    "wiki": {
      "type": "http",
      "url": "https://mcp.example.com/wiki"
    }
  }
}

The access key is not in the file but in an environment variable. That keeps it out of the repository.

Now you ask “Which open tickets does Müller GmbH have?”, and this happens:

1. The model sees the tool description and decides to call search_tickets.
2. The host intercepts this request. The model executes nothing itself. Depending on your settings, the host asks for your permission first.
3. The client sends the call to the server:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_tickets",
    "arguments": { "status": "open", "customer": "Müller GmbH" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "my-agent", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

4. The server queries its ticket system and answers:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "2 open tickets for Müller GmbH: #4812 invoice missing, #4830 password reset"
      }
    ]
  }
}

5. The host puts the result into the conversation. The model writes its answer to you from it.

You will find more servers and practical guides in the MCP server directory. How Claude Code connects servers is covered in the Claude Code guide.

4. Worked example: the integration problem

A short calculation shows why the standard pays off. Our harness directory lists 35 coding agents that are currently available. Add 20 tools a team wants to connect, such as GitHub, Slack, a database or a ticket system. The tool list is made up.

Without a standard

Connections

700

Calculation

35 agents × 20 tools

With MCP

Connections

55

Calculation

35 clients + 20 servers

Approach	Connections	Calculation
Without a standard	700	35 agents × 20 tools
With MCP	55	35 clients + 20 servers

Own calculation+ 1 more

PNG|SVG

CC BY 4.0

gradually.ai

Without a shared standard, every agent would have to connect every tool individually. With MCP, every agent brings one client and every tool gets one server. The number grows with the sum instead of the product. In practice not every agent connects every tool, so the calculation shows the principle.

5. Limits, risks and misconceptions

MCP makes connecting easy. That is also the risk, because every connected server widens what your agent can do and what can be slipped to it.

• Hidden instructions in tool descriptions. The model reads the description of every tool, and you usually do not see it. Invariant Labs showed in 2025 that a malicious server can hide instructions there that the model follows (tool poisoning). It is a form of prompt injection. A tool’s results also land in the context and can contain instructions.
• Excessive permissions. A local server runs with the same permissions as the application that starts it. The MCP documentation warns about servers from unclear sources and recommends keeping every permission as narrow as possible.
• Context consumption. Most clients load all tool definitions into the context window up front. With many servers, a lot of tokens are gone before your first question. Anthropic gives an example in which usage dropped from 150,000 to 2,000 tokens by loading only the tools needed at that moment.
• MCP is not a safety model for the model. The standard governs the exchange of context, not what the AI application does with it. Whether a call needs confirmation is up to the host.
• MCP does not replace APIs. It sits in front of them. The server translates between MCP and the service’s API.
• “Server” does not mean “on the internet”. Many servers run as a small program on your own computer.

6. What does this mean for you?

• Only connect servers whose origin you know. Check the provider and the source code before you start a server that runs on your machine.
• Grant as few permissions as possible. A server that should read tickets does not need write access. Use narrowly scoped access keys.
• Have actions with consequences confirmed. Your host should never delete, send or pay without your approval.
• Stick to a few servers. Every extra one costs context and widens the attack surface. Switch off the ones you do not use.
• Start small. A single server for what you need every day is a good start. What this looks like with agents in everyday life is covered in Personal AI agents, and project-wide instructions for agents in AGENTS.md.