What Is MCP? The Model Context Protocol, Explained

Every useful AI app eventually needs to reach outside the chat: read a file, query a database, open a pull request, hit an API. The hard part was never the model. It was the wiring, a custom integration for every model crossed with every tool. MCP, the Model Context Protocol, is the standard that replaces that tangle with one common plug. This guide explains what MCP is, what an MCP server actually does, how the protocol works under the hood, and how to use and build one.

It assumes no background beyond having used a tool like Claude or ChatGPT. By the end you will know what MCP stands for, be able to read a diagram of how a tool call flows from model to server and back, add an existing server to your own setup, and write a minimal one yourself.

What you'll learn

What MCP stands for, and what it is in one sentence
The problem it solves: why M×N integrations became M+N
The client and server model, and what an MCP server really is
The three things a server exposes: tools, resources, and prompts
What a single tool call looks like, step by step
How to add a server to Claude, Cursor, or Claude Code, and how to build one

What is MCP?

MCP stands for Model Context Protocol. It is an open standard that defines one common way for AI applications to connect to external tools and data. Anthropic introduced it in late 2024 and open-sourced it; through 2025 other major AI companies and developer tools adopted it, which is why it has become the default answer to a question every builder hits: how do I let the model actually do things?

The one-line version worth remembering: MCP is a USB-C port for AI. Before USB-C, every device had its own cable. Before MCP, every AI app had its own way of bolting on tools. MCP is the single connector on both sides, so any app that speaks it can use any tool that speaks it, with no bespoke glue in between.

The name is literal. A model is only as useful as the context it has, the tools it can call and the data it can read. MCP is the protocol for delivering that context in a standard shape. Not a product, not a framework, not an Anthropic-only thing: a specification anyone can implement, the way HTTP is a specification, not a website.

Why MCP exists: the integration problem

Picture a team with a few AI apps (a chat client, a coding agent, an internal assistant) and a few systems those apps need to reach (GitHub, a database, the filesystem). Without a standard, every app needs a hand-built integration to every system. Three apps and three tools is nine integrations, and it gets worse fast: M apps times N tools. Each one is written, maintained, and broken separately.

The same six pieces, two worlds. Without a standard, every app is wired to every tool by hand and the count grows as M×N. With MCP, each app implements the protocol once and each tool is wrapped once, so the total is M+N and a new tool instantly works in every app. This is the entire reason MCP exists.

This is the oldest pattern in software: when too many things need to talk to too many other things, you put a standard in the middle. USB did it for peripherals, HTTP did it for the web, the Language Server Protocol did it for code editors. MCP is that move for AI and its tools.

How MCP works: clients and servers

MCP is a client and server protocol. There are three roles. The host is the AI app you use, Claude Desktop, Cursor, Claude Code. Inside it runs one or more clients, each holding a connection to a server. A server is a small program that exposes some specific capability: one for GitHub, one for your database, one for the filesystem.

The client and server model. One host can run many clients, each connected to a different server. Servers are independent programs, so they can be written in any language, run locally or in the cloud, and be shared. Local servers usually talk over stdio (the host launches them as a subprocess); remote servers talk over HTTP. The model never touches a server directly; it asks, and the client carries the message.

Why separate programs instead of building tools straight into the app? Because separation is the whole point. A server is written and secured once, by whoever knows that system best, and then reused everywhere. The host does not need to know how GitHub's API works; it only needs to speak MCP.

What a server exposes: tools, resources, prompts

An MCP server can offer three kinds of things. Most of the attention goes to the first, but all three matter, and they differ by who is in control.

Three primitives, three controllers. Tools are model-controlled: the model decides when to call them, which is what makes agents possible. Resources are app-controlled: data the host pulls in as context. Prompts are user-controlled: templates a person invokes deliberately. Many servers ship only tools, but the richer ones use all three.

In practice, tools are where the power and the risk live, because a tool lets the model do something. Resources and prompts are about feeding the right context in and giving people clean shortcuts. When someone says "an MCP server for X," they almost always mean "a set of tools for X."

What a single tool call looks like

Connect the parts and a tool call is a short, legible round trip. Here is the whole thing, from the model deciding it needs data to the answer coming back.

One round trip. The model never speaks to the system directly; it asks the client, the client speaks MCP to the server, and the server is the only thing that touches the real API or database. That boundary is what makes a server reusable, and it is also where you put your security controls. After step six the model loops, exactly the agent loop from the companion guide, calling more tools until the goal is met.

How to use an MCP server

You do not have to build anything to benefit from MCP. Hundreds of servers already exist for common systems, and adding one to an app is a small config change. Every host reads a JSON config that lists the servers it should connect to: a name, how to start it, and any secrets.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    },
    "nextbigdev": {
      "url": "https://www.nextbig.dev/mcp"
    }
  }
}

Two servers, two transports. The first is local: the host launches it as a subprocess and talks over stdio. The second is remote: the host connects to a URL over HTTP. That second one is real, by the way, nextbig.dev runs its own MCP server so agents can search our wire and read briefings; see the agent interface for the live tools. Exact config keys differ slightly per app, but the shape is the same in Claude Desktop, Cursor, and Claude Code.

Finding servers. There are public directories and registries of MCP servers for GitHub, Slack, Postgres, Stripe, Sentry, browsers, and most SaaS tools, plus an official set of reference servers. When people ask for an "MCP server list" or the "best MCP servers," that is what they are after. Treat the list the way you would any dependency: prefer official or well-reviewed ones, and read what a server can do before you connect it.

How to build an MCP server

Building one is the fastest way to understand MCP, and it is genuinely small. The official SDKs (Python and TypeScript) handle the protocol; you write the tools. Here is a complete, minimal server in Python:

// pip install mcp
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """Get today's forecast for a city."""   # the model reads this line
    return lookup_weather(city)              # your real logic

mcp.run()   # serve over stdio

That is a working server. The @mcp.tool() decorator turns a function into a tool: the name, the typed arguments, and the docstring become the tool's schema, which is exactly what the model sees when deciding whether to call it.

Write clear descriptions. The model picks tools from their descriptions, not your code. A vague docstring is the most common reason a tool never gets called, or gets called wrong.
Keep tools small and typed. One job per tool, with a strict input schema. Narrow tools are easier for the model to use correctly and easier for you to secure.
Choose a transport. Stdio for a local tool you run yourself; HTTP when you want a server other people or apps can reach. Start local, go remote when you need to.
Test it in a real client. Point Claude Code or Cursor at your server and watch the model use it. The way it misuses a tool tells you what to fix in the description.

Is MCP safe?

MCP itself is just a connector. The risk is what a connector implies: you are giving a model the ability to take real actions, sometimes through servers you did not write. That is worth taking seriously, not fearing.

Treat every server as untrusted code. Two failure modes matter most. Tool poisoning hides instructions in a tool's description, which the model reads but you usually do not, turning a "helpful" server into an attacker. The confused-deputy problem lets a server use its own broad credentials to do something you should not be able to, especially with over-scoped tokens. Defenses are ordinary and effective: install servers you can vet, scope their credentials to the minimum, log every tool call, and require human approval for anything destructive. The full picture is in our AI security guide.

Frequently asked questions

What does MCP stand for?

MCP stands for Model Context Protocol. It is an open standard, introduced by Anthropic in late 2024 and open-sourced, that defines a common way for AI applications to connect to external tools and data. The name is literal: it is a protocol for giving a model the context, the tools and data, it needs to do real work.

What is MCP in AI?

MCP is a standard interface that lets an AI app talk to outside tools and data sources without a custom integration for each one. Instead of wiring every model to every service by hand, each tool is wrapped in an MCP server once, and any MCP-capable app can use it. The common analogy is a USB-C port for AI: one connector, many devices.

What is an MCP server?

An MCP server is a small program that exposes a set of tools, data, or prompt templates over the Model Context Protocol. It sits between an AI app and a specific system, a database, GitHub, your filesystem, a SaaS API, and translates between them. You can run one locally or host it remotely, and any MCP client can connect to it.

How does MCP work?

MCP uses a client and server model. The host app, such as Claude or Cursor, runs an MCP client that connects to one or more MCP servers. They exchange JSON-RPC messages: the client asks each server what it offers, the model decides to call a tool, the client sends the request, the server runs it and returns the result, and that result goes back to the model for its next step.

What is the difference between MCP and function calling or an API?

Function calling is how a single model is told a tool exists inside one request; MCP is the standard that lets that tool be discovered and called the same way across many apps. An API is the underlying service; an MCP server is a thin wrapper that exposes an API, or files, or a database, in the shape every MCP client understands. MCP does not replace function calling or APIs, it standardizes how agents reach them.

How do I add an MCP server to Claude, Cursor, or Claude Code?

In each app you add a server to a small JSON config: a name, the command to start it for local servers, or a URL for remote ones, plus any credentials. Claude Desktop, Cursor, and Claude Code all read this config and connect on launch, after which the server's tools appear to the model automatically. Directories of ready-made servers exist for common systems.

How do I build an MCP server?

Use the official Python or TypeScript SDK. You define each tool as a function with a name, a description, and an input schema, then run the server over stdio for local use or HTTP for remote. The model reads your descriptions to decide when to call each tool, so clear descriptions matter as much as the code. A minimal server is a few dozen lines.

Is MCP free and open source?

Yes. The Model Context Protocol is an open specification with open-source SDKs, free to use and implement. Anthropic introduced it and other major AI companies and tools adopted it through 2025, which is why a server built for one client tends to work in the others.

Is MCP secure?

MCP is a connector, so its risks are the risks of giving a model real tools. A malicious server can hide instructions in a tool description, called tool poisoning, and an over-permissioned server can be tricked into misusing its access, the confused-deputy problem. Treat every server you install as untrusted code: review it, scope its credentials tightly, log tool calls, and gate destructive actions behind human approval.

Glossary

MCP (Model Context Protocol): An open standard for connecting AI applications to external tools and data through one common interface, so a tool built once works across many apps.
Host: The AI application you use, such as Claude Desktop, Cursor, or Claude Code, which runs the model and one or more MCP clients.
Client: The component inside the host that holds a connection to a single server and carries messages between it and the model.
Server: A standalone program that exposes tools, resources, or prompts for one system over MCP. Runs locally or remotely.
Tool: A function a server exposes that the model can choose to call to take an action. The model-controlled primitive, and the one that makes agents possible.
Resource: Data a server exposes for the host to read in as context, such as a file or a schema. App-controlled.
Prompt: A reusable template a server exposes for a user to invoke deliberately, often as a slash command. User-controlled.
Transport: How a client and server talk: stdio for local servers the host launches, or HTTP for remote ones.
JSON-RPC: The lightweight message format MCP uses for requests and responses between client and server.
Tool poisoning: An attack that hides malicious instructions in a tool's description, which the model reads but a user usually does not.

Where to go next

You now have the whole picture: what MCP stands for, the M+N problem it solves, the client and server model, the three primitives, a tool call end to end, and how to use and build a server. MCP is the plug; what you connect to it is the leverage.

The natural next step is the companion guide on what an AI agent is, since MCP is how agents reach their tools, and the AI security guide covers the threat model in full. For the live moves, our AI agents news hub tracks the frameworks and protocols as they ship, and nextbig.dev exposes its own tools to agents over an MCP server you can connect today.

For the daily moves in models, agents, and the standards that connect them, the daily briefing reads the wire every morning and closes each edition with one falsifiable call we settle in public. This guide is part of The Primer, our growing library of ground-up explainers, re-checked against the live landscape each month so the details stay current.