What it actually does
A server's job is translation with judgment. On one side sits a real system — a database, a SaaS product, a filesystem, an internal API. On the other sits a model deciding, mid-task, what to do next. The server presents the system as a short list of named tools, each with a description and a parameter schema the model reads, and executes the calls the model makes. The credential for the real system stays on the server; the model never sees it. That position makes the server more than glue: it is where someone decides which capabilities an agent gets, and which it does not.
Where it fits in the protocol
MCP is a client–server conversation. The client lives inside the AI application — Claude Desktop, Claude Code, Cursor, VS Code and others ship one — and may connect to many servers at once. Each server offers up to three things: tools (actions the model may take), resources (content the application can read for context), and prompts (reusable templates). Most servers people install are tool servers, and the ecosystem of them is wide: reference servers for filesystems and databases, vendor-built ones for major SaaS platforms, community ones for nearly everything else.
Local and remote are different animals
A local server runs as a child process of your own client over stdio — it inherits your laptop, your files, and your blast radius, and it suits personal use. A remote server is a network service shared by many people and agents, which makes it infrastructure: it needs authentication, TLS, monitoring, and an owner. The same code can often run either way; the threat model cannot. The migration from one to the other tends to happen by enthusiasm — someone shares a useful server — rather than by decision, and that is exactly when it deserves the decision.
When it becomes your problem
The moment agents depend on a server, it is a process holding real credentials between AI systems and your systems of record. Installing one is a supply-chain decision — it is code that runs with the keys you hand it. Operating several means knowing which run where, holding which credentials, called by which agents. The practical work is laid out in the guides for building a server properly and running servers as infrastructure; the short version is that an MCP server nobody tracks is shadow infrastructure with a credential inside.