In this guide
  1. Local or remote — where it actually runs
  2. What's actually inside one
  3. Use an existing one, or build your own?

MCP Server

An MCP server is a real, running program: one specific implementation of the MCP protocol, not the protocol itself. This page is about that concrete thing — what it actually looks like to run one or connect to one.

Local or remote — where it actually runs

A local server runs on your own machine. The host launches it as a subprocess and talks to it over standard input and output, so nothing leaves your computer. The official filesystem reference server is a good example: point it at a directory, and it can read and write files there — a fully local round trip.

A remote server runs on someone else's infrastructure and is reached over the network instead, usually behind some form of authentication. GitHub's own MCP server is a real example. It's hosted at a public endpoint and exposes tools for issues, pull requests, and CI/CD runs, acting directly on your GitHub account rather than anything on your machine.

What's actually inside one

A server author writes a handler — the actual code that runs when that specific tool, resource, or prompt gets called — for each one it offers, and gives each tool the same kind of schema any tool call needs. When a client connects, the server reports back whatever it currently supports. A server can announce when its tools change. A client built to listen for that picks up a newly added tool without reconnecting. Not every client listens for it, though, so a plain reconnect is the reliable fallback.

Use an existing one, or build your own?

Reach for an existing server whenever one already covers the system you need: GitHub's own server if the job involves GitHub, the reference filesystem server for local file access. An MCP Registry exists specifically for browsing servers other people have already published. Build your own when the system is something nobody else could plausibly publish a server for, like your own internal database or internal API. It's also worth building your own when you'd rather expose a narrow, hand-picked set of capabilities than trust a third party's server with broader access than the task needs. Building one isn't free, though: it's code you now own, host, and have to keep secure. Skip it whenever an existing server already does the job well enough.

A server you didn't write is code you're choosing to run and data you're choosing to trust, whether or not it happens to be official. That's the same caution the MCP page covers for connecting to any server at all.

Practice interview questions on MCP servers →