The host owns the user-facing context.
The host is the AI application where a user or agent chooses what to do. It manages the conversation, model interaction, user approvals, and usually the policy for which MCP servers are available. The host can connect to several servers, but each server connection is represented by its own client component.
This separation prevents a server from assuming it controls the entire application. The host decides whether a capability is available and how its result fits into the broader task. The server should still explain its capabilities and return structured, useful errors when the requested work cannot be completed.
The client is the protocol boundary inside the host.
An MCP client maintains a one-to-one connection with an MCP server. It handles initialization, capability negotiation, discovery, requests, notifications, and transport details. A host may have many clients, but the server should not need to know the internal layout of the host to serve a valid request.
This is also where client-specific behavior appears. One client may ask for approval before a write tool; another may expose resources differently; a third may support OAuth or server instructions. When documenting an integration, separate protocol behavior from client policy so a reader knows which part can change.
- Host policy decides whether the connection is trusted.
- Client code handles MCP messages and transport behavior.
- Server code owns capability implementation and its own data boundary.
Transports change the deployment shape, not the core idea.
A local server commonly communicates over standard input and output. A remote server uses an HTTP-based transport so clients can reach a service across a network. The choice affects process lifecycle, credentials, latency, observability, and exposure, but both routes still need capability discovery, input validation, and clear error handling.
Treat transport as an operating decision. A local prototype may be easiest to inspect, while a shared remote service may be easier to update and govern. Do not move a server to the internet until its authentication, authorization, logging, and data retention behavior are understood.
Diagnose failures by locating the hop.
If a server never appears, inspect configuration, process startup, and transport connectivity. If the server appears but tools are missing, inspect initialization and capability discovery. If a tool is visible but a call fails, inspect the input schema, server validation, upstream dependency, and returned error.
This gives debugging a sequence instead of a guess. Capture the client, server, transport, request, response, and timing without logging secrets. A useful trace should let an owner explain what happened without replaying the entire conversation.