What is an MCP server? A plain-English guide

An MCP server is a small, standalone program that exposes tools, data or prompts to an AI agent using the Model Context Protocol(MCP) — an open standard Anthropic published in November 2024 for connecting AI applications to systems outside the model itself. Instead of a developer writing a bespoke integration for every database, API or file system an agent needs to touch, the agent's host application opens a connection to one or more MCP servers, asks each one what it can do, and calls whichever tool the task requires. The server itself usually has no idea it's talking to a language model — from its point of view, it just received a normal remote procedure call.

The problem MCP solves

Before MCP, connecting a language model to an external system meant writing custom glue code: one integration for Slack, another for Postgres, another for GitHub, each with its own auth flow and its own way of describing what it does. Every agent framework ended up reinventing the same connectors, and every new tool a team wanted to add meant another bespoke build. MCP standardizes the wire format on both sides — the AI application (the host) and the tool or data source (the server) — so a server built once can be used by any MCP-compatible client. Anthropic's original announcement put it plainly:

"Today, we're open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments."

— Anthropic, "Introducing the Model Context Protocol," November 25, 2024

The official documentation frames the same idea more visually: "Think of MCP like a USB-C port for AI applications" — one connector standard, many devices on either end. For a deeper walk through the protocol's design goals and message flow, see our full protocol breakdown.

What a server actually exposes

MCP defines a small set of primitives a server can offer, and most servers only use one or two of them in practice:

Almost everything you'll encounter in practice is a tool. A server declares each one with a name, a plain-English description and a schema for its arguments, and the description matters more than it sounds — it's the only thing the model reads to decide when and how to call the tool. That also makes it a real security surface: a badly written, vague or maliciously crafted description can mislead the model into calling a tool it shouldn't, or into treating text inside a tool's output as an instruction rather than data. We cover that failure mode — prompt injection via tool metadata — in our MCP security guide and in more depth in what prompt injection looks like in an MCP tool call.

How an agent actually uses one

The flow has three parts: a host application (a chat client, an IDE, an autonomous agent runtime) embeds an MCP client, which opens a connection to one or more MCP servers. Underneath, every message is JSON-RPC 2.0 — a well-worn, boring wire format on purpose, so nobody has to invent a new one. On connect, the client and server negotiate capabilities (what each side actually supports), then the client asks the server what it can do (tools/list, resources/list). When the model decides a tool is worth calling, the host sends a tools/callrequest with the arguments the model chose, waits for the result, and folds that result back into the model's context as if it were any other piece of retrieved information. Nothing about this requires the server to know it's dealing with an AI at all — it's an ordinary RPC server that happens to have a very talkative, very literal-minded client.

One detail that surprises people building their first server: the model decides whether and whento call a tool, not your code. You write the tool and its description; the host's underlying language model reads the available tool list at inference time and chooses, so a confusing or overlapping set of tool descriptions doesn't just annoy a human developer — it actively degrades the model's ability to pick the right one.

stdio vs remote servers

A server can run two very different ways, and the spec defines a transport for each. A local (stdio) server is a subprocess the host launches on your own machine — it communicates over stdin/stdout, inherits whatever permissions the host process has, and never touches the network unless a tool inside it explicitly does. A remoteserver runs on someone else's infrastructure and is reached over Streamable HTTP (or the older SSE transport), which means it needs its own authentication story the way any hosted API does — typically OAuth 2.1 per the current spec. That distinction changes what you should actually check before connecting one: a local server's risk is mostly about what it can reach on yourmachine, while a remote server's risk is mostly about who else can reach it. We cover the practical difference — and why more than a third of the remote servers Vouchity tracks declare no authentication requirement at all — in remote vs local MCP servers.

A few things people get wrong about MCP servers

"An MCP server is basically a plugin."Not quite — a plugin is usually distributed and sandboxed by a single platform. An MCP server is a standalone process or endpoint that speaks a protocol; any compliant host can use it, and it doesn't run inside the AI application at all.

"MCP replaces REST APIs."It doesn't — most MCP servers are thin wrappers around an existing API, database driver or SDK. MCP standardizes how an agent discovers and calls that functionality, not the underlying service itself. Building one is often less about inventing new capability and more about describing existing capability well; see how to build an MCP serverif you're doing that.

"Only Anthropic's tools can use MCP."MCP is an open specification, not a Claude-only feature — it's implemented by IDEs, other model vendors' assistants, and independent agent frameworks. And as of December 2025, Anthropic donated the protocol's governance to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, specifically so MCP stays a vendor-neutral standard rather than one company's asset. See what is MCP for the protocol-level view, or our glossary for the rest of the terminology.

Where servers come from

Anyone can publish an MCP server. The official MCP community registry is the closest thing to a phone book — a namespaced catalog of published servers with links back to their real package on npm, PyPI or another registry. Being listed there is a baseline of discoverability, not a guarantee of quality: it doesn't check whether a server is maintained, licensed or safe to run. See what is an MCP registry for how that catalog actually works, and how it differs from what Vouchity does with the same underlying data.

Not every server is worth installing

The ecosystem has grown fast, and it shows: of the 320 servers Vouchity currently tracks, the single largest category is Search & web, and 85 servers (27%) currently grade D or F on Vouchity's 0–100 scale — meaning at least one of maintenance, adoption, transparency, security or provenance is seriously lacking. None of that is visible from a GitHub star count, and it isn't checked by the community registry either. That's why every server on Vouchity gets a Trust Score computed from real, cited signals — see how the score works — rather than a vibe or a popularity count.

If you're about to connect a new server to your agent, the fastest way to check it is to search for it in the server registry, scan the highest-rated servers in a category on the category pages or the overall trust leaderboard, or check the flagged listif you already suspect something's off. If you're building an agent that needs to make this call itself, it can query Vouchity's own hosted MCP endpoint — which means an agent can vet a tool before it ever calls it, not after.