Skip to content

AI agents · guide

What an MCP server is

6 min read · Last checked 5 October 2026

Watch: L007: Secure Your API Keys From AI Agent in 10 minutes · L008: The Hidden Prompt Injection Inside Your AI Agent

An AI agent has two halves. The brain is the AI model: the program that reads your request, thinks, and decides each step. It lives far away, on the provider’s servers. The hands are the agent program on your laptop, such as Claude Code, Anthropic’s AI coding agent. The brain can’t touch anything itself. It sends a request down to the hands, such as “open this file”. That request is called a tool call.

This page explains MCP servers: add-ons that give the hands extra tools.

A tool is one action the agent can take for the model, such as reading a file or running a command. The Claude Code docs put it plainly (here, “Claude” means the AI model): “Without tools, Claude can only respond with text. With tools, Claude can act.”

The built-in tools cover your own computer. But you may want the agent to read your calendar, look something up in a database, or open a ticket, and each of those lives in a different app. Without a shared standard, every AI app builds its own connection to each one.

MCP stands for Model Context Protocol. A protocol is an agreed way for two programs to talk: which messages they send, in what shape, and what each one means. When both sides follow the same protocol, they understand each other without being built for each other.

The official introduction calls MCP “an open-source standard for connecting AI applications to external systems.” It also gives this comparison: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.”

So a connection built once, the MCP way, can plug into any AI app that supports MCP.

The MCP docs use three names for the pieces:

  • Host: the AI app you use, such as the Claude Code agent. It manages the connections.
  • Client: a small part inside the host. The host makes one client for each server, and that client keeps the connection open.
  • Server: a separate program that offers tools to the host. In everyday words, a server is any program that waits for requests and answers them. It doesn’t have to be a big machine in a data center.

A server can offer three kinds of things. Tools are actions the model can ask for. Resources are information the server can hand over, such as a file or a database record. Prompts are ready-made instructions that help shape a conversation with the model.

Here is one round trip:

  1. You ask the agent: “What’s on my calendar tomorrow?”
  2. The model, far away, decides it needs a calendar tool and sends a tool call.
  3. The host on your laptop passes the request to the calendar MCP server.
  4. The server reads your calendar and sends the answer back.
  5. The answer travels up to the model, which writes your reply.
One MCP round trip1: you ask the agent on your laptop, the host. 2: the AI model, far away on the provider’s servers, sends a tool call back down. 3: the host passes the request to the MCP server. 4: the server reads your calendar and sends the answer back to the host. 5: the answer travels up to the model, which writes your reply. AI MODELon the provider's serversYOUHOSTlike the Claude Code agentMCP SERVERoffers toolsCALENDAR15your question (1),then the answer (5)2tool call34
One round trip, numbered like the list above.

MCP servers run in one of two places. A local server runs on your own computer. A remote server runs somewhere else, and the host reaches it over the internet. The MCP docs give an example of each: a filesystem server that runs on your machine, and Sentry’s server (Sentry is a service that collects app errors), which “runs on the Sentry platform.”

A local server talks to the host directly, on the same machine (the docs call this stdio). A remote server talks to it over the internet (the docs call this Streamable HTTP).

An MCP server can do whatever it was built to do, with whatever access you give it. A calendar server needs a way into your calendar. A database server needs a way into your database. That access usually comes as a token or key: a secret piece of text that proves to a service that the request is allowed, much like a password. Some remote servers ask you to sign in instead, and the agent stores the result. Keys and tokens are explained in the .env files guide.

In Claude Code, MCP servers sit outside the sandbox, the wall around the commands the agent types in its shell, the program that reads typed commands and runs them (the terminal guide). The sandbox docs say: “The sandbox covers shell commands only. Claude’s file tools, MCP servers, and hooks run outside it.” They add that local MCP servers “run with your full access.” That means the same files and programs your own user account can reach. The sandbox guide explains what the wall does cover.

What does reach MCP tools is the permission rules. The sandbox docs say permission rules “apply to every tool: Bash, Read, Edit, WebFetch, MCP, and others.” So a deny rule (a settings line that refuses a tool) can block a server’s tools even though the sandbox can’t.

  1. Trust it first. The Claude Code docs say: “Verify you trust each server before connecting it.”
  2. Be careful with servers that read outside content. The same warning goes on: “Servers that fetch external content can expose you to prompt injection risk.” Prompt injection means text hidden in a web page, email or ticket that tries to give the model orders.
  3. Check what access it asks for. Look at which keys, tokens or sign-ins it needs, and give it the smallest access that does the job.
  4. Read a project’s server list before you approve it. A project can list MCP servers in a file called .mcp.json. The docs say that in interactive sessions Claude Code “prompts for approval” before it uses them. In automated runs it can’t ask, so it loads them without a prompt. Don’t approve a server you don’t recognise.
  5. Block what you don’t need. A deny rule is a line in Claude Code’s settings file, .claude/settings.json, that tells it to refuse a tool. This example from the permissions docs refuses every MCP tool:
{
"permissions": {
"deny": [
"mcp__*"
]
}
}

To block one server only, the docs use its name, for example mcp__puppeteer for a server named puppeteer.

Sources

Facts on this page are explained in our own words. Short quotes are marked and linked.