MCP client: what it is and how it differs from a server

An MCP client is the component inside an AI host that communicates with an MCP server. It discovers supported capabilities and sends requests for tools, resources or prompts on the host’s behalf. People often call the whole editor or assistant an “MCP client,” but the host and its protocol-speaking component have different responsibilities.

What is an MCP client?

The host is the application the user interacts with: an editor, terminal agent, assistant or custom runtime. The MCP client is the component it uses to reach a server. The server implements capabilities and returns their results. A host can manage several server connections through separate client components.

That separation is useful when diagnosing a task. The host chooses the model, presents context and decides when to continue. The client handles the protocol connection. The server handles its capabilities and any upstream service operations. A problem in one stage does not automatically belong to the other two.

Component	Main responsibility	Example
Host	User interaction and task orchestration	A coding application
MCP client	Protocol requests to a server	The host’s remote tool connection
MCP server	Capability descriptions and operation handling	An authenticated account-tool endpoint
Upstream service	Account resources and service effects	An issue tracker behind the server

The MCP architecture guide defines those roles. The MCP introduction explains the protocol, while what an MCP server is focuses on the capability provider.

MCP client vs server

The client requests capabilities and operations; the server provides them. That direction does not decide whether the software is local or remote. A client can communicate with a subprocess through stdio or with an endpoint through HTTP.

A server can expose tools backed by its own code or by another service. An issue-reading tool may require the server to authenticate to the tracker after the client has authenticated to the server. Those are separate credential and permission boundaries.

Question	Client	Server
Who sends the operation request?	The client on behalf of the host	Receives and handles it
Who describes available capabilities?	Reads the advertised description	Provides its capability interface
Who holds model orchestration?	The host around the client	Not automatically part of the server
Who handles service-account access?	May authorize the server connection	Uses and enforces its upstream connection
Where does it run?	Within or beside the host	Local process or remote service

A server supporting tool calls does not prove the host knows how to use every capability. A host supporting MCP does not prove it accepts every transport, authentication mode or protocol extension. Evaluate compatibility at those specific boundaries.

Popular MCP clients and hosts

These host families have setup guides for AIPx. Their configuration syntax and interfaces differ even when the remote endpoint is the same.

Host	Common setup surface	Relevant guide
Claude apps	Remote connector interface	Claude MCP setup
Claude Code	CLI registration and project/user config	Claude Code MCP setup
Codex	CLI registration and TOML configuration	Codex MCP setup
Cursor	Project or global JSON configuration	Cursor MCP setup
Claude Desktop local servers	Developer launch configuration	Claude Desktop setup
ChatGPT	Current custom-server plugin interface	ChatGPT setup
VS Code and compatible editors	Client-specific workspace/user config	Other client setup

Some search results also mention Goose, Cline or framework adapters. Review their maintained documentation for your version rather than inferring compatibility from a name in a list. A framework that supports model tool calling is not automatically configured as an MCP client.

Match configuration to the host

Claude Code uses its CLI and .mcp.json scope model. Codex uses config.toml. Cursor uses .cursor/mcp.json or a global file. A JSON example from one client is not interchangeable with every other client’s schema.

Remote account authorization also depends on the host’s implementation. A tool marked for confirmation may cause one client to request human review and another to call it directly. If that review is part of your required workflow, test the actual client rather than assuming protocol compatibility establishes the behavior.

MCP client Python example

The official Python SDK’s current v2 documentation exposes Client from mcp. The example below connects to a deliberately local development server and inspects its declared capabilities. It is not an AIPx OAuth implementation, and it uses no provider account credential.

import anyio
from mcp import Client

async def inspect_server() -> None:
    async with Client("http://localhost:8000/mcp") as client:
        capabilities = client.server_capabilities
        print(capabilities.model_dump(exclude_none=True))

anyio.run(inspect_server)

The server must already be running at that address. Use the official SDK first steps for its matching server example and installation instructions. Older SDK examples use different APIs, so check the installed major version before copying a snippet.

This code demonstrates the client boundary without involving a model. A model is not required to verify the connection or inspect capabilities. The host can later decide how to turn available tools into its model-facing interface.

In-memory clients for testing

The v2 SDK also documents passing a server object to Client, using Client(mcp) for in-memory tests. That is useful for exercising the protocol-facing handlers without a separate port or subprocess. It does not prove that a remote deployment’s authentication and network behavior work.

Use separate tests for those boundaries. A local handler test can validate an input schema and result. An HTTP integration check can validate reachability and transport. An authorized account test can validate actual provider access. Treating one as proof of all three leaves important failures untested.

MCP client server architecture

A useful architecture keeps the host’s task loop separate from transport and provider execution. The host obtains capability descriptions, exposes suitable tools to the model, validates proposed actions and asks the client to call the server. It then handles results and decides whether the task needs another step.

A gateway can stand between the client and several upstream integrations. AIPx presents an agent endpoint with permitted account tools. From the client’s perspective it is a server connection; behind it are separately connected service accounts and their own authorization requirements.

The MCP architecture article develops that arrangement. Avoid claiming that a gateway automatically observes model inference or runs the entire host. Its evidence is limited to the operations that actually pass through it.

Protocol versions and implementation versions

The current specification revision is 2026-07-28, while deployed SDKs and products can support different revisions or compatibility modes. Earlier tutorials can describe initialization handshakes and connection sessions that should not be generalized to the latest stateless model. Follow the versioned specification and the SDK or product you are actually using.

For ordinary user setup, the supported client configuration matters more than hand-writing JSON-RPC messages. Let the maintained implementation handle its protocol details, and verify the required capabilities rather than forcing a snippet from another revision into the connection.

Choosing a client for local or remote servers

Choose from the task environment. A local server needs a client that can launch or reach the process. A remote server needs supported HTTP transport, reachable network placement and compatible authentication. The graphical interface alone does not tell you where a request originates.

Claude’s remote connector requests originate from its cloud, including in Desktop. That path cannot reach your laptop’s localhost without an explicit route. A local desktop launch configuration is a different connection model. Read the remote MCP server guide for placement decisions.

Selection check	What to verify
Transport	Local stdio or remote HTTP support
Authentication	The server’s supported login or credential method
Capability use	Required tools, resources or prompts are available
Configuration scope	The intended project or user can see the server
Review behavior	Approval hints are handled as your workflow expects
Discovery refresh	Changes to tools and rules can be reflected
Diagnostics	Connection and provider failures can be distinguished

Connecting an AIPx agent

Connect the required service accounts, create an agent and review its tools. Copy https://dash.aipx.run/mcp/AGENT_ID with the dashboard’s actual identifier, register it using the host’s setup and complete OAuth. The URL identifies a protected resource rather than acting as an API key.

Hide is enforced server-side and removes the operation from the agent surface. Allow and Confirm are execution hints, with Confirm requesting client review. Use Hide for an unavailable-operation requirement and verify the actual client before relying on confirmation.

After a first read, inspect the audit’s agent, account, tool, inputs, result and time. A successful connection is not enough: verify that the right account supplied the answer. Free includes three connected accounts and one agent; Pro is $3 per month for unlimited accounts and agents plus Pro integrations.

A direct official server can be simpler for one service. A private local server can fit sensitive environments better. AIPx adds another hosted operator in exchange for shared account configuration and per-agent tool views, while upstream subscriptions and model costs remain separate. Connect free.