MCP discussions usually focus on servers. That makes sense: servers expose the tools, resources, and prompts that agents use. But every server connection depends on a client.

An MCP client is the protocol component that talks to one MCP server. It lives inside a host application, such as Claude Desktop, Claude Code, Cursor, VS Code, or a custom agent runtime. The host is the app the user sees. The client is the piece inside that app that opens the MCP connection, negotiates capabilities, sends JSON-RPC messages, and returns server results to the model.

That distinction sounds small until you start building. Most production hosts run many MCP clients at once. One client might connect to a local filesystem server over stdio. Another might connect to a remote search server over Streamable HTTP. The host coordinates the overall agent experience, but each client manages one server relationship.

The core idea

An MCP client is the connector between an AI host and an MCP server. It handles the protocol details so the host can treat external capabilities as part of the agent’s working environment.

The client is responsible for:

  • Starting or connecting to a server
  • Sending the initialize request
  • Reading the server’s declared capabilities
  • Listing tools, resources, and prompts
  • Calling tools when the model requests them
  • Enforcing user approval and host policy
  • Returning results back into the conversation

In plain English: the server says what it can do, the model decides what it wants to use, and the client makes the actual protocol call.

The client is not the model. It is not the whole app. It is not the server. It is the control layer that makes a specific server usable inside an agent workflow.

Host vs. client vs. server

The easiest way to understand MCP architecture is to separate the three roles.

The host is the application the user interacts with. Claude Desktop, an IDE, or an internal support agent can all be hosts. The host manages chat, permissions, model selection, UI, user identity, and the set of configured servers.

The client is created by the host for a particular server connection. If a host connects to five MCP servers, it usually has five MCP clients. Each client tracks its own transport, session, capabilities, and request lifecycle.

The server exposes capability. It may wrap a SaaS API, a database, a local command line tool, a file system, or a purpose-built service. The server does not own the full user experience. It responds to protocol requests from the client.

This split is why MCP scales better than one-off integrations. A host can add new servers without custom UI work for each one. A server can support many hosts without writing separate plugins for every app.

How an MCP client works

A typical connection starts with configuration. For a local server, the host may know a command to run:

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/alex/project"]
}

For a remote server, the host may know a URL and auth configuration:

{
  "url": "https://api.example.com/mcp",
  "transport": "streamable-http"
}

Once the connection is open, the client sends initialize. The server replies with its protocol version and capabilities. After that, the client can ask what the server offers:

{"jsonrpc": "2.0", "method": "tools/list", "id": 1}

The server responds with tool definitions, including names, descriptions, and input schemas. The host can then show those capabilities to the model. When the model chooses a tool, the client sends tools/call with validated arguments and returns the result.

The same pattern applies to resources and prompts. The client lists what exists, reads or invokes the selected item, and keeps the protocol boundary clean.

Why clients matter for safety

MCP clients sit exactly where safety decisions need to happen. The model may request a tool call, but the client and host decide whether that call is allowed.

That matters because tools can do real work. Reading a file is different from deleting one. Querying a database is different from updating a row. Posting a Slack message is different from drafting one. A good host uses client-side policy to decide which actions are automatic, which require approval, and which are blocked.

This is also where server trust shows up. A client can display the server name, requested method, tool description, arguments, and expected effect before asking the user to approve. It can apply stricter treatment to tools marked as destructive, or auto-approve read-only tools from trusted servers.

The protocol does not magically make unsafe servers safe. It gives host applications a standard place to inspect requests and build permission systems around them.

Client-provided features

Servers do not only provide capabilities to clients. In some cases, clients provide capabilities back to servers.

Elicitation lets a server ask the client to collect specific information from the user. A travel server, for example, might need a seat preference or final booking confirmation before completing a tool call. The client presents the request, validates the response, and sends it back through the protocol.

Roots were used to tell servers which filesystem directories were in scope. As of the 2026-07-28 MCP specification, roots are deprecated and scheduled for removal. New implementations should pass files, directories, resource URIs, or configuration more directly instead.

Sampling allowed servers to request LLM completions through the client. It was useful for servers that needed model reasoning but did not want to call a model API directly. Sampling is also deprecated as of the 2026-07-28 specification. New implementations should usually integrate with model provider APIs directly.

For developers, the practical point is simple: client capabilities are part of compatibility. A server that depends on elicitation, auth behavior, or a specific transport needs a host client that supports it.

What to check when choosing an MCP client

If you are choosing a host or building your own MCP client, look at four things.

First, transport support. Local workflows usually need stdio. Remote workflows should support Streamable HTTP. Older SSE-only servers may still exist, but new remote implementations should move toward Streamable HTTP.

Second, permission controls. The client should make it clear what a tool is about to do before it runs. For team environments, policy needs to be configurable instead of buried in a one-time prompt.

Third, capability coverage. Basic tools are table stakes. Resources, prompts, elicitation, OAuth, and modern protocol version negotiation matter as workflows get more serious.

Fourth, debugging. Developers need to see raw requests, server errors, initialization failures, and schema problems. If the client hides all of that, MCP feels flaky even when the server is the real problem.

FAQ

Q: Is Claude Desktop an MCP client? A: Claude Desktop is an MCP host. It creates MCP clients internally to connect to configured servers. People often use “client” casually to mean the app, but the protocol distinction is host application versus per-server client connection.

Q: Can one MCP client connect to multiple servers? A: In the formal architecture, a client manages one server connection. A host application can create multiple clients, one for each server, and then combine the capabilities in a single agent experience.

Q: Do I need to build an MCP client to build with MCP? A: Usually no. If you are exposing tools or data, build an MCP server and connect it to an existing host. Build a client only if you are creating your own agent runtime, IDE integration, testing tool, or custom host application.

Q: What is the difference between an MCP client and an MCP server? A: The client initiates and manages the connection from the host side. The server exposes capabilities. The client asks what the server can do, sends requests, applies host policy, and passes results back to the model.