What Are MCP Servers? How They Work and How to Add One

An MCP server is a program that gives an AI application a set of tools and data through the Model Context Protocol (MCP), an open standard. The app you use (Claude, ChatGPT, Cursor, VS Code and many others) connects to the server, asks what it can do, and calls its tools when a task needs them. Because the protocol is shared, one server works in every app that supports MCP.

That is the short answer. This guide explains how MCP servers work, what changed when the protocol went stateless in July 2026, how to add a server to the app you already use, and what to check before you trust one with real data.

MCP in plain terms

The project's own introduction calls MCP "an open-source standard for connecting AI applications to external systems" and compares it to a USB-C port: one standard connector instead of a different cable for every device (MCP introduction).

Three roles share the work:

The host is the AI application you use, such as Claude, ChatGPT, Cursor or VS Code.
The client is the connector inside the host. Each client holds a connection to one server.
The server provides the tools and data. It can be a program on your own computer or a service on the internet.

Client and server exchange JSON-RPC 2.0 messages, a simple request and response format. Anthropic released MCP in November 2024. In December 2025 it became one of the founding projects of the Agentic AI Foundation at the Linux Foundation, next to Block's goose and OpenAI's AGENTS.md (Linux Foundation announcement). No single vendor owns it any more.

The problem MCP servers solve

Before MCP, connecting an AI app to a database, a ticket system or an internal API meant writing custom code for that one pairing. With M apps and N tools you could end up maintaining M × N integrations, and every new app or tool added a whole row or column of work.

MCP turns that into M + N. Each tool needs one server and each app needs one client, and any client can talk to any server. A company that ships an MCP server for its product reaches every MCP app at once, and an app that supports MCP can use every server.

What a server offers: tools, resources and prompts

The specification lists three kinds of things a server can offer:

Tools are actions the model can call: search, run a query, create an issue, convert a file. Each tool has a name, a description and a JSON Schema for its inputs. The description is most of what the model sees when it decides whether to use a tool, so a vague one means the tool rarely gets picked.
Resources are data the app can read, such as a file, a record or a table schema, so answers can rest on current facts instead of what the model remembers from training.
Prompts are templates for common tasks that a user chooses, often from a slash command menu.

Many servers offer only tools, and the spec allows that.

Clients can offer something back. In the current revision that is elicitation: a server can ask the user for a missing detail or a confirmation partway through a task. Three older features are deprecated: roots, sampling and logging. They keep working for at least twelve months, but new servers should not rely on them (release notes).

How a tool call works

Say you ask your assistant to summarise the open issues in a repository, and it has a GitHub server connected:

The app gets the server's list of tools with a tools/list request.
The model reads the tool names and descriptions and chooses one, with arguments.
The app sends a tools/call request. The specification's safety principles say a host must get the user's consent before it invokes any tool.
The server does the real work, such as calling the GitHub API, and returns a structured result.
The model reads the result and answers, or calls another tool.

A server sees only what is sent to it, such as the arguments the model chose, not your whole conversation. Under the current revision a server also cannot start a request of its own: every exchange begins with a request from the client.

What changed in July 2026

The current revision of the protocol is 2026-07-28. It made the core stateless:

The initialize handshake and the Mcp-Session-Id header are retired. Each request carries its own protocol version and client details, so any server instance behind an ordinary load balancer can answer it.
A server/discover call returns a server's supported versions, capabilities and identity in one request, for clients that want them up front.
Servers no longer send requests to clients. When a server needs input during a call, it returns a result that says so, and the client retries with the answer (multi round-trip requests).
Deprecated features stay in the spec for at least twelve months under a formal deprecation policy. Besides roots, sampling and logging, that covers the old HTTP+SSE transport and dynamic client registration, which gives way to Client ID Metadata Documents.

Servers and clients built for the handshake revisions (2025-11-25 and earlier) can still work with newer ones: the specification describes how each side detects the other's version and falls back (transports overview). An older server is not broken, just older. When you build or choose a server, check which revisions it lists.

Local or remote: the two transports

The specification defines two standard ways to carry the messages:

Transport	Where the server runs	Setup	Good for
stdio	A program your app starts on your machine	A command in a config file	Your files, your shell, local tools
Streamable HTTP	A URL, run by you or by a vendor	Paste the URL	The same tools in several apps or on several machines

With stdio, the app launches the server as a subprocess and they exchange newline-delimited messages over standard input and output. Nothing goes over the network, and the server runs with your user's permissions. With Streamable HTTP, each message is an HTTP POST to one endpoint, and the reply comes back as JSON or as a short event stream for that request. The older two-endpoint HTTP+SSE transport is deprecated, so a setup guide that asks for a separate /sse URL is out of date.

A simple rule: keep a server local when it needs your files or your shell, and use a remote one when the same tools should work across apps and machines without installing anything. Our explainer on remote MCP servers goes deeper on Streamable HTTP.

MCP servers, APIs, function calling and skills

These terms get mixed up, so here is how they fit together.

An API is documented for a developer, who reads the docs and writes code for one app. An MCP server describes its own tools to the app at run time, so any MCP app can use it without new code. Many MCP servers are thin layers over an existing API: the API still does the work.
Function calling (or tool calling) is the model's ability to ask for a function to be run. MCP is the plumbing that lets those functions live outside the app, in a server that many apps can share.
Agent skills are SKILL.md files: written instructions an agent loads when a task matches, such as how to review a pull request. A skill can tell the model which MCP tools to use, but it does not add new abilities on its own. If you use Codex, see how to find and install Codex skills from GitHub.

Examples of MCP servers

Vendor servers for their own products. Notion, Stripe and HubSpot run hosted MCP servers that let an assistant work with your workspace, payments or CRM data once you sign in. The Claude Code MCP docs use all three as examples.
Meta's Ads MCP server is hosted by Meta and lets an AI agent create and edit campaigns and pull reporting from an ad account (Meta's overview). Our piece on Meta AI in 2026 covers the Ads server and the agent stack around it.
Documentation servers let an agent read current docs rather than what it remembers. Several answered our anonymous test with no account at all: see MCP servers that work with no API key.
Local servers for files, Git or a database run on your machine over stdio. The official reference servers on GitHub are a good way to learn how servers are built, but check a server's status first: several of the original reference servers were moved to an archive repository in 2025 and are no longer maintained.
Hosted tool servers like ours, described at the end of this guide.

Where to find MCP servers

The official MCP Registry at registry.modelcontextprotocol.io is the community's central list of public servers. It stores metadata (a server's name, where it lives and how to run it), checks that publishers own the namespace they publish under, and leaves security scanning to package registries and the catalogues built on top of it. It is still in preview (about the registry).
The vendor's own docs are the safest place to get the URL of an official server.
Directories and marketplaces add curation and ratings on top of the registry. Treat a listing as a pointer, not an endorsement. Our guide to MCP directories explains the difference between a registry entry and a vendor listing.

How to add an MCP server to your AI app

Each app does this differently, and the details change often. These steps were checked against each vendor's documentation on 10 November 2026:

Claude (claude.ai and the Claude apps): custom connectors work on the Free, Pro, Max, Team and Enterprise plans, and a Free account can add one. On Pro or Max, open Customize > Connectors, choose "+ Add", then "Add custom connector", and paste the server URL. On Team and Enterprise, an owner adds connectors under Organization settings > Connectors (Claude Help Center).
ChatGPT: custom MCP servers are added in developer mode, on the web only. Full support, including actions that change data, is rolling out in beta to Business, Enterprise and Edu workspaces, where admins control access. Pro users can connect servers with read and fetch permissions only (OpenAI Help Center).
Claude Code: run claude mcp add --transport http <name> <url>, then use /mcp in a session to check the server or sign in (Claude Code docs).
Cursor: add the server under mcpServers in .cursor/mcp.json for one project or ~/.cursor/mcp.json for all of them, with a url field for a remote server. You can also manage servers from the Customize page, and publishers can offer one-click install links (Cursor docs).
Codex: run codex mcp add <name> --url <url>, or add a [mcp_servers.<name>] table with a url to ~/.codex/config.toml (OpenAI developer docs).
VS Code: run MCP: Add Server from the Command Palette, choose HTTP and enter the server URL (VS Code docs).
Gemini CLI: run gemini mcp add --transport http <name> <url>. Servers are saved in .gemini/settings.json, or in ~/.gemini/settings.json with --scope user (Gemini CLI docs).

Then check that it works. Ask the app to list the server's tools and make one real call that only reads data. If no tools appear, the URL or the transport setting is usually the problem, often a typo or a missing path segment.

Are MCP servers safe?

A server can do whatever the access you give it allows. The specification is direct about this: tools amount to arbitrary code execution, tool descriptions should be treated as untrusted unless they come from a trusted server, and hosts must get the user's consent before sharing data with a server or invoking a tool (specification). In practice:

Know who runs it. A hosted server receives every argument you send it. Prefer a vendor's own server for its product, and check who publishes anything else.
Give it the least access that works. Start with read-only scopes, use a separate token for each server, and keep keys out of config files that end up in Git.
Read what a tool will do before you approve it, especially anything that writes, deletes, sends or pays.
Treat tool output as data, not instructions. A web page or an issue comment returned by a tool can carry text aimed at the model. This is called prompt injection.
Pin the versions of local servers, so an update cannot change the code you run without you noticing.
If you build servers, read the spec's security best practices before you expose one to the internet.

If you are building one

A server that works on your laptop is quick to write with an official SDK. A good one takes a little more care:

Write tool descriptions that say when to use the tool, not only what it does.
Keep inputs typed and strict, and return small, structured results. Every token of output uses the model's context.
Make tools safe to retry where you can, because an agent may retry after a timeout.
Return errors that say what went wrong and whether a retry will help, instead of a bare failure.
Target the current revision, 2026-07-28, and say which revisions you support.

Try one in a minute

The quickest way to understand MCP servers is to use one. Moltline Studio runs 22 hosted MCP servers with 160 tools, and 110 of those tools are free with no account, no API key and no signup. Every server has its own URL on the servers page. For example, to add the catalog server to Claude Code:

claude mcp add --transport http moltline-catalog https://mcp.moltlinestudio.com/catalog

In Cursor, add "moltline-catalog": { "url": "https://mcp.moltlinestudio.com/catalog" } under mcpServers. In Claude, paste the same URL as a custom connector.

Ask the app to list the tools, then call one. At the time of writing (November 2026) our servers use the handshake revisions 2025-06-18 and 2025-11-25, as their server card shows. One $19/month All-Access licence unlocks the other 50 premium tools on every server.

Frequently asked questions

Is an MCP server the same as an API?

No. Many MCP servers call an API behind the scenes, but an MCP server describes its own tools to any MCP app at run time, so the app needs no custom code for it.

Do I need to write code to use one?

No. Adding a remote server is usually a URL in your app's settings or a single command. You only write code to build your own server, and official SDKs exist for TypeScript, Python, Go, C# and other languages.

Is MCP only for Claude?

No. Anthropic created it, but ChatGPT, Cursor, VS Code, Codex, Gemini CLI and many other apps support it, and it is now governed through the Agentic AI Foundation at the Linux Foundation.

Are MCP servers free?

Many are. Open-source servers you run yourself cost nothing but your time, some hosted servers have free tiers, and a vendor's server usually needs an account with that vendor.

Which protocol version should a new server target?

The current revision, 2026-07-28. If the apps your users run still use the handshake revisions, the specification's backward-compatibility notes explain how to support both.