An MCP server is a small program that gives an AI assistant access to something it cannot do on its own - your database, your ticketing system, your file storage, your company's internal API - through a standard interface called the Model Context Protocol. The AI is the client; the MCP server is the adapter between it and the real world.
The comparison that stuck across the industry: MCP is a USB-C port for AI. Before it, every AI product needed a custom integration for every tool, written separately, maintained separately, incompatible with everything else. With MCP, you write one server for your system and every MCP-capable client can use it - Claude, ChatGPT, Cursor, Windsurf, agent frameworks, and whatever ships next quarter.
Where MCP came from
Anthropic released the Model Context Protocol as an open standard in November 2024, and the rest of the industry did something unusual: instead of shipping competing standards, they adopted it. OpenAI added MCP support across its products in 2025, the developer-tool ecosystem (Cursor, Windsurf, Zed, JetBrains) followed, and by now "does it have an MCP server?" is the standard question asked about any SaaS product - the way "does it have an API?" was asked for the last fifteen years.
That adoption is the whole reason the term matters. An integration standard is only as valuable as the number of clients that speak it, and MCP crossed that threshold.
What an MCP server actually exposes
Three kinds of things, defined by the protocol:
- Tools - actions the AI can take: run a query, create a ticket, send a message, deploy an app. The server describes each tool and its parameters; the client's model decides when to call them.
- Resources - data the AI can read: files, records, documents, schemas. Think of these as things the assistant can pull into its context.
- Prompts - reusable, parameterized instructions the server offers to the client, for workflows the tool's author knows best.
A minimal MCP server might expose a single tool ("search our docs"). A rich one might expose your whole product surface - which is why companies now ship official MCP servers the way they ship SDKs.
Local vs remote: the distinction that actually matters
MCP servers run in one of two ways, and the difference decides everything about how you operate them.
Local servers run on the same machine as the client, typically spawned as a subprocess and talked to over standard input and output. This is how most people first meet MCP: your editor starts a filesystem server or a git server on your laptop. Local is perfect for personal tools that touch local things.
Remote servers run somewhere else and speak HTTP. This is what you want the moment more than one person - or more than one machine - needs the same integration: the team's Postgres server, the company's internal-API server, the production deployment tools. A remote MCP server is a long-running network service with a URL, authentication, and uptime expectations.
That second category has an operational reality people discover late: a remote MCP server is a normal always-on web service, not a serverless function. Sessions are stateful, clients hold connections open, and cold starts break the experience mid-conversation. We wrote a whole guide on this - How to Host an MCP Server - because the "just put it on a function platform" instinct is the single most common mistake.
Why this matters more every month
The short version: agents. An AI that can only talk is a chatbot; an AI with MCP servers attached is an agent that can look things up and do things. Every capability you want an agent to have arrives, in practice, as an MCP server. Teams building with agents accumulate them the way teams once accumulated microservices - a server for the database, one for the CRM, one for deployment, one for the docs.
Which puts MCP servers squarely in the category we call small software: purpose-built tools, a handful of users each, easy to create - the reference SDKs make a basic server an afternoon project - and needing somewhere cheap and boring to run. A team of five might run ten of them. That arithmetic is exactly why per-service billing hurts here and why we host ours on a flat plan alongside everything else.
How to get one
Three routes, in increasing order of effort:
- Use official servers. Most major products ship one - check the vendor's docs or the MCP registries. Configuration is usually a few lines in your client's settings.
- Deploy an existing open-source server. Thousands exist for databases, project trackers, search engines, and file stores.
- Write your own. The official SDKs (TypeScript, Python, and others) handle the protocol; you write the tool functions. A server that exposes two or three tools over HTTP is genuinely a small file - and deploying it is a git push.
Frequently asked questions
What is an MCP server in one sentence?
A small program that exposes tools, data, or actions to AI assistants through the Model Context Protocol, so any MCP-capable client - Claude, ChatGPT, Cursor and others - can use the same integration.
Is an MCP server the same as an API?
No, but it is a close cousin. An API is designed for developers to call from code; an MCP server is designed for AI models to call during a conversation, with machine-readable descriptions of every tool so the model can decide when and how to use them. Many MCP servers are thin wrappers that translate an existing API into MCP.
Do I need to host an MCP server myself?
For local, personal use: no - your client starts it as a subprocess. The moment a team shares one, or an always-available agent depends on it, it becomes a remote server: a long-running HTTP service with a URL and authentication that has to stay up. That is regular web hosting, and our hosting guide covers the specifics, including why serverless platforms fit badly.
Who created MCP, and who supports it?
Anthropic released it as an open standard in November 2024. It has since been adopted far beyond its origin - OpenAI's products, major code editors, and agent frameworks all speak it, which is precisely what makes building one worthwhile.
How big does a server for my own tool need to be?
Small. The SDKs handle the protocol, so a useful server is often a few hundred lines exposing a handful of tools. It is a textbook example of small software: quick to build, valuable to a handful of users, and mostly needing a boring, always-on place to live.