In short
An MCP client is the component of an AI application that maintains the connection to exactly one MCP server via the Model Context Protocol (MCP). It retrieves the server's capabilities, passes on the language model's tool calls and inserts the results into the model context. The client lives in the host, the application in which the model runs, such as Claude Desktop, ChatGPT or Cursor.
What an MCP client is and where it sits
The Model Context Protocol describes how language models access external tools, data and templates in a standardised way. For this, the protocol defines three roles: host, client and server. The MCP client is the link between them. It sits neither with the model nor with the data system but in between, inside the host application.
Important for understanding it: a host creates a separate MCP client for each server connection. If you connect Claude Desktop to a file system server, a Git server and a Shopware server, three clients run in parallel inside it. Each client talks exclusively to its one server. This 1:1 relationship is not an implementation detail but part of the protocol's architecture.
Host, client and server at a glance
| Role | What it is | Typical tasks | Examples |
|---|---|---|---|
| MCP host | The application in which the language model runs and with which the user interacts | Orchestrate the model, create and manage clients, provide the user interface, obtain approvals | Claude Desktop, ChatGPT, Cursor, your own AI agent |
| MCP client | A protocol instance in the host that maintains exactly one connection to a server | Retrieve capabilities, pass on tool calls, insert results into the context, manage the transport | One client instance per server connection, created via an SDK |
| MCP server | A program that provides tools, resources and prompts via MCP | Answer requests, encapsulate systems, secure access | Shopware 6 (/api/_mcp), HubSpot remote MCP server, file system server |
Why separating host and client makes sense
At first glance the separation between host and client seems cumbersome. In practice it ensures that connections remain cleanly isolated. Each MCP client only knows the capabilities of its own server and has no insight into other connections. The host decides which tools are offered to the model at all and when a user has to approve an action.
For you as a developer this means: as a rule you do not build a client from scratch. You use a host that already comes with clients, or you use an SDK that encapsulates the client logic. The official tier 1 SDKs are available for TypeScript, Python, Go and C#. The TypeScript and Python packages have each been downloaded more than a billion times.
What an MCP client actually does
The work of an MCP client can be reduced to a few core tasks. It establishes the connection to the server, asks for its capabilities, passes on the model's calls and delivers the answers back into the model context. On top of this come approvals by the user and a check of the tool descriptions before they reach the model at all.
Retrieving capabilities and passing on tool calls
Communication runs via JSON-RPC 2.0. A client uses tools/list to ask which tools a server offers. The response contains the name, description and a JSON schema for the input parameters of each tool. The host passes this information on to the model so that it can decide which tool suits a task.
If the model decides on a tool, it formulates a call. The MCP client packages it as a tools/call request, sends it to the server and waits for the result. A simplified example of such a request looks like this:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "product_search",
"arguments": { "query": "carbon road bike", "limit": 5 }
}
}The client inserts the server's result into the model's context. Only then can the model answer on the basis of real data instead of guessing. This cycle of request, call and return is the heart of every MCP integration.
The three primitives: tools, resources, prompts
An MCP server provides three types of capabilities, which the protocol calls primitives. For the client, what matters is who controls their use in each case:
- Tools are model-controlled. The language model itself decides whether and when to call a tool, such as a product search or creating an order.
- Resources are application-controlled. The host or client decides which data sources, files or records are provided to the model as context.
- Prompts are user-controlled. They are prepared templates that a user selects explicitly, for example via a slash command in the interface.
This division helps you distribute responsibilities cleanly. A client does not have to support all three primitives. Many hosts limit themselves to tools because they offer the greatest leverage in agent scenarios.
User approvals and security
An MCP client does not execute tool calls blindly. For write or critical actions, the host obtains the user's approval. Beyond that, a client should check the tool descriptions it receives via tools/list for so-called tool poisoning. Here a manipulated server hides instructions in a tool's description in order to get the model to take unwanted actions. More on this in the security section below.
Transports: how client and server communicate
The protocol separates the message layer (JSON-RPC 2.0) from the transport. An MCP client therefore has to master the right transport for its server. There are currently two standardised variants.
stdio for local processes
With the stdio transport, the client starts the server as a local process and communicates via standard input and output. This route is simple, needs no network configuration and is suitable for tools on your own machine, such as a file system or Git server. Claude Desktop and Cursor use stdio for locally installed servers.
Streamable HTTP for remote servers
For servers running on another system, Streamable HTTP is used. The client sends its requests via HTTP POST. The server either replies directly with a response or opens a stream through which it delivers several messages one after the other. The older HTTP+SSE transport has been deprecated since protocol version 2025-03-26. New clients should no longer rely on it.
What changes with the 2026-07-28 specification
The current protocol version of 28 July 2026 noticeably changes the work of an MCP client. The most important points from the official changelog of the 2026-07-28 specification:
- The protocol is stateless. There is no longer an
Mcp-Session-Idheader and noinitializehandshake. - Protocol version and client capabilities are sent with each request in the
_metafield. - A new call,
server/discover, returns the server's capabilities. - Notifications run via
subscriptions/listen. - Multi-round-trip requests: the server can reply with
input_required, and the client then repeats the request with the requested answers. - The roots, sampling and logging features are deprecated, with a transition period of at least twelve months.
In practice this means: an MCP client built on the older session logic needs an update. The tier 1 SDKs largely take care of this for you, provided you keep them up to date. With in-house developments you should check whether your client still expects a handshake that modern servers no longer offer.
MCP clients in practice: examples
Abstract roles become tangible when you look at concrete products. The following examples show where an MCP client is already in use today and what it does there.
Claude Desktop, ChatGPT and Cursor as hosts
Claude Desktop, ChatGPT and the code editor Cursor are typical MCP hosts. If you enter a server in their configuration, the application creates an MCP client in the background, connects, retrieves the tool list and makes the tools available to the model. For you as a user the client remains invisible. It only becomes visible when the host asks for approval of a tool call.
If you build your own agent, you take on the host role yourself. You then use an SDK to create the client instances, decide on approvals and control which tools the model may see. How such agents are structured is explained in our glossary entry on AI agents.
Shopware 6 as an MCP server
An example relevant to e-commerce is Shopware 6. The MCP server is part of the core there and can be reached at /api/_mcp for the Admin API and at /store-api/_mcp for the Store API. Since version 6.7.14.0 it has been active without a feature flag. Authentication runs via the credentials of an integration, and for each integration an allowlist determines which tools are offered at all.
What stands out is the handling of toolsets: an MCP client can load further toolsets via the shopware-toolset-enable tool instead of loading the complete tool list into the model context from the start. This keeps the context lean and reduces wrong decisions by the model. How to connect an MCP server to shop, ERP and CRM is described in our post MCP server explained.
HubSpot and OAuth 2.1
Remote servers place additional demands on the client. HubSpot's remote MCP server, generally available since 13 April 2026, requires the MCP client to sign in via OAuth 2.1 with PKCE. A client that only handles static API keys cannot connect there. When choosing a host or SDK, it is therefore worth looking at which authentication methods are supported.
Security: tool poisoning and prompt injection
Because an MCP client inserts descriptions and results from outside into the model context, it is an attack surface. The OWASP MCP Top 10 list tool poisoning as a category of its own (MCP03). Here a tool's description contains hidden instructions that the model reads and follows without the user seeing them.
How effective such attacks are is shown by an evaluation by the Cloud Security Alliance from July 2026: in the MCPTox benchmark, the average attack success rate across 20 tested models was 36.5 per cent, and 72.8 per cent in the worst case. An MCP client should therefore check tool descriptions before passing them on to the model, detect changes to known descriptions and warn about suspicious content.
On top of this come classic attacks via data: if a resource's content or a tool result contains injected instructions, this is called prompt injection. The client cannot catch everything here, but it can label results, enforce approvals and restrict the permissions per server to what is necessary. The allowlist in Shopware is a good example of this limitation on the server side.
History and governance of the protocol
Anthropic published the Model Context Protocol on 25 November 2024. In March 2025 OpenAI adopted the protocol for its products, and Google followed in April 2025. Within a few months MCP was thus established with the three big model providers.
Since 9 December 2025, MCP has been a project of the Agentic AI Foundation under the umbrella of the Linux Foundation. The founding contributions came from Anthropic (MCP), Block (goose) and OpenAI (AGENTS.md). At launch, more than 10,000 published MCP servers were available. Details on the foundation can be found in the Linux Foundation's press release.
For you as a decision-maker, the neutral governance means: an MCP client that you build or use today is not tied to one vendor. The specification is developed further in the open, and the SDKs follow it.
Frequently asked questions about the MCP client
What is the difference between an MCP host and an MCP client? The host is the application with the language model, such as Claude Desktop or your own agent. The client is a protocol instance inside the host that maintains exactly one connection to an MCP server. A host can run many clients.
Can an MCP client talk to several servers at the same time? No. The relationship is 1:1. For each additional server, the host creates another client. The separation ensures that connections remain isolated and that permissions can be granted per server.
Do I have to program an MCP client myself? In most cases, no. Ready-made hosts such as Claude Desktop, ChatGPT or Cursor come with clients. For your own agents you use the official SDKs for TypeScript, Python, Go or C#, which encapsulate the client logic including transport.
What security tasks does an MCP client have? It obtains user approvals for tool calls, checks tool descriptions for hidden instructions (tool poisoning) and should limit permissions per server. The OWASP MCP Top 10 and the Cloud Security Alliance's MCPTox benchmark show that these checks are necessary.