An MCP client is the component inside a host application that manages the connection to one or more MCP servers: it performs the initial capability handshake, receives the list of available tools, resources and prompts, and relays the model's tool calls to the right server and the results back into the conversation. The host application is what a user actually interacts with, and a growing list of them now embed an MCP client, including Claude Desktop and Claude Code from Anthropic, Claude.ai's remote connector support, and several code editors and IDEs such as Cursor, Windsurf and various VS Code extensions that use MCP to reach developer tools like Git, databases and issue trackers. Some agent frameworks used for building custom applications, including LangChain and LlamaIndex, now ship adapters that let a developer-built agent act as an MCP client as well, extending support beyond consumer chat applications into custom internal tools. Because the list of compliant clients keeps growing, the practical benefit of building an MCP server rather than a one-off integration is that new clients tend to work with it without additional changes. Nanobase AI tracks this client ecosystem to decide which transport and auth pattern fits a given deployment.
What the client actually negotiates at connection time
When a host application starts an MCP session, its client component performs an initial handshake with the server to discover what that server can actually offer: which tools it exposes, what resources it can serve, and whether it publishes any reusable prompts. This capability negotiation happens once per connection and determines what the model is told is available for the rest of that session. The client is the translation layer between "what a server can do" and "what the model sees it can do," and a server that adds a new tool after that handshake generally won't appear until the client reconnects or refreshes its capability list.
Categories of MCP clients today
The ecosystem of applications embedding an MCP client has grown well beyond the original chat assistants it launched alongside.
| Category | Examples | Typical transport used |
|---|---|---|
| Desktop and CLI assistants | Claude Desktop, Claude Code | Local stdio, remote Streamable HTTP |
| Cloud chat platforms | Claude.ai remote connectors | Remote Streamable HTTP |
| Code editors and IDEs | Cursor, Windsurf, various VS Code extensions | Local stdio, some remote |
| Agent frameworks | LangChain and LlamaIndex-based custom agents | Varies by implementation |
A server built once now has a realistic chance of reaching users through several of these categories without any server-side change.
Not every client uses every primitive the same way
MCP defines three primitives, tools, resources, and prompts, but adoption across clients has been uneven, with most clients today built primarily around the tools primitive since that maps most directly onto the model deciding to call a function. Support for resources and prompts, which serve different purposes such as pulling static reference content into context or offering reusable workflow templates, varies by client and is worth checking directly against current documentation for whichever client you're targeting rather than assuming full support. Building a server that only relies on tools is currently the safest way to guarantee it works consistently across the widest range of clients.
Why building once still pays off
Even with this unevenness, the practical benefit of building to the MCP specification instead of a one-off integration remains real: a server built correctly today tends to keep working as new clients adopt the protocol, without needing a separate integration for each one. A team that wrapped its internal ticketing system as an MCP server for one client typically finds that a second client, added later, works with little or no additional server-side change, since the protocol boundary rather than a client-specific API is what the server actually implements against. This is the compounding return that makes the initial investment in a standards-based server worthwhile over a one-off integration.
Frequently asked questions
What exactly does an MCP client do that the model itself doesn't?
The client manages the connection lifecycle, discovers what a server offers, and routes the model's decision to call a specific tool to the correct server, then relays the result back into the conversation. The model itself only sees the list of available tools and decides which to call; it does not manage the underlying connection or transport.
Do all MCP clients support remote servers, or only local ones?
Support for remote, Streamable HTTP-based servers varies by client and continues to expand, so check current documentation for the specific client you're deploying against. As of 2026, developer-focused tools like Claude Code and Claude.ai's connector support both extend to remote servers, while some clients remain oriented primarily toward local stdio connections.
Can a framework like LangChain act as an MCP client?
Yes, adapters exist that let agents built on frameworks such as LangChain or LlamaIndex act as MCP clients, connecting to the same servers a consumer chat application would use. This extends MCP's benefit beyond off-the-shelf assistants into custom internal applications a team builds itself.
How Nanobase AI helps
Nanobase AI, an accepted member of the NVIDIA Inception Program, tracks this evolving client ecosystem closely to decide which transport, primitive set, and authentication pattern fits a given deployment, so a server built for one client doesn't need a rewrite when a team adopts a second. This design discipline connects directly to how we think about MCP resources, prompts, and tools and about stdio versus HTTP transport choices for a new server. Read more on what MCP is and how to build a server.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.