Hosts, clients, and servers

The host is the application in which MCP connections are used. It might be an IDE, desktop assistant, research tool, or custom enterprise application. The host usually coordinates the model, user interface, conversation state, and access to connected capabilities.

Most importantly, the host remains responsible for application policy. It decides which servers can be configured, which capabilities become available to the model, what context may leave the application, and when a user must confirm an action. It may apply an allowlist, hide tools that do not fit the current task, or reject arguments before any request is sent.

The host also presents results. A server can return structured content, but the host decides whether that content becomes model context, a user-visible card, an error message, or an audit event. Protocol standardization does not remove product design.

An MCP client is the protocol participant created by the host to communicate with a particular server. Conceptually, a host with three server connections has three clients, even if an SDK hides those objects behind one manager.

The client handles protocol duties such as initialization, capability negotiation, requests, responses, and notifications supported by both sides. It tracks which conversation a response belongs to and converts host intentions into messages the server understands.

This one-client-per-server mental model is useful for isolation. A filesystem server should not automatically receive context intended for a customer-support server. Separate connections make it easier to reason about credentials, failure, logging, and shutdown. An implementation may optimize internals, but the security design should preserve clear boundaries.

The client does not replace the host's policy engine. Receiving a list of tools does not mean the client should expose all of them to a model. It reports protocol facts; the host decides how those facts affect the application.

An MCP server provides capabilities through the protocol. It may run as a local process, a service on the same network, or a remote service, depending on the deployment and transport. It can expose tools, resources, prompts, or a subset of these.

The server translates protocol requests into domain behavior. A documentation server might search an index and read approved pages. An issue-tracker server might call a vendor API. The server is responsible for validating requests, protecting its own credentials, enforcing server-side authorization, handling provider failures, and returning honest errors.

A server should never assume that the host has performed every safety check. Defense in depth means both sides enforce the controls they own. For example, the host may require confirmation before requesting ticket creation, while the server verifies that the authenticated principal can create tickets in the selected project.

A conceptual lifecycle has several phases:

1. Start or connect. The host establishes a transport to the configured server.
2. Initialize. Client and server identify protocol expectations and supported capabilities.
3. Operate. They exchange capability discovery messages, requests, results, and supported notifications.
4. Change or fail. Capabilities may change, a request may error, or the connection may disappear.
5. Close. The application or server ends the session and releases resources.

Do not treat initialization as permanent proof that the server remains healthy or trustworthy. A local process can exit. A remote token can expire. A capability can be removed. A robust host scopes what it caches, responds to supported change signals, and has a reconnection strategy appropriate to the action risk.

The order of exact messages is defined by the protocol and implemented by current SDKs. At the conceptual level, remember that normal operations should not begin until initialization has established a compatible session.

Roles are logical, not geographical. A host and server on the same laptop are still separate trust domains if the server is third-party code. “Local” reduces some network exposure but does not make code safe. A local server may read files available to its operating-system process or execute commands within its permissions.

Conversely, one organization may operate both a host and a remote server, yet network and identity boundaries still matter. The transport must protect data in transit where appropriate, and the server must authenticate the caller rather than trusting a friendly product name.

Ask four questions for each connection: Who authored the server? Where does it run? Which identity and credentials does it use? What data and side effects can it reach? Those answers reveal more than the label “local” or “remote.”

The host owns consent, context selection, model exposure, and application-level policy. The client owns faithful protocol communication for its server connection. The server owns truthful capability behavior, input validation, and server-side access control. The underlying service still owns its own authorization and data rules.

Responsibilities can overlap intentionally. Both host and server may log a request using a correlation identifier. Both may enforce size limits. Both should treat text from the other side as untrusted input. Overlap is not waste when it prevents one mistaken assumption from becoming an incident.

When debugging, identify the role first. A missing tool could mean the server did not advertise it, the client failed discovery, or the host filtered it by policy. A denied invocation could come from host policy, server authorization, or the downstream API. Precise roles turn “MCP is broken” into a testable diagnosis.