MCP, the Model Context Protocol, is an open standard for connecting AI apps to the tools and data they cannot reach on their own: your GitHub issues, a browser, a database, your notes. Someone writes an MCP server for a system once, and any AI app that speaks MCP can use it. Claude, ChatGPT, Cursor, VS Code, Gemini and many others do.
Anthropic announced MCP in November 2024. In December 2025 it moved to the Agentic AI Foundation, a fund under the Linux Foundation, so no single company owns it. This post explains the parts, follows one request from question to answer, and covers why setting a server up looks different in every tool.
Host, client and server
The MCP architecture docs name three participants:
- The host is the AI application you use: Claude Code, Cursor, VS Code, Claude Desktop.
- A client lives inside the host. The host makes one client for each server it connects to, and each client keeps its own connection.
- A server is the program that offers the tools and data. It might run on your computer or on someone else's.
So if your VS Code is connected to a filesystem server and a Sentry server, it has two MCP clients running, one talking to each. You never deal with the client directly. It is the part of the app that speaks the protocol.
Underneath, the messages are JSON-RPC 2.0: small JSON objects with a method name, some parameters and an id to match the reply to the request.
Tools, resources and prompts
A server can offer three kinds of thing. The server concepts page separates them by who decides when they are used:
| What | What it is | Who decides to use it | Example |
|---|---|---|---|
| Tools | Functions that do something | The model | Search issues, click a button, run a query |
| Resources | Read-only data for context | The app | A file, a database schema, API docs |
| Prompts | Ready-made instructions with slots | You | A slash command like /summarise-pr |
Tools are the part most people mean when they talk about MCP. Your agent sees each tool's name, description and input schema, and decides for itself when to call one. Plenty of servers offer nothing else.
One tool call, step by step
Here is what happens between typing a question and getting an answer that used a tool. Switch between a local and a remote server to see what changes.
One tool call
Step 1 of 6AI appMCP serverrun command
The app starts the server
A local server is a program on your computer. The AI app runs the command from your config as a child process and sends messages through its standard input and output. It runs as you, so it can reach whatever you can. Any token it needs comes from environment variables in that config.
npx -y example-notes-mcp@1.2.0Notice two things. The model never talks to the server: the app sits in the middle, which is where approval prompts and permissions live. And the model reads text the server's author wrote, both the tool descriptions and the results. That is why our safety guide asks you to read a server's tool descriptions before you connect it.
Local (stdio) or remote (HTTP)
MCP has two standard ways to carry those messages, called transports:
stdio, for local servers. The AI app starts the server as a program on
your computer, usually with a command like npx some-server or
uvx some-server, and the two talk through the program's standard input and
output. Nothing goes over the network unless the server itself makes a
request. A local server runs with your user account, so it can read what you
can read. If it needs a token, the
authorization spec
says to take it from environment variables, which you set in the app's config.
Streamable HTTP, for remote servers. The server runs on someone else's machine, and the app sends each message as an HTTP request to its URL. One remote server serves many users. When it needs to know who you are, MCP recommends OAuth: the app opens the service's sign-in page in your browser, you approve the access, and the app gets a token. Your password never goes through the AI app, and you can usually revoke the token from the service's settings.
A lot of servers offer both. Context7, for example, has a hosted URL and an npm package that runs locally.
The official MCP registry
The MCP Registry is the project's official list of public servers. It is still marked as a preview. It holds metadata, not code: a server's name, where its package or URL is, and how to start it. The code stays on npm, PyPI, Docker Hub or the server's own host.
What it does well is names. A server called io.github.microsoft/playwright-mcp
can only be published by whoever controls the microsoft GitHub account, and a
com.example/... name needs control of that domain. So a listing tells you
who published a server.
What it does not do is check the code. The registry says security scanning is left to the package registries and to the directories built on top of it. It is also mostly meant for those directories and for apps to read through an API, rather than for people to browse.
Why every tool configures it differently
The protocol describes how a client and a server talk once they are connected. It does not say where an app keeps its list of servers, so each app chose its own file and format. Here is the same local server, the reference filesystem server with access to one folder, in three of them.
Cursor, in ~/.cursor/mcp.json
(docs):
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem@2026.8.31", "/path/to/project"]
}
}
}VS Code, in .vscode/mcp.json
(docs).
The top-level key is servers, and each server says its type:
{
"servers": {
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem@2026.8.31", "/path/to/project"]
}
}
}Codex, in ~/.codex/config.toml
(docs), which is TOML
rather than JSON:
[mcp_servers.filesystem]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem@2026.8.31", "/path/to/project"]Claude Code has a command for it
(docs) and also reads a .mcp.json
file in the project that uses mcpServers, like Cursor. Gemini CLI keeps its
servers in ~/.gemini/settings.json
(docs).
The server is the same program in every case. Only the wrapping changes. Every server page in our MCP servers list generates the right snippet for each of these tools, pinned to the version we reviewed, so you do not have to translate by hand.
Three servers to start with
These are from our reviewed list, and none of them needs an account:
- Filesystem, the MCP project's reference server. Reads and writes files, limited to the folders you name. A good first server for learning how MCP works, especially in Claude Desktop.
- Playwright, by Microsoft. Your agent drives a real browser: opens pages, clicks, fills in forms and reads each page's structure.
- Context7, by Upstash. Looks up current documentation for the library versions you use, so your agent stops guessing at APIs. Works as a remote URL or a local package.
An MCP server gives your agent access. It does not teach the agent your way of using that access, which is what agent skills are for. For how the two fit together, and where subagents come in, read skills vs MCP servers vs subagents.
Sources
All checked on 27 September 2026. The protocol pages describe version 2026-07-28.
- Model Context Protocol, Architecture overview and Understanding MCP servers
- Model Context Protocol, Authorization
- Model Context Protocol, The MCP Registry
- Anthropic, Introducing the Model Context Protocol (November 2024)
- MCP blog, MCP joins the Agentic AI Foundation (December 2025)
- MCP config docs for Claude Code, Codex, Cursor, VS Code and Gemini CLI

