MCP client

How an MCP client works

The Model Context Protocol splits an integration into three roles. The host is the AI application a person uses, such as a chat assistant, a code editor or an agent. The client is a connector inside that host. The MCP server is the program on the other end that offers tools and data 1. The host creates one client per server, and each client keeps a dedicated connection to its server 2. A host connected to five servers runs five clients.

A client starts from a configuration entry. For a local MCP server, the entry is a command that starts the server as a process on the same machine, and the two talk over the stdio transport 2. For a remote MCP server, the entry is a URL, and the client talks over Streamable HTTP 2. The architecture guide notes that a local stdio server typically serves a single client, while a remote server typically serves many 2.

Under the current revision, each request is self-contained. Every request carries the protocol version and the client's capabilities in its metadata, and the client should include its own identity there too 2. A client that wants to learn what a server supports first sends a server/discover request 2. It then lists the server's MCP tools with tools/list and calls one with tools/call when the model picks it through tool calling 2.

Authentication belongs to the transport. On remote HTTP connections, MCP recommends OAuth to obtain authentication tokens, and the transport also supports bearer tokens, API keys and custom headers 2. The client runs the sign-in and attaches the token to each request. MCP OAuth describes that flow in detail.

What an MCP client offers the server

Most traffic runs from client to server, but a client can also offer features the server may use. The specification lists elicitation as the client feature in the current revision, a way for a server to ask the user for more information 1.

• Elicitation in form mode. The server sends a schema, and the client builds an input form, collects the answer and validates it 3.
• Elicitation in URL mode. The server sends a URL for the user to open, and the data never passes through the client, which suits credential entry and third-party OAuth 3.
• Roots. These told a server which directories to focus on, and they are deprecated as of the July 28, 2026 revision 3.
• Sampling. This let a server ask the host's model for a completion, and it is also deprecated as of that revision 3.

Servers must not use form mode to ask for passwords, API keys, access tokens or payment details, and the client guide describes clients warning users about suspicious requests and letting them review form data before sending 3. Consent sits with the host. Hosts must get explicit user consent before they invoke any tool, and before they expose user data to a server 1. The specification also tells implementers to treat tool descriptions and annotations as untrusted unless they come from a trusted server 1. A client that shows the user each tool call and its inputs before it runs gives that consent a real meaning.

Example of an MCP client

The official architecture guide walks through the first message a client sends 2. The client calls server/discover and states who it is and what it supports, shortened here 2.

{"jsonrpc": "2.0", "id": 1, "method": "server/discover",
 "params": {"_meta": {
  "io.modelcontextprotocol/clientInfo": {"name": "example-client", "version": "1.0.0"},
  "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

The capability block tells the server that this client can collect extra input from the user when asked 2. The server answers with its supported versions, its capabilities, such as tools with list change notifications, and a ttlMs value of 3600000, which lets the client cache the answer for an hour 2. Calling server/discover is optional, since every request carries the same metadata and a client can send any request directly 2. The client then lists the server's tools and keeps them ready for the model.

A remote data server works the same way from the user's side. RichAPI runs its server at mcp.richapi.ai 4. A user pastes the server URL into an MCP client, signs in to RichAPI when the client opens it, and clicks Allow, with no API key to copy 4. The page says the same URL works in any client that supports remote HTTP MCP 4. From then on, a request such as checking an email list before a send becomes a tool call from the client, and the page prices email verification at 2 credits per email 4.

MCP client vs MCP host

People use the two words for the same thing, but the specification keeps them apart. The host is the AI application that starts connections and manages the user experience 1. The client is a connector inside the host, created for one server and dedicated to it 2. A user installs and opens a host. The host creates clients behind the scenes as the user adds servers. Consent duties sit with the host, which must get explicit user consent before any tool runs 1.