MCP Architecture: Host, Client and Server
MCP becomes much easier to reason about once you separate three roles: the host, the client, and the server.
The host
The host is the AI application the user interacts with. It owns the broader product experience, model orchestration, policy decisions, and usually the lifecycle of MCP connections. A coding assistant or internal AI portal can be a host.
The client
The MCP client is the protocol-speaking component inside or controlled by the host. It sends MCP requests, receives server capabilities and results, and translates those capabilities into the host's internal tool/context model.
The server
An MCP server exposes capabilities. It may run as a local subprocess over stdio or as a remote service over HTTP. It can wrap APIs, databases, filesystem access, developer tools, SaaS products, or internal systems.
One host, many servers
A host can connect to multiple servers. The important architecture question is not just connectivity, but policy: which server is trusted, which tools are shown to which agent, and which actions require approval.
User → Host / Agent Runtime
├─ MCP Client → Git Server
├─ MCP Client → Database Server
└─ MCP Client → Deploy ServerSecurity boundaries
Do not assume an MCP server is harmless because it exposes structured schemas. A tool can still read sensitive data or perform destructive actions. Credentials should be scoped narrowly, server trust should be explicit, and sensitive tools should use human approval where possible.
The stateless 2026 core
Older MCP explanations often center on an initialization handshake and persistent sessions. The 2026-07-28 core moved toward self-describing stateless requests, allowing requests to land on different backend instances. Clients may still perform discovery, but the protocol no longer requires the old session-centric mental model for every request.