In Model Context Protocol (MCP), an MCP client is the host app’s per-server connection component. The host creates one client for each MCP server, and the client runs the session, negotiation, and message routing. It is not the LLM and not an AI agent.
TL;DR
- An MCP client is the host’s embedded per-server connector, running a stateful session, negotiation, and message routing.
- Each client maintains one direct 1:1 connection to one server, while hosts coordinate many isolated clients.
- Host–client–server roles stay distinct: host handles UX, consent, security, lifecycle; client handles session mechanics.
- Servers expose tools, prompts, and resources; the LLM reasons and an agent orchestrates workflows separately.
- Clients negotiate capabilities and use JSON-RPC for discovery and invocation over HTTP or stdio transports.
MCP Client Definition
If you keep hearing “MCP client” in Claude Desktop or an IDE, think “the host’s connector for one server.” The host instantiates it, and it speaks MCP to a specific server on your behalf.
An MCP client is the protocol-level component that maintains one direct communication with one server. Hosts can coordinate many clients at once, each isolated to its server connection.
This 1:1 boundary is what keeps integrations composable. You can add or remove servers without rewriting the host, and you can scope permissions per server instead of granting one giant integration.
How people get confused: “MCP client” is used two ways: the embedded client component inside a host, and a developer library/API you import to build such a client capability. When you read docs, check whether they mean “component role” or “programming interface.”
Next, lock in the role separation so you can spot what you’re configuring in any MCP setup.
Role Map Table
MCP uses a host–client–server architecture, but most confusion comes from mixing those roles with “the model” and “the agent.” This quick map keeps the terms stable across Claude, Cursor, and other ecosystems.
The host is the user-facing app, the client is the per-server session component inside the host, and the server exposes tools, prompts, and resources. The LLM is the reasoning engine, and an agent is a workflow layer.
The host owns consent, security policy, and lifecycle control, while the client owns session mechanics. That division is a key trust boundary, especially when servers can touch sensitive data or take actions.
How to use it: When you’re “adding an MCP server” in settings, you’re usually configuring the host to create a client connection to a server. The labels differ by product, but the roles do not.
| Component | What it is | Primary job | Where you touch it |
| Host | App you use | UX, consent, security policy, lifecycle | App settings and approvals |
| Client | Embedded connector | One stateful session per server, negotiation, routing | Usually implicit; created by host |
| Server | Capability provider | Exposes tools, prompts, resources | A URL/command you add, plus auth |
| LLM | Model | Generates text and decisions | Model selector or API config |
| Agent | Workflow layer | Plans steps, calls tools, handles loops | Your app/agent framework logic |
With the map in place, the fastest way to remove ambiguity is to compare the client to the most commonly confused concepts.
Client Comparisons
Most “MCP client” questions are really “what role is this playing?” You only need a few crisp boundaries to stop mixing up client, server, LLM, and agent in system diagrams and configs.
What to remember: The client initiates and maintains the session to a server. The server exposes capabilities. The LLM reasons, and an agent orchestrates. These are different responsibilities, even when one product bundles them.
Why confusion persists: Product UIs often say “Add MCP server,” but community talk says “use an MCP client.” Both can be true, because the host UI is really configuring the host to spin up a client connection.
How to resolve it quickly: Ask one question: “Is this thing exposing tools, or calling them?” If it exposes tools, it’s a server. If it calls tools from a host context, it’s a client.
Versus MCP Server
An MCP server is the provider role: it exposes tools, prompts, and resources that clients can use. A client is the consumer role: it connects, negotiates capabilities, and calls into those exposed features.
This matters because servers can be local or remote, and you should treat them as external code with explicit permissions. The host’s job is to enforce policy boundaries across multiple server connections.
Practically, if you have a server URL, a command, or a deploy target, you’re dealing with a server. If you’re inside the host that manages those connections, you’re dealing with clients.
Next, separate protocol roles from the model itself so you don’t accidentally describe the LLM as “the client.”
Versus LLM
A large language model (LLM) is the model that generates text and decisions. MCP is the wiring standard around it, so the model can access tools and data through consistent interfaces instead of bespoke integrations.
This matters because you can swap LLMs without changing MCP’s role boundaries. The host still manages clients, each client still talks to one server, and servers still expose tools and resources.
In other words, the LLM is not “the MCP client.” The client is the protocol session component that mediates access and keeps permissions and consent under host control.
Next, separate “agent” as an orchestration layer from “client” as a protocol component.
Versus AI Agent
An AI agent is a behavior pattern or system design that plans steps, calls tools, and loops until a goal is done. MCP is one common way an agent-enabled host can access external capabilities safely and consistently.
This matters because an agent might use multiple MCP servers, meaning the host may spin up multiple client instances. Treating “agent” and “client” as synonyms hides where consent and security enforcement should live.
A good rule is: the agent decides what to do, while the MCP client is the connection mechanism used to talk to a specific server. Some libraries call themselves “McpClient,” but that is an API, not the agent role.
Now that roles are clear, the remaining question is “what actually happens on the wire” when a client connects and runs tools.
How MCP Clients Work
At a high level, an MCP client creates a stateful session to a server, negotiates what each side supports, then sends JSON-RPC messages to discover and invoke capabilities. You don’t need code to understand the flow.
The client establishes a session per server, exchanges capabilities, and routes messages bidirectionally. Servers can expose tools, resources, and prompts, and the client can provide features like sampling and roots.
MCP keeps the host in control of policies and consent, while letting servers request structured interactions. That design supports human-in-the-loop approvals and reduces the risk of silent, over-privileged tool use.
How transports fit: Remote connections commonly use HTTP-based transports, while local connections may use stdio. The protocol also defines an authorization framework for HTTP transports, but not for stdio, where credentials are typically handled differently.
Example Flow
Imagine you add a server entry in your IDE’s MCP settings, pointing to a server URL with a token. The host reads that config, creates a client instance, and opens one session to that specific server.
During initialization, the client and server negotiate capabilities, then the client discovers what tools and resources the server offers. When you ask a question, the host decides whether to call a tool and may require approval before sending data.
After a tool runs, the server returns results to the client, and the host merges those results into the model’s context to produce the final answer. The server never “becomes the model,” it only supplies capabilities through the session.
Next, ground this in where you’ll actually see MCP clients when you’re configuring real products.
Where MCP Clients Run
You typically do not “run an MCP client” as a separate program when using mainstream tools. Instead, you use a host app that embeds client functionality and manages one client instance per server connection.
Hosts can be assistants, IDEs, or agent apps that need external capabilities. In those products, “MCP client” usually means “the embedded client inside the host that connects to servers.”
This framing helps you debug faster. If tools do not appear, you usually troubleshoot the host configuration, the server URL, or auth, rather than hunting for a separate “client process.”
How to apply it: If your tool supports both local and remote servers, decide whether your server runs on your machine or over the internet. That choice drives whether you configure a local command or a remote URL.
Spot it in Config
If you’re editing a JSON block that lists mcpServers, you are configuring the host to create a client connection to each named server. This pattern shows up across IDE-style MCP integrations.
{
“mcpServers”: {
“example-server”: {
“url”: “https://server.example.com/sse?token=YOUR_TOKEN”
}
}
}
Next, decide when MCP is the right integration tool, and how to avoid the most common trust and safety mistakes.
When to Use MCP
MCP is most valuable when you want a reusable, standard way for a host and model to access many tools and data systems without building one-off integrations for each pairing. It is a portability play.
Instead of custom wiring between every model and every tool, MCP standardizes the session, messages, and capability discovery. That makes it easier to swap hosts, models, and servers as your stack changes.
Remote MCP servers can touch sensitive data and actions, and tool outputs can include risky content like URLs. Prefer official servers from service providers, log shared data, and require approvals for higher-risk calls.
How to decide quickly: Use MCP when you want composable integrations across hosts and teams. Skip it when a single direct API integration is simpler and governance is already solved inside one app.
| Approach | Best when | Trade-offs |
| MCP | Many tools, many hosts, portability matters | You must manage trust, auth, and approvals well |
| Direct API integration | One app, one workflow, tight control | Harder to reuse across different hosts/models |
| Custom connector layer | You need governance, logging, policy | More build and maintenance effort |
Next, if you already have an MCP client in your host, the practical next step is pointing it at a server you control.
Connect to CustomGPT Server
If you want a no-code adoption path, treat CustomGPT as the MCP server and your existing tool as the host with an embedded client. Most MCP clients only need a server URL and an auth token to connect.
- Open your CustomGPT project and locate the MCP Server deployment option in the project deploy area.
- Copy the server URL provided for your agent’s hosted MCP server endpoint.
- Generate or copy your MCP token used to authenticate the client to that server.
- In your host app, add a new MCP server entry and paste the CustomGPT server URL with the token.
- Save settings, then start a new chat or reload the host so it recreates the client session cleanly.
- Confirm the server’s tools appear, then try a simple query that should hit your private docs or enabled permissions.
- If you need client-specific UI steps, follow the relevant guide for your host rather than guessing menu names.
You should see the server listed in the host, and tool-backed answers should clearly reflect your CustomGPT agent’s knowledge and enabled permissions. If nothing appears, recheck the URL, token, and whether your host supports remote connections.
Conclusion
If you remember one thing, remember the boundary: the host owns the user experience, consent, and policy, while the MCP client is the host’s per-server session that talks to one MCP server. That clarity prevents most setup mistakes.
Use MCP when you want reusable integrations across tools and teams, and treat remote servers as external code that deserves trust checks and approvals. When you already have a host with MCP support, the fastest win is connecting it to a server you control.
If you want a no-code path, point your existing MCP client at a CustomGPT hosted MCP server and verify tools appear before enabling broader permissions. That keeps the rollout safe and reversible.