What is MCP (Model Context Protocol)?

The problem it solves

Before MCP, every AI application that wanted to read a file, query a database or call an API wrote its own integration for each one. Every framework reinvented the same connectors, with its own auth flow and its own way of describing what a tool does. MCP standardises that wire format so a connector — an MCP server — built once works with any compliant AI application.

Three roles, one protocol

• Host— the AI application itself: a chat client, an IDE, or an autonomous agent runtime. It decides which servers to connect to and shows the user (or the model) what's available.
• Client — the piece embedded in the host that speaks MCP to a specific server, managing the connection and message exchange.
• Server— the program that actually exposes tools, data or prompts. It usually has no idea it's talking to an AI; it just receives calls that look like ordinary RPC requests.

Three primitives a server can expose

• Tools — callable functions the model can invoke (the primitive behind almost every server, e.g. search_issues, run_query).
• Resources — read-only data the host can attach to context, like a file or a schema.
• Prompts — reusable prompt templates a server suggests for its own tools.

A tool's name, description and argument schema are the only things the model ever reads to decide when and how to call it — which is also why a badly written (or deliberately manipulative) description is a real risk, not just a quality issue. See our MCP security guide.

Local (stdio) vs remote servers

A server can run as a local subprocess the host launches on your own machine, communicating over stdin/stdout with no network involved — or as a remote service reached over HTTP (streamable HTTP or SSE), which needs its own authentication story the way any hosted API does. The trust questions differ for each; we cover them in remote vs local MCP servers.

Where servers come from

Anyone can publish an MCP server. The official MCP community registry (registry.modelcontextprotocol.io) is the closest thing to a phone book: a namespaced catalogue of published servers linking back to their real package on npm, PyPI or another registry. Being listed there is a baseline of discoverability — it says nothing about whether a server is maintained, licensed or safe to run.

Why trust is a separate question from capability

Vouchity tracks 320 published MCP servers today, and the honest picture is uneven: some are actively maintained by identifiable publishers with clear licenses, and a meaningful share are unmaintained, unlicensed, or vague about what permissions they actually need. None of that is visible from a star count. Every server on Vouchity gets a Trust Score computed from real, cited signals — see how the score works — so you can tell the two categories apart before you connect anything.