What Is an MCP Server?
An MCP server is a program that sits between an AI agent and one outside capability. The agent does not learn that capability by heart. It asks the server, in a shared format, to do a specific thing — read a file, open a page, look up a repository — and the server returns a result the agent can use on the next step.
MCP is the Model Context Protocol. It is a protocol, not a product and not a Claude feature. Claude is one host that speaks it. The server is the piece that makes a particular tool available to any host that speaks the same protocol. If you only remember one sentence, remember that one.
The plain version
A chatbot answers from what is already in the conversation. An agent is a chatbot that can also act. Acting means calling something outside the model: a filesystem, a browser, a GitHub account, a voice API, an SEO dataset. Without a standard, every one of those connections is a one-off. The model vendor writes a plugin, the tool vendor writes a different plugin, and you install both into one app.
An MCP server is the tool vendor's side of a shared plug. The host (Claude Desktop, Claude Code, Cursor, or another client) already knows how to talk MCP. The server already knows how to talk to one service. You connect them, and the agent gets a new action without a new custom integration for that pair.
The protocol specification is the contract. A server that follows it can be listed, installed, and reasoned about the same way as any other server. That is why a short directory is useful, and why a giant unreviewed dump of servers is not. The contract says how to connect. It does not say the server is safe.
Host, client, and server
Three roles show up in every setup. Mixing them up is how the docs start to sound like jargon.
- Host. The application you are actually using. Claude Desktop and Claude Code are hosts. The host owns the chat, the permissions UI, and the decision to start a server.
- Client. The connector inside the host that speaks MCP to one server. You rarely configure the client by itself. When a host says it "added an MCP server," it started a client pointed at that server.
- Server. The program that exposes the tool. It might be a local process the host launches, or an HTTPS endpoint someone else hosts. The server is not the model, and it is not the chat window.
A useful picture: the host is the workshop, the client is the socket, the server is the machine you plugged in. The model is the person deciding which machine to run. Unplug the server and the model can still talk. It just cannot do that job.
Where the agent ends and the tool begins
The agent is the loop: read the situation, choose an action, observe the result, repeat. The tool is one action on that menu. An MCP server is how a tool gets onto the menu without being baked into the model.
That split matters. The model can be wrong about when to call the tool. The server can be wrong about what the tool does. A GitHub server that can open pull requests will open one if the model asks and the token allows it. The protocol does not add a second opinion. Permission lives in what you connect, which directories or accounts you hand over, and whether the host asks you before the call.
This site already treats tool use as part of how an agent is built, not a last-minute accessory. The tool-use training piece is about how models learn to call tools. An MCP server is the runtime side of the same idea: a stable way for a trained model to reach a real system.
Not the same thing as an API or a plugin
An API is the service's own contract. GitHub's HTTP API, a browser automation library, a text-to-speech API — each has its own URLs, auth, and error shapes. An MCP server usually wraps one of those APIs. It does not replace it. If the upstream API changes, the server has to change too.
A plugin is an install target. It is built for one host's extension system. An MCP server is built for the protocol. The same server can be attached to more than one host, which is the practical difference you feel: you learn the server once, then point Claude, or another client, at it.
So "MCP server" is not a brand of AI, and it is not a synonym for Claude. Claude is a convenient first host because its public docs show both a desktop config file and a claude mcp add command. The entity you are deciding to trust is the server.
What a server actually exposes
Servers advertise capabilities the client can list. In practice you will meet three kinds:
- Tools. Actions with arguments and a result. "Open this URL." "Create this issue." "Read this directory." This is the part an agent loop calls.
- Resources. Data the client can read into context, more like a file the model is allowed to see than a button it can press.
- Prompts. Reusable prompt templates the server offers, so a task starts from a known shape instead of a blank message.
You do not need all three. A beginner server is often just a handful of tools. The safety question is the same either way: what can this process see, and what can it change?
Browser, GitHub, voice, and SEO
The interesting servers are not abstract. They map onto jobs you already recognize. A short, hand-checked list lives at the MCP servers page. Four of the jobs:
- Browser. Microsoft's Playwright MCP server lets a model drive a browser through Playwright's accessibility tree, rather than by looking at screenshots. That is a structured page, not a picture. It can still click and type.
- GitHub. GitHub's official MCP server reads repos, issues, and pull requests, and can change them when the account you connect is allowed to. GitHub also documents a remote endpoint at
https://api.githubcopilot.com/mcp/, with OAuth or a personal access token. - Voice. ElevenLabs publishes a hosted MCP server for speech and audio tools. Their older local server repository is deprecated in favor of the hosted endpoint, which uses OAuth instead of an API key pasted into a config file. The ElevenLabs introduction is the vendor's own page.
- SEO. Ahrefs and DataForSEO both ship MCP servers that sit on top of their paid SEO APIs: rankings, keywords, site data. These are not free public datasets. They are a protocol face on an account you already pay for. Details and the current remote URLs are on the directory page, next to the safety note for each one.
The official reference collection is the modelcontextprotocol/servers repository. The local-server tutorial most people hit first is a filesystem server: the host launches it with npx, and the arguments are the only directories it may touch. That pattern — name the server, name the command, name the narrow scope — is the one to copy before you connect a browser or an account.
Local process or remote URL
A local server is a process on your machine. The host starts it, often with npx or Docker, and talks to it over standard input and output. Nothing about that server is on the network unless the server itself calls out. The risk is local power: the process runs as you, inside the folders and tokens you passed in.
A remote server is a URL. Your host opens it over HTTP. The vendor runs the process. The risk moves: you are sending prompts, file contents, or queries to someone else's machine, and you are attaching whatever credential that server requires. Remote is less install work. It is not automatically safer.
Neither mode is a sandbox by default. The protocol is a language for the call. The boundary is the config: which command, which URL, which paths, which token, which tool groups. Read that boundary on the directory page before you install anything, then follow the Claude setup guide if Claude is the host you have.
FAQ
Is an MCP server the same as an API?
No. An API is how a service already works. An MCP server is a protocol adapter in front of a service, so an agent host can call it without a custom plugin for that one app. The API is still there underneath.
Do I need Claude to use an MCP server?
No. Claude Desktop and Claude Code are hosts with public setup docs, which is why the next article uses them as the walkthrough. Any host that speaks MCP can connect to the same server. The server does not belong to Claude.
Is a local MCP server safer than a remote one?
It is a different risk, not a smaller one. Local means the process runs as you, on the paths you granted. Remote means your requests and credentials go to the operator of that URL. Start with the narrowest scope either way.
What should I look at before I install one?
The one-line description, the official link, and the safety note. That is the whole point of the starter directory. Pick a server that matches a job you already have, confirm the vendor still maintains that install path, and only then add it to a host.
Related: How to use MCP servers with Claude · MCP servers by use case · How AI agents learn to use tools · Are AI agents safe?
Next Steps
Read the short directory before you install a server. If Claude is the host, the setup article stays at the level of the public docs: where the config file is, what a remote URL looks like, and what not to grant on the first day.
Browse the hand-picked MCP servers →Connect a server to Claude →how do AI agents work — return to the complete AI agent architecture guide.
Was this helpful?
Your feedback stays on this page — no tracking.