What is an MCP server?

An MCP server is a program that exposes one product's data and actions to AI assistants through the Model Context Protocol — an open standard, so a single server built for Notion or GitHub works in Claude, Cursor, ChatGPT and every other compatible client.

Think of it as an adapter. The product already has an API meant for developers; the MCP server re-presents that API in a form an AI model can discover and call on its own. The assistant asks the server what it can do, gets back a typed menu, and picks from it mid-conversation — no bespoke integration per app. This page covers the server side; for the protocol itself and why it exists, start with What is MCP?

What a server actually provides

A server exposes up to three kinds of capability, and clients discover all of them by asking:

The architecture, in one diagram

MCP has three roles. A host is the AI app you actually use. Inside it, the host runs one client per connection, and each client talks to exactly one server:

┌─────────────── host (Claude, Cursor, VS Code…) ───────────────┐
│                                                               │
│   MCP client ──── MCP client ──── MCP client                  │
└───────│──────────────│───────────────│───────────────────────┘
        │ stdio        │ HTTP          │ HTTP
        ▼              ▼               ▼
  local server    mcp.notion.com   api.githubcopilot.com/mcp
  (your machine)  (Notion's cloud) (GitHub's cloud)

Under the hood every message is JSON-RPC 2.0. The conversation follows a fixed shape: the client connects and the two sides negotiate versions and capabilities; the client asks tools/list and gets the menu; when the model wants something done, the client sends tools/call with arguments, and the result flows back into the model's context. Two transports carry it: stdio for servers running as a subprocess on your machine, and streamable HTTP for servers at a URL.

Local vs remote vs in-product

Where the server runs decides how you install it — and who holds your credentials:

Remote is the least friction and keeps credentials with the vendor. Local gives you full control — keys never leave your machine — but the code you run can reach your filesystem, so its provenance matters. In-product servers ride along with software you already trust.

Official vs community — and why it matters

Anyone can write an MCP server for anyone's product, so most products have several. An official server is built and maintained by the company behind the product: it tracks their API changes and passes through their security review. A community server does the same job unofficially — often well, sometimes abandoned, always unaudited by the vendor. Since a server holds your credentials and sees your data, that difference is the first thing worth knowing about any server you're about to connect. It's the one question every verdict on this site answers, with the evidence attached.

How to check whether a product has one

1. Look it up here. We track 234 brands — 212 with official servers, 22 with community-only ones. Hit ⌘K or browse the full list. Each verdict links the vendor's own docs, endpoint or repository.
2. Check the vendor's docs directly. Search their documentation for "MCP" — remote servers in particular never show up on GitHub, which is why star-counting directories miss them.
3. No server yet? The brand's page here says so plainly, and lists the closest community options if any exist.

Common questions