What are the parts of an MCP setup: host, client and server?

Which part runs where?

The MCP architecture overview (read on 16 October 2026, protocol version 2026-07-28) defines the host as "the AI application that coordinates and manages one or multiple MCP clients", the client as "a component that maintains a connection to an MCP server", and the server as "a program that provides context to MCP clients". The plain terms thread covers what a server exposes. This thread is about how the parts fit together on your machine.

Part	Where it runs	What it decides	You touch it through
Host	On your machine (or the vendor's cloud for web sessions)	Which servers start, which tools the model sees, whether a call needs your approval	The app's settings and its MCP config file
Client	Inside the host process, one per server	Nothing on its own; it carries requests and results for one connection	Nothing directly
Server, local	A separate process the host starts with a command	What its tools do and what they can reach	The command and args in the config file
Server, remote	Someone else's machine, at a URL	The same, plus its own sign-in rules	The url and headers in the config file
Model	The provider's servers, or locally	Which tool to call and with what arguments	Your prompt

The model is in the table on purpose. It is not an MCP participant. The architecture page says MCP "does not dictate how AI applications use LLMs". The host shows the model a list of tools, the model asks for a call, and the host routes that call through the right client to the right server.

Where does the configuration live?

The config file is the part you actually edit. Each host keeps its own, and the formats are close but not identical. As of the docs read on 16 October 2026:

Host	File	Top-level key	Shared through git?
Claude Code, project scope	.mcp.json in the project root	mcpServers	Yes
Claude Code, local or user scope	~/.claude.json	mcpServers	No
VS Code, portable	.mcp.json at the workspace root	mcpServers	Yes
VS Code, VS Code only	.vscode/mcp.json	servers	Yes
VS Code and other Copilot tools, user	~/.copilot/mcp-config.json	mcpServers	No

Sources: Claude Code's MCP page and VS Code's MCP servers page. The servers versus mcpServers difference is the usual reason a config copied from one tool does nothing in another.

What happens between starting the host and the first tool call?

Here is the sequence for a local server, from the architecture page and the two host docs:

1. The host reads its config. It finds an entry such as "command": "npx", "args": ["-y", "@microsoft/mcp-server-playwright"].
2. The host checks trust. Claude Code "prompts for approval in interactive sessions before using project-scoped servers from .mcp.json files". In VS Code, workspace servers inherit Workspace Trust, and in restricted mode they do not start.
3. The host starts the server and creates a client. For a local server that means a child process talking over stdio, standard input and output. A remote server is reached over Streamable HTTP instead.
4. The client discovers the server. Under the 2026-07-28 revision there is no handshake: every request carries the protocol version and the client's capabilities in a _meta field, and the client may first send server/discover to learn the server's versions and capabilities.
5. The client lists tools. A tools/list request returns each tool's name, description and inputSchema. The host merges the lists from every server into one set the model can choose from.
6. The model asks for a tool. The host intercepts the request, may ask you to approve it, sends tools/call through that server's client, and puts the result back into the conversation.

What does the client offer the server?

Most traffic flows from server to host, but the client side has features too. The client concepts page lists elicitation, where a server asks the user for input through the host, and roots, where the client tells a server which folders it should work in. Read the roots section carefully: roots "do not enforce security restrictions. Actual security must be enforced at the operating system level". A server that ignores them can still read anything its process can. The Filesystem sandbox thread shows the enforcement that does work for one server, and VS Code offers "sandboxEnabled": true per server on macOS and Linux.

Which part should you blame when something breaks?

• Server missing from the tool list: a host problem. Check the file name and the top-level key, then the trust prompt. In Claude Code, claude mcp get <name> shows a status such as "Pending approval".
• Server listed but its tools fail: a server problem. Run it alone in the MCP Inspector, as described in the build a simple MCP server thread.
• Tools work but the model never picks them: a description problem. The model only sees the name, description and schema.
• Works in one app, not another: compare the two config formats above before anything else.

The CodeLifter MCP directory gives the install line for each listed server in the format its maker documents.

Short version

• The host is the app; it creates one client per server and decides what the model sees and what needs approval.
• A local server is a process the host starts; a remote server is a URL.
• Each host has its own config file, and the top-level key differs (servers or mcpServers).
• Roots tell a server where to work; they do not stop it from going elsewhere.