Ask five developers what an MCP server is and you get five answers: a plugin, an API wrapper, an agent, a Docker container, a block of JSON you paste into a config file. Only one of those is close, and the confusion has a real cost when you start building one.
The short answer: An MCP server is a program that exposes tools, data, and prompt templates to AI applications through the Model Context Protocol, an open standard built on JSON-RPC 2.0. Anthropic released MCP in November 2024. Any MCP compatible client can call any MCP server.
That definition is short enough to be useful and vague enough to leave the interesting questions open. What exactly does a server expose? Who talks to it? Does it run on your laptop or on a machine somewhere? This guide answers those, including the one most explainers skip: where an MCP server actually lives once more than one person needs it.
What Is an MCP Server?
MCP means Model Context Protocol. The protocol defines a message format and a small set of named methods. An MCP server is any program that implements the server half of that contract.
The meaning is deliberately narrow, and the narrowness is the point. An MCP server contains no model. It makes no decisions. It publishes a list of things it can do, waits for a client to call one, executes it, and returns a structured result. The reasoning stays in the AI application. The execution lives in the server.
On the wire, MCP uses JSON-RPC 2.0, the same request and response encoding the Language Server Protocol uses. That choice is not an accident. LSP solved a similar problem for code editors: rather than every editor implementing support for every language, each language ships one server and each editor ships one client. MCP applies the same shape to AI applications and the systems they need to reach.
Anthropic published the protocol and open sourced it on 25 November 2024, in the Model Context Protocol announcement. On 9 December 2025 Anthropic donated MCP to the Linux Foundation, where it became a founding project of the Agentic AI Foundation alongside the goose agent framework and the AGENTS.md specification. The foundation was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. The specification and the official SDKs are MIT licensed.
At the time of that donation Anthropic reported more than 10,000 active public MCP servers and more than 97 million monthly SDK downloads across the Python and TypeScript SDKs. Whatever else is true about MCP, it is no longer an experiment.
Why Does MCP Exist? The N × M Integration Problem
Before MCP, connecting an AI application to an external system meant writing a bespoke integration. Every AI application needed its own connector for every tool, and every tool vendor needed a connector for every AI application.
That is the N × M problem. Six AI applications and twelve tools means seventy two separate integrations, each with its own auth handling, error semantics, and maintenance burden. Add one more tool and you write six more connectors.
MCP turns that multiplication into addition. Each AI application implements one MCP client. Each tool ships one MCP server. Six clients plus twelve servers is eighteen pieces of software instead of seventy two, and adding a thirteenth tool costs exactly one new server that every client can already use.
This is the single most quoted framing of MCP, and it holds up because it describes an economic fact rather than a technical preference. The protocol is not faster or cleverer than a custom HTTP integration. It is simply written once instead of N times.
What Does an MCP Server Expose?
A server offers three kinds of thing. They differ in who decides when to use them, which is the distinction most people miss.
| Primitive | What it is | Who controls it | Example |
|---|---|---|---|
| Tools | Executable functions the model can call to take an action | The model | Query a database, send a message, create a calendar event |
| Resources | Read only data the application can pull in as context | The application | A file's contents, a database schema, an API document |
| Prompts | Reusable instruction templates the user invokes deliberately | The user | A "summarize this incident" template with typed arguments |
Tools are the ones everyone means when they say MCP server. Each tool carries a name, a description, and a JSON Schema describing its inputs, so the model can decide when it applies and how to call it. Clients discover tools with tools/list and invoke them with tools/call.
Resources are passive. They are addressed by URI, such as file:///docs/runbook.md or a template like crm://customers/{id}, and the application decides what to read and how much of it to put in front of the model. Methods are resources/list and resources/read.
Prompts are templates that the user picks explicitly, usually surfaced as slash commands in the host application. Methods are prompts/list and prompts/get.
Defining a tool takes very little code. Here is a complete server using the official Python SDK:
from mcp.server import MCPServer
mcp = MCPServer("Support Tools")
@mcp.tool()
def lookup_order(order_id: str) -> dict:
"""Look up an order by its ID and return status and item count."""
return {"id": order_id, "status": "shipped", "items": 3}The docstring becomes the tool description the model reads. The type hints become the JSON Schema the client validates against. That is the entire contract.
When a client calls that tool, the message on the wire is ordinary JSON-RPC:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "lookup_order",
"arguments": { "order_id": "A-10482" },
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}Nothing exotic is happening. That is a large part of why the protocol spread quickly.
How Do Host, Client, and Server Fit Together?
Three terms appear constantly in MCP documentation and they are not interchangeable.
The host is the AI application itself. Claude Desktop, an IDE, a chat product, an internal agent you built. The host owns the conversation and the model.
The client is a connector inside the host. The host creates one client per server it connects to, and each client maintains one connection. If your IDE connects to three MCP servers, it is running three clients.
The server is your program. It has no idea which model is on the other end, and it does not need to.
The practical consequence is that servers are not tied to a vendor. The same server that Claude Desktop connects to can be used by an IDE, by an internal agent, or by a script, because they all speak the same protocol. Write the server once, and every compliant host is a potential caller.
What an MCP Server Is Not
Most of the confusion around MCP comes from mapping it onto something familiar that it only partly resembles.
| People assume | Reality |
|---|---|
| It is a REST API | Not the same shape. REST models resources with URLs and verbs. MCP is JSON-RPC with a fixed method set and machine readable schemas designed for a model to choose between. An MCP server often wraps a REST API, which is not the same as being one. |
| It is a plugin | Plugins are specific to one host and load into its process. An MCP server is a standalone program, speaks a public protocol, and works with any compliant host. |
| It is an AI agent | An agent plans and decides. A server executes and returns. All the reasoning happens on the client side. |
| It contains a model | It does not. Servers hold credentials and business logic, not weights. |
| It is Anthropic proprietary | The protocol was created by Anthropic, open sourced from day one, and has been governed by the Linux Foundation since December 2025. Clients from multiple vendors implement it. |
| One server means one tool | A single server can expose many tools, resources, and prompts. Grouping related capabilities in one server is the normal pattern. |
Getting this right matters when you design one. If you think you are writing a REST API, you will build endpoints. If you understand you are writing an MCP server, you will build a small number of well named tools with descriptions a model can actually reason about.
Local or Remote: Which Kind of MCP Server Are You Building?
The specification defines two standard transports, and the choice between them determines almost everything about how you operate the server.
stdio means the client launches your server as a subprocess and exchanges newline delimited JSON over standard input and output. There is no network, no port, and no URL.
Streamable HTTP means your server is an ordinary web service. Each message is an HTTP POST to a single endpoint, and replies come back as a JSON object or a request scoped Server Sent Events stream. This transport replaced the older HTTP+SSE transport in the 2025-03-26 revision, and HTTP+SSE is now formally deprecated.
| Local (stdio) | Remote (Streamable HTTP) | |
|---|---|---|
| Transport | Newline delimited JSON over stdin and stdout | HTTP POST to a single endpoint, optional SSE stream |
| Who starts it | The client, as a child process | You, as a long running service |
| Who can reach it | Only the user on that machine | Anyone with the URL and valid credentials |
| Authentication | Inherits the user's OS session, secrets in local env vars | Bearer tokens, API keys, or OAuth on every request |
| Typical use | Filesystem access, local databases, personal dev tools | Shared team tools, SaaS integrations, anything an automated agent calls |
| Operational burden | None. It dies with the client | Real. Hosting, TLS, uptime, secrets, logs |
| Cost | Free, it runs on hardware you already own | Whatever the hosting costs |
Almost every MCP server starts life as stdio, because that is what the tutorials show and it is genuinely the fastest path to a working tool. The transition to HTTP happens the moment a second person wants to use it, or a scheduled job needs to call it at three in the morning while your laptop is closed.
Switching transports usually does not mean rewriting anything. The same server file runs either way:
# Local: the client launches your server as a subprocess over stdio
uv run mcp dev server.py
# Remote: the same server, served over Streamable HTTP
uv run mcp run server.py --transport streamable-httpIf you are at the point of writing your first one, the guide to building an MCP server walks through it end to end, and MCP server examples covers patterns worth copying.
Where Does an MCP Server Actually Run?
This is the question the definition articles leave out, and it is the one that decides whether your server is a demo or a tool your team uses.
A stdio server runs nowhere in particular. It is a script on a disk that a client executes on demand. There is no deployment, no URL, and no bill. It also cannot be shared, cannot be called by anything other than a human sitting at that machine, and stops existing when the process exits.
An HTTP server is a normal long running web service, with all that implies. It needs a host, a public HTTPS endpoint with a valid certificate, environment variables for its credentials, logs you can read when a tool call returns a 500, and a process that stays up. Most MCP servers are small and mostly idle, spending their time waiting for occasional tool calls, so the compute requirement is modest. The operational requirement is not zero.
Out Plane runs this kind of workload as an ordinary application. You connect a GitHub repository or a container image, set the port your server binds to, add your credentials as environment variables, and get an HTTPS URL with a certificate provisioned automatically. Compute is metered by the minute, and at least one instance stays running, so the first tool call after a quiet hour is as fast as any other. Everything runs in a single region, Nuremberg in Germany, which is a straightforward answer if EU data residency matters for whatever the server touches. Plans start at 9 dollars a month with a 14 day free trial. The step by step version is in how to deploy an MCP server.
Whatever you host it on, the checklist is the same: HTTPS, credentials outside the repository, authentication on the endpoint, and logs you can actually read. Our environment variables and secrets guide covers the credential half of that, and what a PaaS actually is covers the hosting half if the category is new to you.
What Language Can You Write an MCP Server In?
Any language that can read and write JSON over a stream or serve HTTP. In practice most people use an official SDK, and there are ten of them in the modelcontextprotocol GitHub organization.
The SDKs are grouped into tiers by feature completeness and maintenance commitment. TypeScript, Python, C#, Go, and Rust are Tier 1. Java and Ruby are Tier 2. Swift, PHP, and Kotlin are Tier 3. Several are co maintained with the relevant ecosystem stewards: the Go SDK with Google, the C# SDK with Microsoft, the Java SDK with Spring AI, the PHP SDK with The PHP Foundation, and the Kotlin SDK with JetBrains.
Python and TypeScript dominate in practice, which is why the download figure Anthropic cited covers only those two. Install is a one liner in either:
# Python
pip install "mcp[cli]"
# TypeScript
npm install @modelcontextprotocol/sdkThere is also an official MCP Inspector for poking at a server interactively before you connect a real client to it, and an official registry at registry.modelcontextprotocol.io for publishing server metadata. The registry is still in preview, so treat anything you publish there as subject to change.
Is MCP Stable Enough to Build On?
The protocol versions by date, in YYYY-MM-DD form, where the date marks the last backwards incompatible change. There have been five revisions.
| Revision | What it brought |
|---|---|
| 2024-11-05 | The original release. stdio and HTTP+SSE transports, tools, resources, prompts |
| 2025-03-26 | Streamable HTTP replaces HTTP+SSE. OAuth 2.1 based authorization |
| 2025-06-18 | Elicitation, structured tool output, resource links, security hardening |
| 2025-11-25 | Experimental async tasks, richer authorization discovery, icons and metadata |
| 2026-07-28 | Current. The protocol becomes stateless |
The 2026-07-28 revision is the largest break so far and worth understanding before you write anything new. It removed the initialize handshake and protocol level sessions entirely. Every request now carries its own protocol version and client capabilities in a _meta field, and a mandatory server/discover method reports what a server supports. The practical effect is that any instance can answer any request, so a remote MCP server sits behind ordinary HTTP infrastructure without sticky sessions.
The same revision deprecated the Roots, Sampling, and Logging features. They still work during the deprecation window, which the feature lifecycle policy sets at a minimum of twelve months, but new servers should not adopt them. The suggested replacements are tool parameters or resource URIs instead of Roots, a direct LLM provider integration instead of Sampling, and stderr or OpenTelemetry instead of Logging.
So: stable enough to build on, but not stable enough to ignore. Read the current specification before starting, and pin the SDK version you tested against.
Frequently Asked Questions
Is MCP the same as an API?
No, though the two are related. An API is a general term for any programmatic interface. MCP is one specific protocol, built on JSON-RPC 2.0, with a fixed method set and machine readable schemas designed so a model can pick the right call on its own. Many MCP servers are thin wrappers around an existing REST API, translating it into a form a model can discover and use.
Do I need to write my own MCP server?
Often not. There are more than 10,000 active public MCP servers, covering filesystems, databases, issue trackers, and most major SaaS products. Write your own when you need to reach an internal system, enforce your own access rules, or expose a workflow that does not map to any existing server. Check the official registry and the reference implementations first.
Is MCP only for Claude?
No. Anthropic created MCP and open sourced it in November 2024, then donated it to the Linux Foundation in December 2025. It is now governed by the Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI. Clients across multiple vendors implement it, including ChatGPT, Visual Studio Code, and Cursor. A server you write works with any compliant host.
Is MCP open source?
Yes. The specification, the schema, the ten official SDKs, the Inspector, and the reference servers are all MIT licensed and developed in public on GitHub. Changes go through a public proposal process, and the protocol is stewarded by the Linux Foundation rather than any single company.
What language can I write an MCP server in?
Any language capable of JSON over a stream or over HTTP. Official SDKs exist for TypeScript, Python, C#, Go, Rust, Java, Ruby, Swift, PHP, and Kotlin. TypeScript and Python are the most widely used and have the most complete documentation, so pick one of those unless you have a reason to stay in another stack.
Does an MCP server cost money to run?
A local stdio server costs nothing. It runs as a subprocess on hardware you already own and stops when the client stops. A remote HTTP server is a hosted web service and costs whatever hosting costs. Because most MCP servers are small and mostly idle, that is usually the lowest tier of a platform. On Out Plane, plans start at 9 dollars a month and open with a 14 day free trial.
How does an MCP client authenticate to a remote server?
Over standard HTTP mechanisms. The Streamable HTTP transport supports bearer tokens, API keys, and custom headers, and the specification recommends OAuth for obtaining tokens. Because the current revision is stateless, credentials travel with every request rather than being established once per session, which is exactly how ordinary HTTP APIs already behave.
Where to Go Next
An MCP server is a small, boring program with a very specific job: publish a set of capabilities, and run them when asked. The protocol underneath is JSON-RPC, the schema is JSON Schema, and the transports are a subprocess pipe or an HTTP endpoint. There is no magic in it, which is precisely why it caught on.
The useful mental model is this. Tools, resources, and prompts describe what your server offers. Host, client, and server describe who is talking. stdio versus Streamable HTTP describes where it runs and, by extension, who else can use it.
Most servers start on a laptop over stdio and stay there. The ones that become useful to a team cross over to HTTP, at which point they stop being a script and start being a service that needs a URL, a certificate, credentials, and logs. If you have reached that point, deploying an MCP server covers the move, or you can start from the Out Plane console with a 14 day free trial.
