MCP Server Architecture: Hosts, Clients, Servers, and Protocol Layers

MCP server architecture is a host–client–server system. A user-facing AI application acts as the host, creates one MCP client for each connected server, and coordinates the model and user experience. Each client maintains a dedicated protocol connection to one server, which exposes standardized capabilities such as tools, resources, and prompts.

The architecture in one diagram

The short answer

MCP architecture separates the host application, one or more protocol clients, and independently connected servers. Clients negotiate capabilities with each server, exchange structured protocol messages over a supported transport, and keep trust boundaries explicit rather than giving every server access to the whole application.

User → MCP Host / AI Application → MCP Client A → MCP Server A

→ MCP Client B → MCP Server B

→ MCP Client C → MCP Server C

The important relationships are:

• one host can manage many clients;

• each client maintains a direct relationship with one server;

• one remote server can serve many clients;

• the host coordinates what the model and user can access;

• servers do not automatically see the full conversation or other servers.

“MCP client” is not another name for the whole AI application. It is the protocol component the host uses for a particular server connection.

The three participants

MCP host

The host is the application the person interacts with, such as an AI desktop application, IDE, coding agent, or team workspace.

The host typically:

• creates and manages MCP clients;

• coordinates model interaction;

• aggregates available capabilities;

• controls consent and approval experiences;

• decides what context is sent to a server;

• applies security policies;

• routes results back into the task;

• manages connection lifecycle.

MCP standardizes context exchange. It does not dictate how a host prompts its model, stores chat history, selects tools, or designs approval interfaces.

MCP client

A client is instantiated by the host to communicate with one server.

The client:

• establishes the transport connection;

• performs initialization;

• negotiates protocol version and capabilities;

• lists server primitives;

• sends requests and notifications;

• receives results;

• maintains session state where applicable;

• exposes supported client features to the server.

If a host connects to a filesystem server and a project-management server, it normally creates two clients.

MCP server

A server provides focused capabilities through the protocol.

A server can:

• expose tools;

• expose resources and resource templates;

• expose prompts;

• send supported notifications;

• request client features such as sampling or elicitation;

• operate locally or remotely;

• validate requests and enforce access rules.

A server should expose a coherent capability boundary. “Everything in the company” is usually worse than a scoped workspace, repository, database role, or application service.

MCP has a data layer and a transport layer

Data layer

The data layer uses JSON-RPC 2.0 message structures.

It defines:

• requests with identifiers;

• matching responses;

• notifications without responses;

• initialization and capability negotiation;

• tools, resources, prompts, and client features;

• progress, cancellation, logging, and utilities.

JSON-RPC supplies the envelope. MCP defines method names, parameters, results, and lifecycle semantics.

Transport layer

The protocol defines two standard transport mechanisms:

• stdio: standard input and output, commonly used for a local server launched by the host;

• Streamable HTTP: HTTP-based communication for remote or independently running servers, with optional server-to-client streaming.

Custom transports are possible, but interoperability depends on both sides implementing them.

Transport choice changes deployment and security concerns, not the meaning of tools or resources.

Local stdio architecture

A common local flow:

1. The host launches a server process.

2. The host creates an MCP client.

3. The client sends JSON-RPC messages through standard input.

4. The server writes responses and notifications to standard output.

5. The host terminates the process when finished.

Advantages:

• simple local setup;

• no listening network port;

• direct process lifecycle control;

• useful for local files and developer tools.

Risks:

• the server inherits a local execution environment;

• filesystem and environment access require control;

• logs must not corrupt protocol output;

• the host must manage process failures;

• local does not automatically mean trustworthy.

Remote Streamable HTTP architecture

A remote flow:

1. The host connects to an MCP endpoint over HTTP.

2. Client and server initialize the protocol session.

3. Client-to-server messages use HTTP requests.

4. Server messages are returned directly or streamed where supported.

5. Session and protocol-version headers are managed by the transport.

6. Transport authorization protects the remote resource.

Advantages:

• shared service for many users or agents;

• centralized updates and operations;

• cloud data access;

• organizational authentication and governance.

Risks:

• authentication and authorization;

• tenant isolation;

• session affinity or durable state;

• horizontal scaling;

• retries and duplicate effects;

• network exposure;

• audit and revocation;

• origin and DNS security.

A remote endpoint is an application security surface, not merely a model integration.

MCP lifecycle and initialization

MCP is negotiated rather than assumed.

1. The client sends an initialize request.

2. It declares protocol version, identity, and capabilities.

3. The server responds with the negotiated version, identity, and capabilities.

4. The client sends an initialized notification.

5. Normal operations begin.

Initialization prevents a client from calling undeclared features and prevents a server from assuming the client supports elicitation or sampling.

If a compatible version cannot be negotiated, the connection should not proceed.

Capability negotiation

Capabilities are feature contracts for the session.

A server may declare:

• tools;

• resources;

• prompts;

• logging;

• completions;

• list-change notifications;

• resource subscription;

• task-augmented execution where supported.

A client may declare features such as:

• sampling;

• elicitation;

• filesystem roots;

• other facilities defined by the negotiated version.

Declaring a capability does not authorize every operation. It says the participant understands the protocol feature. Business permissions still require enforcement.

Server primitives

Tools

Tools are executable functions the AI application can invoke.

A tool definition includes name, description, and input schema. Current versions can support output schemas and metadata.

Examples:

• search documents;

• query a database;

• create a ticket;

• update a table;

• run a calculation;

• capture a screenshot.

Tools can change external state. Clients should present consent and servers must validate authorization and inputs.

Resources

Resources provide contextual data identified by URIs.

Examples:

• file contents;

• workspace documents;

• database records;

• repository metadata;

• API responses;

• generated reports.

Use a resource when the main operation is obtaining context. Use a tool when the model needs an action with structured arguments.

Prompts

Prompts are reusable interaction templates offered by a server.

Examples:

• review a code change;

• analyze an interview;

• generate a domain report;

• start a known workflow.

Prompts help users select a structured workflow. They are not hidden system instructions or security boundaries.

Client primitives

Sampling

Sampling lets a server ask the client’s AI application to perform a model completion. The server can remain model-independent while using the host’s model access and policies.

The host decides whether and how the request is fulfilled.

Elicitation

Elicitation lets a server request structured input from the user. It helps when a workflow needs information or confirmation.

The client controls the user experience and should not allow elicitation to bypass consent.

Roots

Roots communicate filesystem or workspace boundaries relevant to a server. Actual enforcement must still be implemented.

Logging

Servers can send log messages to clients when logging is supported, enabling debugging without mixing logs into protocol payloads.

Discovery before execution

A typical tool sequence:

1. initialize;

2. request tools/list;

3. register returned tool definitions;

4. let the host or model select a tool;

5. validate consent and policy;

6. request tools/call;

7. return tool content to the host;

8. continue the task.

Dynamic listing allows capabilities to vary by user, workspace, permissions, or state.

A client must not assume a tool exists because it existed in a previous session.

Requests, responses, and notifications

Request

Contains a method, parameters, and identifier. The recipient returns a matching response.

Response

Contains either a result or protocol error associated with that identifier.

Notification

Contains a method and parameters but no identifier, so no direct response is expected.

Notifications can announce initialization completion, list changes, resource updates, progress, cancellation, or logs.

Applications must not assume guarantees beyond the chosen transport and specification.

Sessions and state

Conflating these causes bugs.

Losing an HTTP transport session should not silently grant a new application session. Reconnecting should not cause an unsafe write to repeat.

Design write tools with idempotency, request identifiers, or confirmation when duplicates are harmful.

How multiple servers work together

Servers do not normally call each other through a shared magical bus.

The host:

1. discovers tools from several connections;

2. gives the model an appropriate capability set;

3. routes a call to its owning client;

4. receives the result;

5. provides relevant context to the next model step;

6. routes a later call to another server.

Example:

• Playwright MCP captures current page evidence.

• Dokki MCP stores evidence in a workspace.

• Linear MCP creates an approved task.

The host and workflow provide orchestration. MCP provides interoperable connections.

Security boundaries

MCP creates separation of concerns, but security depends on implementation.

Host responsibilities

• trusted server configuration;

• user consent;

• tool visibility;

• client isolation;

• model and context policy;

• approval for consequential actions;

• safe result handling.

Client responsibilities

• protocol validation;

• capability enforcement;

• transport security;

• session handling;

• cancellation and timeout behavior.

Server responsibilities

• authentication;

• authorization;

• tenant scoping;

• input validation;

• output minimization;

• audit logging;

• rate limiting;

• safe external API use;

• confused-deputy protection.

User and administrator responsibilities

• selecting trusted integrations;

• granting minimal access;

• reviewing external actions;

• revoking unused credentials;

• monitoring unexpected behavior.

Tool descriptions and annotations from untrusted servers are untrusted input. A server naming a tool “read-only search” does not prove it is read-only.

Production architecture decisions

Before deploying, decide:

1. Local or remote?

2. Which identity does the server act as?

3. Is scope per user, workspace, tenant, repository, or connection?

4. Which tools mutate state?

5. How are duplicate writes prevented?

6. How are secrets stored and rotated?

7. How are sessions resumed or expired?

8. How are capabilities filtered by permission?

9. What is logged?

10. Can access be revoked immediately?

11. How does the server scale horizontally?

12. What happens when the client disconnects mid-task?

The protocol removes integration boilerplate. It does not remove distributed-systems design.

A Dokki workspace example

1. An AI host creates an MCP client for Dokki.

2. The client authenticates a workspace-scoped connection.

3. Client and server negotiate capabilities.

4. The client lists Dokki tools and resources.

5. The agent searches or reads workspace content.

6. A write is routed through the same scoped connection.

7. The result lands in the workspace for review.

8. Revoking the connection cuts off that external client.

The workspace is an application authorization boundary layered on top of the protocol connection.

Architecture checklist

A healthy MCP architecture has:

• clear host, client, and server ownership;

• one scoped client/server relationship;

• protocol-version negotiation;

• capability-based feature use;

• separate data and transport layers;

• dynamic discovery;

• schema validation;

• least-privilege authorization;

• visible consent;

• idempotent or confirmable mutations;

• session expiration and revocation;

• structured logging and audit;

• bounded context sharing;

• failure and retry semantics;

• verification against the current protocol version.

Frequently asked questions

What is the difference between an MCP host and client?

The host is the user-facing AI application and coordinator. The client is the protocol component created to communicate with one server.

Can one MCP client connect to multiple servers?

The architecture models each client as maintaining one server connection. A host creates multiple clients for multiple servers.

Does an MCP server contain the model?

Not necessarily. The host normally owns model interaction. A server can request sampling from a supporting client.

Is MCP stateful?

MCP uses lifecycle and negotiated session state. Transport and application state vary. Current roadmap work continues to evolve scalability and lifecycle semantics, so use the current specification.

Does capability negotiation grant permission?

No. It declares protocol support. Authentication and business authorization still restrict resources and actions.

Does Streamable HTTP replace stdio?

No. Stdio suits local servers; Streamable HTTP supports remote services.

Sources

• Model Context Protocol: Architecture overview

• MCP specification: Architecture

• MCP specification: Transports

• MCP client concepts

• MCP server concepts

• MCP specification: Tools

• MCP 2026 roadmap

• Dokki Docs: MCP Connections