A Model Context Protocol (MCP) client is the component within an AI application that connects to MCP servers to access external tools, data, and capabilities. It sits between the user-facing host application (like Claude Desktop, Cursor, or a custom AI agent) and the MCP servers that expose those capabilities.
TL;DR An MCP client is the protocol connector a host app creates to manage a 1:1 connection to one MCP server. It negotiates capabilities during initialization, then exchanges JSON Remote Procedure Call (JSON-RPC) 2.0 requests and responses. It invokes server capabilities (tools, resources, prompts) and may support client capabilities (sampling, elicitation, roots). Hosts create multiple clients to connect to multiple servers, which keeps connections isolated and boundaries clear. What Is an MCP Client? An MCP client is a protocol-level connector that handles communication between a host application and an MCP server. It is distinct from the host (the user-facing application) and from the server (the service providing tools or data). The host creates the client, which then discovers what a server offers, sends requests, receives responses, and manages the connection lifecycle.
Each MCP client maintains a strict 1:1 relationship with a single server. When a host application needs to connect to multiple servers, it creates multiple client instances: one per server connection. This isolation ensures clear capability boundaries and independent communication channels for each connection.
Host, Client, and Server — The MCP Architecture MCP implements a three-component architecture with distinct participants. These roles map to different runtime concerns, and mixing them up leads to architectural issues down the line.
Host is the AI application that users interact with directly. Claude Desktop, Cursor, Visual Studio Code, or a custom-built AI agent : the host manages the overall user experience and coordinates one or more MCP clients. It creates client instances, manages their lifecycles, and orchestrates connections to multiple servers simultaneously.Client is the protocol connector the host creates. It handles protocol negotiation, capability discovery, and the request/response cycle. Multiple clients run in parallel within a single host, each isolated from the others.Server is a program that provides context to MCP clients. Servers expose three types of capabilities: tools, resources, prompts. A server runs as a separate process, either locally on the same machine or remotely. You can access it through transport mechanisms like stdio (for local communication) or Hypertext Transfer Protocol (HTTP) with Server-Sent Events (SSE) (for remote communication).In practice, this looks like: a developer using Visual Studio Code (host) connected to a Sentry MCP server and a local filesystem MCP server has two MCP clients running, one for each server connection. Each client independently negotiates capabilities with its server and manages its own communication channel.
How Does an MCP Client Work? MCP clients operate through a structured three-phase lifecycle. Each phase uses JSON-RPC 2.0 as the message format.
The Connection Lifecycle Initialization follows a precise three-step handshake. First, the client sends an initialize request containing its protocol version and the capabilities it supports, such as sampling or elicitation. The server responds with its own capabilities, which include the tools, resources, and prompts it offers. Finally, the client sends an initialized notification confirming the handshake is complete. This negotiation ensures both sides understand what operations are possible before any work begins.
Operation is the main working phase. The client sends requests to the server to invoke tools, read resources, or retrieve prompts. Communication is bidirectional. The server can also request user input through elicitation or large language model (LLM) completions through sampling. Both sides can send notifications, which are asynchronous messages that do not expect a response.
Termination ends the connection cleanly. For local servers using stdio transport, the client sends a SIGTERM signal to the server process. For remote HTTP connections, the client sends an HTTP DELETE request with the session ID to close the session. Either side can initiate termination.
Core Client Capabilities Beyond invoking server-side tools, resources, and prompts, MCP clients can advertise their own capabilities. Servers can only invoke capabilities that clients declare during initialization, creating a mutual capability contract.
Sampling lets servers request language model completions through the client. Instead of calling an LLM directly, a server asks the client to perform the inference. The client controls which model to use, what token limits apply, and what the user sees. A server can delegate AI-powered tasks while the client retains full control over model access and costs. Servers can specify abstract preferences like prioritizing speed over quality, and the client maps those to an appropriate model.
Elicitation allows servers to request specific information from users during an interaction. Instead of requiring all input upfront, a server can pause mid-task to ask for missing details. For example, a server helping book travel might pause to ask for passport details or travel preferences through the client's approval interface.
Elicitation operates in two modes. In form mode, the client collects structured data with defined fields and validation rules. In URL mode, the client directs users to external pages, which is useful for Open Authorization (OAuth) flows or sensitive credential collection. The server initiates the request, the client presents it to the user, the user approves or denies, and the client validates the response before sending it to the server. Every request requires explicit user approval before any data reaches the server.
Roots Roots spec , roots are Uniform Resource Identifier (URI)-based declarations that inform servers about available filesystem locations and access scope limitations. For example, a client might declare two roots pointing at file:///home/user/repos/frontend and file:///home/user/repos/backend. This gives the server awareness of a multi-repository project structure. Roots establish explicit access boundaries that prevent servers from traversing outside designated directories.
Transport Protocols MCP clients communicate with servers through two transport mechanisms : stdio and HTTP. In practice, stdio handles local process communication, and Streamable HTTP with SSE handles remote server communication. The choice depends on whether the server runs on the same machine or a remote host.
stdio (standard I/O) Streamable HTTP Use case Local servers on the same machine Remote or cloud-hosted servers How it works Client launches the server as a subprocess and communicates through stdin/stdout pipes Client sends JSON-RPC messages as HTTP POST requests; server responds with JSON or upgrades to an SSE stream Message format JSON-RPC, newline-delimited JSON-RPC over HTTP POST Network required No Yes Multiple clients Not supported Supported Authentication Not needed (local process) Standard HTTP auth (OAuth, TLS) Infrastructure compatibility N/A (local only) Works with proxies, load balancers, and TLS Key tradeoff No remote access, but avoids network and auth complexity Full distributed support; replaces the deprecated standalone SSE transport per the MCP transport spec
What Is the Difference Between an MCP Client and an MCP Server? The client is the consumer; the server is the provider. The following table summarizes how their responsibilities differ.
Role MCP Client MCP Server Role Consumer — discovers and invokes capabilities Provider — exposes and executes capabilities Where it runs Inside the host application As a separate process (local or remote) Core responsibilities Discovers capabilities, invokes tools, manages credentials Exposes tools and resources, executes operations, returns results Connection scope Scoped to exactly one server (1:1) Can serve connections from one or more clients Who creates it The host application instantiates and manages each client Runs independently; launched by the client (stdio) or hosted remotely (HTTP) Communication direction Initiates the connection; sends requests for tools, resources, and prompts Responds to requests; can also send requests back for sampling and elicitation Capability contract Declares sampling, elicitation, and roots during initialization Declares tools, resources, and prompts during initialization
Unlike traditional client-server models where a single client might fan out to many servers, MCP scopes each client instance to exactly one server. The host application manages multiple client instances to reach multiple servers. During initialization, both sides declare what they support, which establishes a clear contract for the session.
Why Do MCP Clients Matter for AI Agents? MCP clients give AI agents a structured way to access external tools and data without writing per-source integration code. Three aspects determine how much value the client layer adds in production: standardized access patterns, security controls, and the quality of data infrastructure behind each server.
Standardized Data Access Before MCP, every agent-to-tool connection required a bespoke integration. Teams had to handle different application programming interfaces (APIs), authentication flows, and data formats for each external service. Three AI models connecting to five data sources meant fifteen separate integrations. This is an O(n×m) problem that scales poorly.
MCP gives agents a single interface to discover and use tools across any compliant server. Teams learn one JSON-RPC-based protocol instead of mastering proprietary patterns for each data source. When a server adds new capabilities, connected agents can discover them at runtime without code changes.
Security and Control The client layer enforces permissions. Sampling, elicitation, and roots give organizations a single enforcement point for model access controls , user consent, and filesystem boundaries. This applies regardless of which servers are connected. It positions the client as the security and governance gateway between AI agents and external resources.
The Data Infrastructure Behind the Server The value of an MCP client depends on the data infrastructure behind the servers it connects to. An MCP server backed by governed infrastructure with hundreds of connectors gives agents more useful context than a server with a handful of hand-rolled API integrations. The protocol standardizes communication, but the infrastructure determines whether agents get the data they need to avoid hallucinations and produce accurate results.
How Do MCP Clients Fit into Production AI Agent Infrastructure? MCP clients handle capability discovery, communication, and security enforcement through a single protocol interface. That removes the per-source integration burden, but what matters most in production is the data layer behind the servers.
Airbyte's Agent Engine provides the MCP server infrastructure to back that data layer, with 600+ governed connectors already built. The PyAirbyte MCP server lets agents manage data pipelines through natural language, listing available connectors, validating configurations, and running sync operations through any MCP-compatible client.
The Connector Builder MCP supports AI-assisted development of custom connectors when existing sources do not cover your needs. Together, they give MCP clients access to enterprise data with built-in access controls and automatic freshness.
Connect with an Airbyte expert to see how Airbyte's MCP infrastructure powers production AI agents with reliable, governed data access.
You build the agent. We'll bring the data.
Authenticate once. Fetch, search, and write in real-time.
Try Agent Engine →
Frequently Asked Questions How do I start building an MCP client? Use the quickstart repo , which includes complete client implementations in TypeScript and Python. Install the SDK, create a client session, connect to a server, and call initialize() to negotiate capabilities. Then use list_tools() to discover what the server offers.
Is an MCP client the same as the host application? No. The host vs client distinction is core to MCP. The host is the user-facing application, and the client is a protocol-level component the host creates to manage a single server connection.
How many tools can an MCP client expose to an LLM? MCP does not impose a hard tool limit, but LLM performance can degrade beyond approximately 20 tools due to tool selection issues. Design your server architecture accordingly, and prefer multiple specialized servers over one server exposing dozens of tools.
What security risks should I watch for with MCP clients? The MCP protocol does not natively carry user context from host to server, so servers cannot differentiate between users without custom authentication layers. Local servers can execute operating system (OS) commands based on model instructions, so host-system security posture matters. Enterprise deployments should add OAuth or OpenID Connect (OIDC) authentication, audit logging for all tool invocations, and input validation beyond what the protocol assumes.
Can MCP clients connect to remote servers? Yes, using Streamable HTTP. The client sends JSON-RPC messages as HTTP POST requests, and the server responds with either a standard JSON response or upgrades to a Server-Sent Events stream. Standalone SSE transport is deprecated; the specification recommends Streamable HTTP for new implementations.
