An MCP server is a program that exposes tools, data, and prompt templates to an AI model through the Model Context Protocol (MCP), an open standard for connecting language models to external systems. You run the server, an AI client like Claude Code or ChatGPT connects to it, and the model can then call the server's functions — read a file, query a database, hit an API — without any custom glue code for each model. Think of it as a universal adapter between an AI and the rest of your software.
That's the whole idea in three sentences. The rest of this post builds it out: how the client-server model works, what "tools, resources, and prompts" actually mean, how MCP differs from a plain API, and why it changed how coding agents are built.
Where MCP came from
MCP was introduced and open-sourced by Anthropic in November 2024. It started as a way for Claude to talk to external data sources, but because the spec was open and vendor-neutral, other companies adopted it fast. By late 2025 the ecosystem crossed 10,000+ public servers, and major AI labs — OpenAI, Google DeepMind, Microsoft — had shipped MCP support in their own products. Reporting also indicates Anthropic moved governance of the protocol to a Linux Foundation body in December 2025, which, if accurate, makes MCP a community-owned standard rather than one vendor's project. Either way, the practical result is the same: one protocol, many clients, many servers.
How an MCP server works
MCP uses a client-server architecture built on JSON-RPC 2.0 messages. There are three roles:
- Host — the AI application you interact with (Claude Code, an IDE, a chat app).
- Client — the connector inside the host that speaks MCP; one client per server connection.
- Server — the program that exposes capabilities. This is the "MCP server."
When the host starts, its client and your server perform a handshake and exchange what each side supports. From then on, the model can see the server's capabilities and invoke them during a conversation. Crucially, the model doesn't need to know how the server is implemented — only what it offers.
Servers expose three kinds of things, sometimes called the data layer:
- Tools — actions the model can call, like
search_files,run_query, orcreate_issue. Tools are the most-used primitive because they let the model do things. - Resources — read-only data the model can pull in as context, like a file's contents, a schema, or a document.
- Prompts — reusable prompt templates the server offers, often surfaced as slash commands or shortcuts in the host.
Communication rides over a transport. As of the current 2025-11-25 spec, MCP defines two: stdio, where the host launches the server as a local child process and talks to it over standard input/output (simplest, most common for local tools), and Streamable HTTP, where the server runs independently and handles connections over HTTP — the right choice for remote or production deployments. An older HTTP+SSE transport exists but has been deprecated. You write your tools once; the transport is just how bytes move.
MCP vs a plain API
This is the question I get most, so let me be direct: MCP doesn't replace APIs — it wraps them in a shape that AI models can discover and use consistently. An MCP server often calls a normal REST API under the hood. The difference is who the interface is designed for.
| Traditional API | MCP server | |
|---|---|---|
| Designed for | Human developers writing code | AI models at runtime |
| Discovery | Read docs, hardcode endpoints | Model queries the server for its capabilities |
| Integration cost | Custom code per API × per model | Write once, works with any MCP client |
| Interface style | REST/GraphQL, per-vendor conventions | One JSON-RPC protocol, uniform primitives |
| Who calls it | Your application logic | The model, mid-conversation |
| Auth/transport | Whatever the vendor chose | Standardized (stdio / Streamable HTTP) |
The headline benefit is combinatorial. Before MCP, connecting M models to N tools meant up to M × N bespoke integrations. With MCP it's M + N: each model speaks MCP, each tool exposes MCP, and they interoperate. That's why people call it "USB-C for AI" — one port instead of a drawer of dongles.
Why it matters for coding agents
Coding agents live or die by context and reach. An agent that can only read the prompt you paste is a toy; an agent that can read your repo, run your tests, query your database, and open a pull request is a teammate. MCP is how agents get that reach without every tool being hardwired into every agent.
I build openseek, an open-source TUI coding agent, and MCP is what lets it borrow the same server ecosystem as Claude Code instead of reinventing integrations. Add a Postgres MCP server and the agent can inspect your schema. Add a GitHub server and it can file issues. The agent code doesn't change — you just plug in more servers. That decoupling is the point.
It's worth separating MCP from a related concept: skills. An MCP server gives an agent new capabilities (external tools and data). A skill is more like packaged know-how — instructions and workflows that shape how the agent uses what it already has. They're complementary, and I go deeper on that split in what is a Claude Code skill. You can browse a curated set at /skills.
A concrete example
Say you want Claude Code to answer questions about your production database. You run a Postgres MCP server pointed at your DB (over stdio, as a local child process). It exposes a query tool and a resource that returns the schema. In your session you ask, "Which users signed up last week but never logged in again?" The model reads the schema resource, writes SQL, calls the query tool, gets rows back, and answers in plain English — no plugin written for that specific database, because the protocol is the plugin.
Want to actually wire one up? See how to add an MCP server to Claude Code, and for picks worth installing, the best MCP servers of 2026.
The short version
An MCP server is a standardized adapter that lets any AI model use your tools and data through one open protocol instead of one-off integrations. It's the plumbing that turned coding assistants into agents that can touch the real world.
If you'd rather have the signal without reading twenty explainers, we distill the week's most useful AI-dev developments — including notable new MCP servers — into a single calm digest. Get the weekly →
Sources: ChatForest MCP ecosystem 2026, MCP transports spec, WorkOS MCP in 2026. Governance and adoption figures reflect third-party reporting as of mid-2026 and may have shifted.