MCP Client
What is an MCP client?
An MCP client is the protocol component an AI application uses to communicate with an [MCP server](/glossary/mcp-server/). In the MCP architecture, the AI application is often called the host. The host creates a separate client for each server connection.
The client handles MCP communication. The host remains responsible for the broader product experience, including model access, conversation state, user interface, and decisions about how server-provided capabilities are presented or used.
How it works
The client establishes communication over an [MCP transport](/glossary/mcp-transport/) supported by both sides. It sends requests, receives responses and notifications, and tracks the protocol information needed for that server relationship.
Through the client, the host can discover and use features such as:
- tools exposed for model-directed actions;
- resources that provide contextual data;
- prompt templates available for selection;
- supported protocol capabilities and change notifications.
An SDK may hide much of this plumbing, but the architectural role is still useful: the client is the MCP-speaking component on the application side of the connection.
Simple example
A desktop coding assistant connects to two MCP servers: one for a local repository and one for an issue tracker. The host creates two MCP clients. Each client communicates with its corresponding server, while the host decides which capabilities to show to the model and user.
If the repository connection closes, that does not inherently describe the state of the issue-tracker connection. They are separate client-server relationships.
MCP client versus host
The host is the complete AI application. An MCP client is one internal protocol participant created by that host. Calling the entire application “the MCP client” can be convenient in casual discussion, but it hides the one-client-per-server connection model.
The client also does not decide by itself that every resource belongs in the context or that every tool call should run. Those are application policies, often combined with model decisions, permissions, and user approval.
Why it matters
Separating host and client responsibilities makes MCP systems easier to reason about. Connection handling belongs to the client; product behavior and safety policy belong to the host and surrounding application.
For builders, this distinction clarifies where to implement capability discovery, connection errors, permission prompts, server isolation, and context selection.