What Is an MCP Client? How Hosts, Clients and Servers Fit

What is an MCP client?

An MCP client is the piece of software inside an AI application that opens and holds one connection to one MCP server. The application, called the host, creates a separate client for every server it talks to. Claude Desktop, Cursor and VS Code are hosts; the client is the component doing the protocol work underneath.

An MCP client is a component instantiated by a host application, such as Claude Desktop or Cursor, to communicate with one specific MCP server over the Model Context Protocol. It sends requests for that server's tools, resources and prompts, and it exposes features back to the server, such as elicitation, so a tool can ask the person using it for missing information mid-task.

The three participants

The Model Context Protocol, introduced by Anthropic in November 2024 and now maintained under the Agentic AI Foundation, a directed fund under the Linux Foundation that Anthropic set up with Block and OpenAI in December 2025, distinguishes three roles:

• MCP host: the AI application a person interacts with. Examples include Claude, Claude Code, Cursor, VS Code and ChatGPT.
• MCP client: a component the host creates, one per server. It maintains the connection, sends requests and manages the session.
• MCP server: a program that exposes tools, resources and prompts to clients.

According to the official MCP architecture documentation, local MCP servers that use the STDIO transport typically serve a single client, while remote servers on Streamable HTTP typically serve many clients at once. When VS Code connects to the Sentry MCP server and then separately to a local filesystem server, it instantiates two distinct client objects, one per connection.

How an MCP client works

MCP splits into two layers. The data layer is a JSON-RPC based protocol that covers capability discovery, versioning, and the core primitives: tools, resources, prompts and notifications. The transport layer defines how bytes actually move, whether over STDIO on the same machine or over Streamable HTTP across the network, including authorization.

A client's day-to-day job runs through a small set of message types. It sends a ListToolsRequest to ask a server what it can do and gets back a ListToolsResult. When the host's model decides to use one of those tools, the client sends a CallToolRequest with the arguments and receives a CallToolResult with the outcome. The client sits between the host's model and the server's actual work, translating decisions into protocol calls and results back into something the model can read.

Clients also expose features that let servers ask for more than they were given upfront. The current protocol version, 2026-07-28, documents three:

• Elicitation: a server can pause a request and ask the user for specific input through the client. It has two modes. Form mode has the client build a UI from a JSON schema the server supplies and return the filled-in values. URL mode instead gives the user a link to open, so the exchange (a credential entry or third-party OAuth step, for instance) never passes through the client at all. Elicitation follows the Multi Round-Trip Requests pattern: the server responds to the original call with an InputRequiredResult, the client collects the input, and it retries the original request carrying the answers.
• Roots: lets a client tell a server which directories to focus on. Deprecated as of protocol version 2026-07-28.
• Sampling: lets a server ask the client to run an LLM completion on its behalf, keeping permission and safety checks under the client's control. Also deprecated as of 2026-07-28.

Examples

Local, one server, one client. Claude Desktop's filesystem quickstart has a person edit a JSON config file naming the @modelcontextprotocol/server-filesystem package and the directories it may touch. Claude Desktop then launches that server over STDIO and creates one client to talk to it. Every file read, write or move still needs the user's explicit approval in the app, one action at a time.

Remote, custom connector. Claude's remote-server flow works differently: a person adds a Custom Connector by pasting a server URL such as https://example-server.modelcontextprotocol.io/mcp into Settings, completes whatever authentication the server needs (commonly OAuth or an API key), and Claude then lists that server's resources and prompts under the message composer's attachment menu, with tool permissions configurable per connector.

Editor client with its own transport rules. Cursor's MCP documentation lists three transports it supports: stdio for a locally-run, single-user server started with a shell command; SSE; and Streamable HTTP, both for local or remote multi-user servers reached by URL with OAuth. Cursor's protocol support table marks tools, prompts, resources, roots, elicitation and the MCP Apps extension all as supported, and it also accepts static OAuth client credentials in mcp.json for providers, such as Figma or Linear, that require a fixed client ID or a whitelisted redirect URL instead of dynamic client registration.

When you need to think about the client (and when you don't)

If you are building an MCP server, you mostly do not write client code: you implement the server side of the spec and let existing clients connect to it. You do need to know what the clients you are targeting actually support, because support is uneven. MCPJam's client directory, last reviewed 2026-07-08, tracks 16 clients and finds that only 9 of them (ChatGPT, Claude, Copilot, Cursor, Goose, MCPJam, Mistral, Slackbot and VS Code) render MCP Apps' interactive UI at all; the rest, including Claude Code, Cline, Codex, Amazon Bedrock AgentCore, n8n, Notion and Perplexity, will still call your tools and read your resources but will draw nothing for a UI-based tool. A server whose value lives in that UI shows those users nothing, so if your tool depends on MCP Apps you have to check the specific client, not assume parity across the ecosystem.

If you are building a client yourself, in most cases you should not start from the wire protocol. The official SDKs for TypeScript, Python, C#, Go and Rust hold Tier 1 status (complete protocol implementation, comprehensive documentation, a two business day issue-triage commitment), with Java and Ruby at Tier 2 and Swift, PHP and Kotlin at Tier 3. All of them implement both server and client creation, so picking one by language and following its client quickstart is faster and less error-prone than implementing the JSON-RPC exchange from scratch.

What's new (as of 19 September 2026)

Protocol version 2026-07-28 is the current release referenced throughout the official documentation. Under this version, Roots and Sampling are both marked deprecated, while Elicitation has been extended with a URL mode alongside its original form mode, specifically so sensitive flows like OAuth authorization or credential entry can happen out of band from the client. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund it co-founded with Block and OpenAI, moving governance of the spec outside a single vendor. MCPJam's client capability catalog, reviewed 2026-07-08, is the most current public accounting of which of the 16 clients it tracks render MCP Apps' UI (9 of 16) versus which only call tools and read resources.

Developers comparing MCP servers or planning which ones to install can browse the MCP servers directory on AI Agents Listing, and hosts such as Cursor, Claude Code and Goose each have their own listing there too.

Key takeaways

• An MCP client is a per-server component that a host application, such as Claude or Cursor, creates to communicate with one MCP server; a host with three server connections runs three separate clients.
• The data layer (JSON-RPC, tools, resources, prompts, notifications) and the transport layer (STDIO or Streamable HTTP, including auth) are the two layers the protocol defines.
• Roots and Sampling are deprecated as of protocol version 2026-07-28; Elicitation remains active and now supports a URL mode for sensitive flows in addition to its original form mode.
• Only 9 of the 16 clients MCPJam tracks (as of its 2026-07-08 review) render MCP Apps' interactive UI; the rest still call tools but show no app UI.
• Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund, in December 2025, moving its governance beyond a single company.

FAQ

What is the difference between an MCP client and an MCP host?

The host is the application a person actually uses, such as Claude Desktop or Cursor; it manages the overall experience and can coordinate several server connections at once. The client is the protocol-level component the host creates to maintain one specific connection to one specific server. A host with multiple server connections runs multiple clients internally.

Do I need to write client code to build an MCP server?

No. Existing hosts already contain clients that can connect to any spec-compliant server. Building a server means implementing the server side of the protocol (exposing tools, resources and prompts) and testing it against real clients, which is what tools like the MCP Inspector and MCPJam's testing tools are for.

Which MCP clients support MCP Apps' interactive UI?

According to MCPJam's client directory, reviewed 2026-07-08, 9 of the 16 clients it tracks render MCP Apps: ChatGPT, Claude, Copilot, Cursor, Goose, MCPJam, Mistral, Slackbot and VS Code. The other 7, including Claude Code, Cline and Codex, can still call tools and read resources but will not draw an app's UI.

What happened to Roots and Sampling in MCP?

Both are marked deprecated as of protocol version 2026-07-28 in the official specification. Elicitation, the third core client feature, is still active and was extended with a URL mode so sensitive exchanges like OAuth logins can happen outside the client entirely.