# What are the parts of an MCP setup: host, client and server? Source: https://codelifter.com/forum/posts/what-are-the-parts-of-an-mcp-setup-host-client-and-server/ Site: CodeLifter Forum, category MCP and tools Published: 2026-11-07. Updated: 2026-11-10. Replies: 2. ## Question by CodeLifter editors (staff), 2026-11-07 An MCP setup has three parts: the host, the AI app you use (Claude Code, VS Code); one client per server, created by the host to hold that connection; and the server, the program that offers tools, resources and prompts. Around them sit a config file that tells the host which servers to start, and a transport that carries messages. ## Which part runs where? The [MCP architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) (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](/forum/posts/what-is-an-mcp-server-in-plain-terms/) 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](https://code.claude.com/docs/en/mcp) and VS Code's [MCP servers page](https://code.visualstudio.com/docs/agent-customization/mcp-servers). 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](https://modelcontextprotocol.io/docs/learn/client-concepts) 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](/forum/posts/how-do-you-sandbox-the-filesystem-mcp-server/) 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 ` 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](/forum/posts/how-do-you-build-a-simple-mcp-server/). - **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](https://codelifter.com/mcp/) 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. ## Reply 1 by CodeLifter editors (staff), 2026-11-07 **Why does an older MCP server stop working with a newer app?** Usually because the two speak different protocol revisions. The specification's [versioning page](https://modelcontextprotocol.io/specification/latest/basic/versioning) splits versions into "legacy" ones, which open a session with an `initialize` handshake (2025-11-25 and earlier), and "modern" ones, which carry the version, identity and capabilities on every request (2026-07-28 and later). Its compatibility matrix is blunt: a modern-only client talking to a legacy server "Fails", and so does a legacy client talking to a modern-only server. What works is a "dual-era" implementation on either side. A dual-era client probes a stdio server with `server/discover` and falls back to `initialize` if it gets an unrecognised error; over HTTP it inspects the body of a `400 Bad Request` before falling back. If a server you rely on stops connecting after a host update, check which SDK version the server was built with and whether its maintainer has shipped a release for the 2026-07-28 revision. The page also asks modern-only servers to name their supported versions in any error they return to an `initialize` request, so read the server's log output first. ## Reply 2 by CodeLifter editors (staff), 2026-11-10 **Is an MCP server the same as a plugin or an extension?** No. The server is the program that answers MCP requests; a plugin or extension is a way of packaging and installing things, which can include a server. Claude Code's [MCP documentation](https://code.claude.com/docs/en/mcp) says plugins "define MCP servers in `.mcp.json` at the plugin root or inline in `plugin.json`", and that when you enable a plugin, "Claude Code starts its MCP servers automatically". You then add or remove those servers by installing or uninstalling the plugin, not with the `/mcp` commands. Their tools get longer names, in the form `mcp__plugin____`, which matters if you write permission rules against them. VS Code works in a similar way: its [MCP servers page](https://code.visualstudio.com/docs/agent-customization/mcp-servers) lets you install a server from the Extensions view by searching `@mcp`, and agent plugins can carry servers too. Either way, the server inside still runs with your permissions, so check who publishes the plugin before you enable it. --- Cite as: CodeLifter Forum, "What are the parts of an MCP setup: host, client and server?", https://codelifter.com/forum/posts/what-are-the-parts-of-an-mcp-setup-host-client-and-server/, accessed 2026-11-12.