What is an MCP server? A practical guide
The plain-English version: what an MCP server is, why it exists, and how to go from 'never used one' to a working setup — with the trade-offs nobody mentions.
MCP (Model Context Protocol) is the standard that lets an AI assistant do things — query your database, read your repo, call an API — instead of only writing text about them. An MCP server is the small program that exposes those actions as tools. This is the practical guide: what they are, why they exist, and how to start, grounded in the real data behind 300 servers.
What an MCP server actually is
An MCP server is a process that advertises a set of tools — functions with a name, inputs, and a description — over a standard protocol. Your AI client (Claude Desktop, Cursor, Windsurf) connects to it and can now call those tools. A Postgres server exposes execute_query; a GitHub server exposes create_issue and search_code; a browser server exposes navigate and click. You can see this concretely on any server page — the real tool list is right there.
The protocol is the whole point. Before MCP, every tool integration was bespoke glue. MCP standardises the handshake, so any compliant client can talk to any compliant server. That portability is why a directory of servers is useful at all: one config works across clients.
Why use MCP instead of just calling an API?
This is the question worth answering honestly. MCP doesn't replace APIs — servers usually wrap one. What it gives you is a uniform tool layer the model can discover and call on its own, plus, for local servers, access to things an API can't reach: your filesystem, your already-authenticated CLIs, your local database. You're not pasting data back and forth; the agent acts directly. The cost is a new moving part to install and trust — which is the rest of this guide.
Local vs remote servers
About 90% of servers run locally over stdio (npx, uvx, docker); the rest are remote HTTP/SSE endpoints. Local-first isn't legacy — a local server sees your machine and sends nothing to a third party, which is often exactly what you want. Remote wins when you need to share a setup across a team or offload heavy infrastructure. The full argument is in Local or remote MCP?, and you can browse each set directly: local servers, remote servers.
Finding the right server: by capability, not just by name
Most directories organise by product. The more useful question is usually "which server can do the thing I need?" — so you can browse by capability: execute SQL, automate a browser, search the web. For a specific client, the Claude, Cursor and Windsurf pages list what works there.
Official vs community
A lot of "official-looking" servers are third-party wrappers. We use a strict bar: a server is official only if the repo belongs to the vendor whose product it wraps. Official servers win on auth and maintenance, not raw capability — a focused community server is often just as good. The point is to know which is which before you wire it up.
What actually goes wrong: security and tool budget
Two things bite people. First, security: a tool that runs arbitrary SQL or shell in your name is the real risk, not the protocol. Prefer read-only defaults and narrow scopes. Second, the tool budget: clients like Cursor degrade past ~40 active tools, and the average server exposes ~12 — so you hit the wall around four servers, not fifty.
Start here
- Find a server — by capability or by client.
- Copy its config — every server page ships a one-paste block for Claude, Cursor and Windsurf, or build a multi-server config.
- Paste and restart — the exact steps per client are in How to add an MCP server.
New to the ecosystem and want the lay of the land in numbers? The State of MCP report has the full breakdown.