Skip to content
learning
Menu

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to tools and data through a common client and server interface.

Last updated , 9 min read

Learning objectives

After reading this article you will be able to:

  • Define MCP and its client-server model
  • Explain how coding agents use MCP servers
  • Identify how test results can reach an agent through MCP
On this page

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard that defines how AI applications call tools and read data from programs called MCP servers. A coding agent can use one server to query a database and another to drive a browser. A team writes a server once, and AI applications that support MCP can use it.

Anthropic created MCP and published it as an open standard in a November 2024 announcement. Anthropic later donated the project to the Agentic AI Foundation, a directed fund under the Linux Foundation. The official documentation calls MCP "an open-source standard for connecting AI applications to external systems."

Before MCP, developers often wrote a custom connector between each AI agent and each tool's API. MCP does not replace those APIs. An MCP server often wraps one and describes its actions as tools that any MCP client can call.

How does MCP work?

MCP connects three roles:

  • Host. The host is the AI application that calls the model and manages the MCP clients. In a coding agent, it is the agent harness, the program around the model that runs its loop and tools.
  • Client. The host creates one MCP client for each server, and each client talks only to that server.
  • Server. An MCP server is a program that exposes tools or data to AI agents over MCP, so any client can call them in the same way. A local server usually talks over standard input and output (stdio), and a remote server talks over Streamable HTTP.

Both transports carry JSON-RPC messages. A server can offer tools for the model to call, resources for the host to read, and prompts, which are templates a person picks.

Tools build on tool calling, which lets a large language model (LLM) request a named function with arguments. MCP tells the host which tools a server offers and carries each call to that server. Using a tool takes six steps:

  1. The client asks the server for its tools with a tools/list request.
  2. The server returns a definition of each tool, including a description and an argument schema.
  3. The host offers these tools to the model.
  4. The model generates a tool call with a tool name and arguments.
  5. The client sends a tools/call request to the server that owns the tool.
  6. The server runs the tool, and the host adds the result to the model's context.
MCP host, clients, and servers Host (coding agent) Model MCP client A MCP client B Local MCP server e.g. for a database Remote MCP server e.g. for an issue tracker stdio Streamable HTTP Both carry JSON-RPC 2.0 messages
Each server gets its own client inside the host. The transport differs, but the messages are the same.

What is an example of an MCP server?

Here is an illustrative example. Acme Co. sells furniture online. A developer at Acme asked a coding agent to "Let customers edit their delivery address during checkout." On staging, test order A-1042 lost its items after an address change. The developer asks the agent to find the cause.

Acme has a small MCP server, acme-orders, that reads orders from the staging database. The developer registers it with the coding agent, e.g. Claude Code:

claude mcp add acme-orders -- node orders-server.js

The host starts the server as a local process over stdio. Its client sends tools/list, and the server returns one tool definition:

{
  "name": "get_order",
  "description": "Read one order from the Acme staging database. Read-only.",
  "inputSchema": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  }
}

The model generates a call to get_order. The client sends this request, shown without its JSON-RPC version, ID, and metadata:

{
  "method": "tools/call",
  "params": {
    "name": "get_order",
    "arguments": { "order_id": "A-1042" }
  }
}

The server returns the text A-1042: address 12 Elm Street, 0 items. The address saved, but the cart emptied. Without the server, the developer would have pasted this record into the chat.

The agent then reads the checkout code that handles the address change. That code rebuilds the order without its items. This example is simplified. A real server would also limit which orders each caller can read.

How do coding agents use MCP?

Coding agents act as MCP hosts. A person lists servers in a config file for their user account or for one project, e.g. .mcp.json at the root of a repository. When a session starts, the agent adds each server's tools to its built-in tools for files and the shell.

Common servers in coding work include:

  • Browser control. A server, e.g. Playwright MCP, can expose browser actions as tools and return an accessibility snapshot of the page.
  • Code hosts and issue trackers. A server can read an issue or open a pull request.
  • Databases. A server can run read-only queries against a development database, as in the Acme example.

Each server's tool definitions use part of the model's context, so some agents load them only when a task needs them. The specification also says that a person should be able to deny a tool call, and coding agents usually do this with approval prompts.

How can test results reach an agent through MCP?

An MCP server can wrap a test runner or a browser tool. After an edit, the model calls a tool, e.g. run_tests, and a failure in the result can lead to the next edit.

A test result helps the agent most when it contains three things:

  • The failing check. The result names the failing test and gives the expected and the actual value.
  • A way to reproduce it. The result gives the exact command or the reproduction steps, so the agent can rerun the failure after its fix.
  • Short evidence. The result adds the exit code and a log excerpt, or a page snapshot from a headless browser. A full log can crowd out the code the agent needs to read.

An MCP tool can return each part as a named field of structured content.

An agent can also run tests with its own shell tool. An MCP tool fits a check that needs state the shell does not keep, e.g. a browser session that stays open between calls. Agent hooks run a check at fixed points in the loop, e.g. when the agent tries to stop. A hook runs whether or not the model asks for it, and an MCP tool usually runs only when the model calls it.

A result that reaches the agent is still only data in its context. The agent's final message can say the task is "done" while the result shows a failure. A person, or a check that the agent did not write, should confirm the fix.

What are the security risks of MCP servers?

An MCP server widens what an agent can reach, and anyone who controls text the agent reads can try to use that reach. The main risks are these:

  • Code on the machine. A local server runs with the user's permissions. Installing servers from known sources and pinning their versions limits this risk.
  • Injected instructions. Tool descriptions and results are text the model reads, so they can carry prompt injection. Hiding instructions for the model in a tool description is called tool poisoning.
  • Broad credentials. The agent gets whatever a server's token allows. Least privilege limits each token to what the task needs, e.g. read access to one repository.
  • Repository config. A cloned repository can bring an MCP config file that adds servers. Its instruction files can carry a rules file backdoor. Reading both files before the first session limits this risk.
  • Combined reach. A server that reads untrusted text and another that can send data out give an injected instruction a path to leak secrets. A sandbox limits what a hijacked call can touch.

The specification says that MCP cannot enforce its security principles at the protocol level, and leaves them to hosts and servers.

How is MCP different from an agent skill?

An agent skill is a folder with a SKILL.md file of instructions and optional scripts. An agent reads the skill into its context when a task matches the skill's description. MCP connects an agent to a separate program that runs and returns results, while a skill adds instructions to the agent's own context.

An MCP server fits when the agent needs live access to a system with its own credentials or state. A skill fits when the agent needs a repeatable procedure, e.g. the steps of a project's release check. The two overlap, because a skill can tell the agent which MCP tools to call and in what order.

FAQs

Who created MCP?

Anthropic created the Model Context Protocol (MCP) and published it as an open standard. Anthropic later donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation.

Is MCP an API?

MCP is a protocol, not the API of one service. A plain API needs client code written for it, while any MCP client can list a server's tools and call them the same way.

Should you use MCP or an agent skill?

The choice between MCP and an agent skill depends on what the agent lacks. An MCP server gives it live access to a system, and a skill gives it a repeatable procedure. The two work together when a skill names the MCP tools to call.

Is Playwright MCP a kind of MCP server?

Playwright MCP is an MCP server that exposes browser actions as tools. A coding agent connected to it drives a browser through tool calls and reads the accessibility snapshots it returns.