Hosts, clients, and servers

The host is the AI application the person uses. It owns the interface, model interaction, permissions, and the overall user experience.

An MCP client is the connection inside the host. It speaks the protocol to one MCP server.

The server exposes a focused set of capabilities. It might read project notes, query a database, or call an existing API.

One host can manage several clients, each connected to a different server. The server does not become the model, and the model does not run inside the protocol.

This separation helps diagnose failures. If the server process crashes, the host interface and model can still work, but that client’s capabilities disappear. If one client cannot initialize, another server connection may remain healthy. If the model proposes a bad call, the host can still require approval before the client sends it.

The host owns policy such as which servers are enabled, which capabilities are shown to the model, and when the person must approve. The client owns one protocol session, including initialization and negotiated features. The server owns the schemas and implementation of its capabilities.

Credentials should follow the same boundary. A database password needed by one server should go to that server process, not into the model prompt or every other server’s environment.

Draw the path for this course: AI host → MCP client → project-notes server → notes data. Now label where an invalid tool argument is rejected, where filesystem access is restricted, and where the person sees an approval.

When debugging, name the failing role instead of saying “MCP is broken.” That one distinction usually cuts the search space dramatically.