MCP client
An MCP client is the side of a Model Context Protocol connection that consumes capabilities. It opens the transport, sends the initialize request, reads the server's tool list, and decides which of those tools to expose to a model. Claude Desktop, IDE extensions, and custom agents are all MCP clients.
Updated
What is an MCP client?
An MCP client is the program holding the model. It connects outward to servers, gathers what they offer, and presents some or all of it to the model as callable functions.
The client owns the conversation. It chooses which servers to connect to, when to refresh a tool list, and what to do when a server misbehaves.
Which apps are MCP clients?
Any app that connects to MCP servers on a model's behalf. These ten take a remote server by URL, and each one keeps it somewhere different:
| App | Where a remote server goes | Setup guide |
|---|---|---|
| Claude Desktop | Customize > Connectors, as a custom connector, not claude_desktop_config.json |
Claude Desktop |
| Claude Code | claude mcp add --transport http, saved in ~/.claude.json or a project's .mcp.json |
Claude Code |
| ChatGPT | chatgpt.com/plugins, then Add custom MCP server | ChatGPT |
| Cursor | ~/.cursor/mcp.json, or .cursor/mcp.json in a project |
Cursor |
| VS Code | MCP: Add Server, saved in a workspace's .mcp.json or ~/.copilot/mcp-config.json |
VS Code |
| Cline | The Remote Servers tab, or cline_mcp_settings.json |
Cline |
| Windsurf (now Devin Desktop) | ~/.config/devin/mcp_config.json |
Windsurf |
| Codex | A [mcp_servers.<name>] table in ~/.codex/config.toml |
Codex |
| Gemini CLI | gemini mcp add, saved in .gemini/settings.json |
Gemini CLI |
| GitHub Copilot CLI | /mcp add, saved in ~/.copilot/mcp-config.json |
Copilot CLI |
Where the client runs decides what it can reach. ChatGPT and Claude Desktop's custom connectors call your server from OpenAI's and Anthropic's networks, so they only reach a server with a public address. The coding tools connect from your own machine and can reach localhost, except in their cloud modes, such as Cursor's cloud agents. That is why a server can work in Cursor and fail in Claude or ChatGPT.
What does a client do during a connection?
Four things, in order: open the transport, send initialize with the revision it prefers, read back the server's revision and capabilities, then call tools/list to find out what is available.
Our own tester is a minimal client and does exactly this, which is why it can report what a server answered without knowing anything about the product behind it.
Why does the client's behaviour matter to a server author?
Because the client decides what the model sees. A server returning 213 tools is not offering the model 213 options: the client may paginate, filter, truncate, or refuse, and every tool it does pass through spends context.
The specification is explicit that a client "MUST consider tool annotations to be untrusted unless they come from trusted servers", which is the same principle applied to metadata. Descriptions and annotations are the server's claims about itself, and a careful client treats them that way.
Example
Our tester connected to https://gitmcp.io/docs on 5 August 2026, sent an initialize request, received revision 2025-03-26 back, and then called tools/list and read 5 tools. It reported those 5 and stopped. A production client like an IDE assistant would go further and hand some subset of them to a model, and that subset is a client-side decision the server has no say in.