MCP Client

An MCP client is the application a person actually uses — the chat interface, code editor, or agent runtime — that speaks the Model Context Protocol to one or more MCP servers. The servers provide capabilities; the client is where those capabilities get used.

If the MCP server is a power outlet, the client is the appliance plugged into it. One client can connect to many servers simultaneously, pooling all of their tools into a single session.

The client's job has three parts. First, connection management: launching local servers as subprocesses over stdio, or opening Streamable HTTP connections to remote ones, and keeping those sessions alive. Second, capability discovery: asking each server what tools, resources, and prompts it offers, and presenting the tool list to the underlying LLM.

Third, execution: when the model decides to call a tool, the client sends the JSON-RPC request to the right server, enforces any user-approval rules, and returns the result to the model. Most clients also handle the human-in-the-loop step — asking you before a tool with side effects runs.

The ecosystem spans desktop assistants, code editors, and automation frameworks. Claude Desktop and Claude Code come from Anthropic, the protocol's originator. Cursor, Windsurf, Zed, Cline, Continue.dev, and VS Code with GitHub Copilot bring MCP into the editor. On the automation side, n8n and LangChain can act as MCP clients inside larger agent workflows.

Configuration differs by client — each has its own config file location and format — but the protocol underneath is identical, which is why a single MCP server works across all of them without modification.

The MCP specification technically distinguishes the host (the application, e.g. Claude Desktop) from the client (the protocol connection the host opens to one server — one client per server). In everyday usage, "MCP client" almost always means the host application, and that's how marketplaces, docs, and setup guides use the word.

Either way, the boundary that matters in practice is: servers expose capabilities, clients consume them.

When a client calls a tool on a monetized server, the x402 exchange is handled by a wallet layer rather than the client's UI: the server responds with payment requirements, the agent's wallet signs and pays in USDC, settlement lands on Base in about two seconds, and the call proceeds. From the client's perspective it is still just a tool call that returns a result — plus a signed receipt.

Because the payment happens at the protocol level, the same monetized server works from any MCP client without client-specific billing integration.