An MCP server is a small program that gives an AI application access to something outside itself: a database, a file system, a calendar, an issue tracker, your own app's API. It speaks the Model Context Protocol (MCP), an open standard, so any AI application that supports MCP can use it without a custom integration. If you are building a web app in 2026, MCP matters in two ways: the AI tools you build with increasingly use MCP servers, and your own app could offer one so that assistants like Claude or ChatGPT can work with it.
This guide explains what an MCP server is, how it differs from an ordinary API, what changed in the current version of the protocol, and the security rules that matter most if you connect or build one. Everything about the protocol below comes from the official MCP documentation, which lists 2026-07-28 as the current protocol version at the time of writing (October 2026).
What MCP is, in one paragraph
The official introduction describes MCP as "an open-source standard for connecting AI applications to external systems." It lets AI applications such as Claude or ChatGPT connect to data sources (local files, databases), tools (search engines, calculators) and workflows (specialised prompts). The documentation's own analogy is that MCP is "like a USB-C port for AI applications": one standard plug instead of a different cable for every device.
Anthropic announced and open-sourced MCP on 25 November 2024. The launch included the specification and SDKs, local MCP server support in the Claude Desktop apps, and an open-source repository of reference servers for systems such as Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Since then, the official site lists support in Claude, ChatGPT, Visual Studio Code, Cursor and other clients.
Host, client and server: who does what
MCP uses three roles, and most confusion disappears once they are clear.
| Role | What it is | Example |
|---|---|---|
| MCP host | The AI application the person uses | Claude Desktop, Claude Code, Visual Studio Code |
| MCP client | A connector inside the host, one per server | The object VS Code creates to talk to one server |
| MCP server | The program that provides context and actions | A filesystem server, a database server, Sentry's server |
The architecture guide puts it this way: the host "establishes connections to one or more MCP servers" by "creating one MCP client for each MCP server." So when you add three MCP servers to your editor, the editor runs three clients, each with its own dedicated connection.
The term server describes the role, not the location. A server can run on your own machine or on someone else's infrastructure:
- Local servers use the stdio transport (standard input and output). The host starts the server as a process on the same machine. The docs note that a local stdio server typically serves a single client.
- Remote servers use the Streamable HTTP transport. They run on the provider's platform and typically serve many clients. The docs give Sentry's official MCP server as an example of a remote server.
What an MCP server can offer
The protocol defines three core building blocks, called primitives, that a server can expose:
- Tools: functions the AI application can call to do something, such as run a database query, create a file or call an API.
- Resources: data the application can read for context, such as file contents, database records or a schema.
- Prompts: reusable templates that structure an interaction, such as a system prompt or worked examples.
The documentation's database example shows how they fit together: a database server could expose tools for querying, a resource containing the schema, and a prompt with examples of how to use the tools well.
Each primitive can be discovered at runtime. A client asks a server to list its tools, receives each tool's name, description and a JSON Schema describing its inputs, and only then calls one. The AI application merges the tools from every connected server into one list the model can choose from. When the model decides to use a tool, the host routes the call to the right server and passes the result back into the conversation.
Servers can also ask the user for input through a feature called elicitation, for example to confirm an action or collect a missing detail.
MCP server vs API: what is the difference?
"MCP server vs API" is one of the most common searches on the subject, and the answer is that they are not alternatives. An MCP server usually sits in front of an API.
Your app's REST API is designed for programs written by developers who read your documentation. An MCP server is designed for AI applications that discover capabilities at runtime. The differences that follow from that:
| Ordinary REST API | MCP server | |
|---|---|---|
| Who calls it | Code a developer wrote for your API | Any MCP-compatible AI application |
| How capabilities are found | Documentation, read by a person | Listed by the server at runtime, with descriptions and input schemas |
| Message format | Whatever you design | JSON-RPC 2.0, the same across all MCP servers |
| Integration work | One integration per consumer | Build once, usable by every MCP host |
That last row is the point of the standard. The official site says MCP "reduces development time and complexity when building, or integrating with, an AI application or agent." Without it, every AI product needs its own plugin for every service. With it, a service publishes one server and every compatible host can use it.
If you are designing the API that sits behind such a server, the basics still apply. Our guide to REST API design basics covers the methods, status codes and naming that make an API easy to wrap.
What changed in the 2026-07-28 version
MCP versions are dates. The versioning page explains that the identifier marks "the last date backwards incompatible changes were made," and that the version is not bumped for backwards-compatible updates.
The 2026-07-28 revision changed how connections work. According to the current architecture guide:
- MCP is now stateless. Every request carries the protocol version and the relevant capabilities in its metadata, so a server can process each request on its own instead of relying on an earlier handshake.
- Discovery is a request, not a handshake. Servers must implement a server/discover request that returns their supported versions, capabilities and identity. Calling it is optional; a client may send any request directly and handle a version error.
- Two client features are deprecated. Sampling (a server asking the host's model for a completion) and logging are marked deprecated as of this version. The docs tell new implementations to call model provider APIs directly and to log to standard error or use OpenTelemetry.
For compatibility, the versioning page points to guidance for working with the older, handshake-based revisions (2025-11-25 and earlier). Deprecated features stay in the specification for at least twelve months under the project's deprecation policy before they can be removed. If you use an official SDK, most of this is handled for you; if you are following an older tutorial, check which protocol version it targets before copying its connection code.
Security: what to check before you connect or build one
An MCP server can read data and take actions, so it deserves the same caution as any other code with access to your accounts. The official security best practices page is written for implementers, but several points apply directly to people building small apps.
Treat local servers as code you are running
The docs describe local MCP servers as binaries "downloaded and executed on the same machine as the MCP client," with possible direct access to the user's system. Their listed risks include arbitrary code execution, data exfiltration and data loss. They require that clients with one-click setup show "the exact command that will be executed" and get explicit approval first.
In practice: install local servers only from sources you trust, read the command your client is about to run, and be wary of anything that asks for access to your home directory or SSH keys.
Give tokens the smallest scope that works
The best practices page warns against broad scopes granted up front and recommends a "progressive, least-privilege scope model": start with low-risk read operations and ask for more only when a privileged action is first attempted. When you connect a remote server to a service like GitHub or a database, grant read-only access unless the task truly needs writes.
If you build a server: never pass tokens through
"Token passthrough" means accepting a token from the client and forwarding it to a downstream API without checking it was issued for your server. The specification forbids it, and the docs state plainly that MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server." The same page says servers that keep state between requests must not treat possession of a handle (such as a cart ID) as proof of identity, and should bind it to the authenticated user.
The same habits that protect any web app protect an MCP server: keep secrets out of code (see API keys security), validate every input, and put limits on how often a caller can hit expensive operations (see rate limiting explained).
Should your app have an MCP server?
For most first apps, not yet. An MCP server is worth building when people would plausibly want an AI assistant to work with your app on their behalf, for example reading their bookings, creating invoices or searching their notes. Before that point, a clean, documented API is the better investment, because an MCP server is mostly a thin, well-described layer on top of one.
A sensible order of work for a small product:
- Ship the app and a small, consistent API first.
- Add authentication with proper scopes, so a token can be limited to read or write.
- Wrap the most useful read-only actions as MCP tools, with clear names and descriptions.
- Add write actions later, behind confirmation, once you can see how people use the read-only ones.
The official SDKs and the MCP Inspector, a development tool listed in the architecture guide, are the place to start when you get there.
Frequently asked questions
What does MCP stand for?
Model Context Protocol. It is an open standard for connecting AI applications to external systems such as data sources, tools and workflows.
Is MCP only for Claude?
No. Anthropic created it, but the official site lists support across many clients, including ChatGPT, Visual Studio Code and Cursor. A server built to the standard works with any compatible host.
What is the difference between a local and a remote MCP server?
A local server runs on your machine and talks to the host over stdio. A remote server runs on the provider's infrastructure and uses Streamable HTTP, usually with OAuth-based authorisation, and can serve many users.
Is an MCP server the same as an AI agent?
No. The agent is the AI application deciding what to do. The MCP server is one of the things it can use: it offers tools, resources and prompts, and carries out the calls the agent makes.
Are MCP servers safe to install?
They are as safe as the code and permissions behind them. A local server runs with your user's privileges, so install only trusted servers, check the exact command before approving it, and grant the narrowest access that does the job.
